home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16575 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  1.3 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!usc!srhqla!quest!kdq
  2. From: kdq@quest.UUCP (Kevin D. Quitt)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Reasons for using C vs. Fortran or vic
  5. Message-ID: <0i5auB1w165w@quest.UUCP>
  6. Date: 16 Nov 92 00:57:56 GMT
  7. Article-I.D.: quest.0i5auB1w165w
  8. References: <1992Nov15.201555.20678@thunder.mcrcim.mcgill.edu>
  9. Reply-To: srhqla!quest!kdq
  10. Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210
  11. Lines: 18
  12.  
  13. mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  14. > In article <1992Nov13.162451.13049@zia.aoc.nrao.edu>, cflatter@nrao.edu (Chri
  15. > > Storing arrays by column or by row doesn't make any difference
  16. > > whatsoever to the speed of matrix operations: it is merely a notation
  17. > > change.
  18. > This is true only in the abstract.  I have experienced (not just heard
  19. > about) multiple orders of magnitude speed differences, because going
  20. > through arrays "the wrong way" had catastrohpically bad VM behavior:
  21. > essentially, every access involved a page fault.  Doing it "the right
  22. > way" stepped through VM in a nice sequential way, with minimal paging.
  23.  
  24.     You've misunderstood.  *Storage order* makes no difference, as long
  25. as the *access order* matches.  What you've described is what happens
  26. in any language when the wrong order is used.
  27.  
  28.  
  29.  _
  30. Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
  31.