stdio performance in tango, stdlib, and perl

[kris]

Walter Bright wrote:
> kris wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> kris wrote:
>>
>> [snip]
>>
>>>> Tango should still come out in front, although I have to say that 
>>>> benchmarks don't really tell very much in general i.e. doesn't mean 
>>>> much of anything important whether tango "wins" this or not (IMO)
>>>
>>>
>>>
>>> Why not? 
>>
>>
>> If tango were terribly terribly slow instead, then it would be cause 
>> for concern. If I have some program that needs to run faster I'll find 
>> a way to do just that; another reason why tango.io is fairly modular
> 
> 
> One problem with C++, as I mentioned before, is that the 
> straightforward, out of the box coding techniques don't get you fast 
> code. One of my goals with D is to fix that - the straightforward, 
> untuned code should get you most of the possible speed. I think the wc 
> benchmark shows this off.
> 
> Having to recode one's programs to speed them up is a big productivity 
> sapper. (The most egregious examples of this are people forced to recode 
> bits of their python/java/ruby app in C++.)
> 
> What makes stdio so worth the effort to speed up is because the payoff 
> is evident in 80-90% of the programs out there. Optimizing your own 
> program speeds up only your own program - optimizing the library speeds 
> everyone up.
> 
> Tango doesn't need to be terribly, terribly slow to be a cause for 
> concern. It only needs to be slower than C++/Perl/Java to be a problem, 
> because then it is a convenient excuse for people to not switch to D.
> 
> The conventional wisdom with C++ is that:
> 
> 1) C++ code is inherently faster than in any other language
> 2) iostream has a great design
> 3) iostream is uber fast because it uses templates to inline everything
> 
> Andrei's benchmark blows that out of the water. Even interpreted Perl 
> beats the pants off of C++ iostreams.


tango.io is not even optimized for this case (unlike the new Phobos 
code), and yet it is still faster than all others once the flush() is 
removed?

The earlier point is only that optimization can easily be premature and 
misguided; typically better to get a flexible and effective design 
instead. This should not have given anyone cause to assume, assert, or 
imply that tango is in any way inefficient -- apparently that needs to 
be clarified ;)

For the record, my perspective of "terribly, terribly slow" is pretty 
much where C++ landed in this particular case