stdio performance in tango, stdlib, and perl

[James Dennett]

Andrei Alexandrescu (See Website For Email) wrote:
> James Dennett wrote:
>> As you appear to be saying that printf has to flush every
>> time it's used, I'd guess that it's unusable for performance
>> reasons alone.
> 
> Numbers clearly tell the above is wrong. 

Only if they apply to the above.

> Here's the thing: I write
> programs that write lines to files. If I use cout, they don't work. If I
> use fprintf, the do work, and 10 times faster. And that's that.

Except that your test wasn't of the right thing; you
probably didn't test code that guaranteed atomicity
of writes between different processes.

>> It's also really hard to implement such a
>> guarantee on most platforms without using some kind of
>> process-shared mutex, file lock, or similar.  Does printf
>> really incur that kind of overhead every time something is
>> written to a stream, or does its implementation make use
>> of platform-specific knowledge on which writes are atomic
>> at the OS level?
> 
> The C standard library takes care of it without me having to do anything
> in particular.

I've never seen a C library that guarantees atomicity of
writes between processes on a Unix-like system.  The
documentation of some systems does guarantee atomicity
of sufficiently small writes to certain types of file
descriptors, but I've not seen any Unix-like system
that guarantees atomicity for writes of unlimited sizes;
in some cases they can even be interrupted before the
full amount is written.  I've certainly seen the result
of C's *printf *not* being synchronized between processes
on a wide variety of systems.

>> Within a process, this level of safety could be achieved
>> with only a little (usually redundant) synchronization.
>> Which is useful for debugging or simplistic logging,but
>> not for anything else I've seen.
> 
> I do not concur.

With my description of my own experience?  ;)

-- James