home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,419 of 243,242   
   bart to Paul   
   Re: is_binary_file()   
   11 Dec 25 11:46:19   
   
   From: bc@freeuk.com   
      
   On 11/12/2025 03:35, Paul wrote:   
   > On Wed, 12/10/2025 5:37 PM, bart wrote:   
      
   >> A getc loop took 4.3 seconds to read a 192MB file from SSD, on my Windows   
   PC.   
   >>   
   >> Under WSL it took 8.4 seconds (8.4/0.5 real/user).   
   >>   
   >> However reading it all in one go took 0.14 seconds.   
   >>   
   >> I guess not all 'getc' implementations are the same.   
   >   
   > #include    
   > #include    
   > #include    
   >   
   > /* gcc -Wl,--stack,1200000000  -o getcbench.exe getcbench.c */   
   >   
   > int main(int argc, char **argv)   
   > {  FILE* source;   
   >   
   >     int c;                                      /* getc holder */   
   >     const int size = 1000*1000*1000;   
   >     char keep[size];   
      
   I didn't see the point of either keeping the array on the stack, or   
   using a VLA. I made it static. That also allowed me a choice of   
   compilers with no special options needed.   
      
   > Add some code after the fopen.   
   >   
   >     if (setvbuf(source, NULL, _IOFBF, 65536) != 0)   
   >     {   
   >          fprintf(stderr, "setvbuf() failed\n\n" );   
   >          return -1;   
   >     }   
      
   When I added that, it slowed it down! Maybe it was already using a   
   bigger buffer.   
      
   > Extra code was added so keep[] was not optimized away.   
      
   My loop didn't store the characters anywhere; it just bumped a count.   
      
   I think it was enough that it was calling an external function, 'getc';   
   a commpiler can't optimise that away.   
      
   > Read 1000000000 bytes in 001.075651 seconds   
   >   
   > Busy sum = FFFFFFFFE216FE9C   
   >   
   > That's getting close to a gigabyte per second.   
   >   
   > Summary: The -O2 makes a BIG difference.   
   >           No idea how it is cheating.   
      
   How a look at the generated assembly: is it still making an actual call   
   to 'getc', or has it been inlined?   
      
   In my case -O2 made little difference, and it was still calling getc().   
   -O2 can't effect such a precompiled function, unless getc() is not   
   really an external function: either a macro, or a wrapper.   
      
   Also, the generated EXE file actually imports getc from msvcrt.dll,   
   which is a library not known to be performant.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca