From: demon.adramelek@nospicedham.gmail.com   
      
   On Friday, July 20, 2018 at 8:11:42 AM UTC-5, 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.   
      
   Not sure about that. I suspect time command does count loading time.   
      
   As you can see in the code, I define output buffer as ".lcomm OutputBuffer,   
   ITERATIONS*9", so the memory is requested by loader at the loading time.   
   However, if I'll try to do "OutputBuffer: .fill ITERATIONS*9, 1, 0x00" so the   
   OutputBuffer will be part of executable, then output of time command will   
   show much bigger numbers. I guess it's because it takes much longer to   
   load such big executable. I don't have other explanation.   
      
   > --    
   > Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)