From: terje.mathisen@nospicedham.tmsw.no   
      
   Alex McDonald wrote:   
   > On 20-Jul-18 09:54, Terje Mathisen wrote:   
   >> James Van Buskirk wrote:   
   >>> "fizz buzz"  wrote in message   
   >>> news:f32b85f8-e105-4869-bb7e-456c2d525981@googlegroups.com...   
   >>>   
   >>>> According to this logic, fastest prime number calculating   
   >>>> algorithm would just print text file with already calculated   
   >>>> prime numbers.   
   >>>   
   >>> Whoa, you can calculate and format the primes via the Sieve of   
   >>> Eratosthenes way faster than you can read the data off disk.   
   >>>   
   >> Exactly right, and we have the same case here:   
   >>   
   >> As long as you get above 10-100K numbers it will be much faster to   
   >> calculate the output on the fly instead of loading it from a disk   
   >> file.   
   >>   
   >> Terje   
   >>   
   >   
   > It's my understanding that neither sys or user process time under   
   > Linux includes the load of the executable, since there's no process   
   > in place to time. So if I start the timing of my program from when it   
   > starts execution and exclude the load time, then a program with   
   > memoized values as part of the executable will always appear to be   
   > faster.   
   >   
   That seems obvious, but isn't actually true:   
      
   It can be significantly faster to store data from SIMD registers than to   
   copy it from the memory image, i.e. from one address to another.   
      
   It is only if you replace the entire program with a single (unbuffered,   
   so needs 4kB aligned data array) write() call that an immediate array   
   will be faster.   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)