stdio performance in tango, stdlib, and perl

[Andrei Alexandrescu (See Website For Email)]

James Dennett wrote:
> 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.

If you did, fine. I take that part of my argument back. I'll also note 
that that doesn't make iostreams any more defensible :o).

Andrei