stdio performance in tango, stdlib, and perl

Sean Kelly sean at f4.ca
Sat Mar 24 15:31:43 PDT 2007


Andrei Alexandrescu (See Website For Email) wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> Bill Baxter wrote:
>>>> James Dennett wrote:
>>>>> Walter Bright wrote:
>>>>> It might be harsh, but not entirely unjustified, to say
>>>>> that the "conventional wisdom" of many communities of
>>>>> programmers is a long, long way from being wise.  As
>>>>> the community behind a language grows larger, there is
>>>>> a natural tendency for it not to have some a density
>>>>> of experts; if D amasses a million users it's a safe
>>>>> bet than most of them won't be as sharp as the average
>>>>> D user is today.
>>> D bucks conventional wisdom in more than one way. There's a current
>>> debate going on among people involved in the next C++ standardization
>>> effort about whether to include garbage collection or not. The people
>>> involved are arguably the top tier of C++ programmers.
>>>
>>> But still, there are one or two that repeat the conventional (and wrong)
>>> wisdom about garbage collection. Such conventional wisdom is much more
>>> common among the general population of C++ programmers.
>>
>> Which "wrong" assertions are those?
>>
>>>> I think there is a tendency to assume that APIs and languages which
>>>> have (A) been around a long time and
>>>> (B) been used by millions of people
>>>> will probably be close to optimal.  It just makes sense that that
>>>> would be the case.  Unfortunately, it's all too often just not true.
>>> I just find it strange that C++, a language meant for building speedy
>>> applications, would incorporate iostreams, which is slow, not thread
>>> safe, and not exception safe.
>>
>> I'm intrigued by your claim that IOStreams is not thread-safe;
>> the IOStreams framework is thread-safe in the same way that
>> the STL is thread-safe.  The one minor difference is that
>> IOStreams exposes some global variables, which is unfortunate
>> as they can easily be used in inappropriate ways in a
>> multi-threaded environment.  Then again, that is unsurprising
>> as C++ does not yet officially incorporate support for
>> multi-threading.  Is there something deeper in IOStreams that
>> you consider to be thread-unsafe, or is it just the matter of
>> its global variables?
> 
> cout << a << b;
> 
> can't guarantee that a and b will be adjacent in the output. In contrast,
> 
> printf(format, a, b);
> 
> does give that guarantee. Moreover, that guarantee is not between 
> separate threads in the same process, it's between whole processes! 
> Guess which of the two is usable :o).

stringstream s;
s << a << b;
cout << s.str();

;-)

> Btw, does tango provide such a guarantee for code such as Cout(a)(b)? 
>  From the construct, my understanding is that it doesn't.

No.  There really isn't any way to do automatic locking with chained 
opCall barring the use of proxy objects or something equally nasty. 
Also, it hurts efficiency to always lock regardless of whether the user 
is performing IO in multiple threads.  The preferred method here is:

synchronized( Cout )
     Cout( a )( b )( c )();


Sean



More information about the Digitalmars-d mailing list