TIP: Click on subject to list as thread! ANSI
echo: c_plusplus
to: CAMERON CLARK
from: JERRY COFFIN
date: 1997-05-27 09:14:00
subject: compiler opt.

On (25 May 97) Cameron Clark wrote to Jerry Coffin...
 CC>     How many layers of caching does one need? get?
Hard to say with any certainty...
 CC>     It seems that most likely the drive does some caching/readahead
 CC>     and then OS does the same, and then the compiler does the same.
 CC>     It would seem that there is quite a bit of overkill if a modern
 CC>     compiler assumes that its own caching will improve upon the
 CC> caching up the ladder.
Try a bit of testing:
#include 
#include 
int main(void) {
    clock_t start = clock();
    FILE *null_dev = fopen("NUL", "wb");
    for ( int i=0; i<100000; i++)
        putc( i % 255, null_dev);
    printf("Time with buffering: %f",
        static_cast(clock()-start)/CLOCKS_PER_SEC);
    setvbuf(null_dev, NULL, _IONBF, 0);
    start = clock();
    for ( i=0; i<100000; i++)
        putc (i % 255, null_dev);
    printf("Time without buffering: %f",
        static_cast(clock()-start)/CLOCKS_PER_SEC);
    return 0;
}
On my system, the version with buffering turned on is roughly 20 times
as fast as the version with it turned off.
Now, note that this is writing to the NUL device, so no output is ever
actually generated at all.  What we're doing here is simply reducing the
overhead in having to call the OS evertime we want to write a character.
After we do that, the OS simply discards the character.
In my experience adding at least a little simple-minded buffering to a
program will typically give a speed increase of 15 or 20 to 1.
 CC>     While I do agree with the use of inline for some functions, I've
 CC>     never been a believer in the use of macros. I find macros in a
 CC> high level language deconstructive to the ideas behind strong
 CC> typecasting
In this case, they're macros simply because they're left-overs from C,
which lacks inline functions.  If they'd been designed specifically for
C++, they'd undoubtedly be inline functions instead.  However, this is
more or less beside the point.  The simple fact is that for simple
character at a time I/O, iostreams are typically quite a bit slower than
their C counterparts.  They may be more typesafe, but in many cases
taking a 2 or 3:1 speed hit simply isn't acceptable.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------
* Origin: Point Pointedly Pointless (1:128/166.5)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.