Over the past couple of weeks Walter and I have worked on improving the stdio module, following my shocking discovery that its performance was inadequate for any amount of serious coding. To say nothing about the lack of the input routines readf, readln, etc.

The good news is that Walter and myself have improved stdio's reading performance by an order of magnitude when compared to a naive implementation using fgetc(). Now reading is almost as fast as C would allow you, beats Perl and C++, (Perl is harder to beat than C++), while writef* is still suboptimal (but write without "f" is fast because it forwards to the C routine).

I was actually surprised that nobody seems to have discovered the abysmal performance of the writef family. If they did, they would have likely posted reports on this newsgroup.

This ate a lot of time measuring, testing, and optimizing. So I have a question - has anyone verified that Tango's I/O performance is up to snuff? I see it imposes the dynamic-polymorphic approach, and unless there was some serious performance work going on, it's possible it's even slower than stdio.


Thanks,

Andrei

Andrei Alexandrescu (See Website For Email) wrote:

> This ate a lot of time measuring, testing, and optimizing. So I have a question - has anyone verified that Tango's I/O performance is up to snuff? I see it imposes the dynamic-polymorphic approach, and unless there was some serious performance work going on, it's possible it's even slower than stdio.

If you have actually tested Tango IO and finds it to be slower than
the "new" stdio, then this would be interesting to know, and also the test
harness in use. If not, I find your suggestive tone above to be rather
rude, given the time put into making Tango IO as good as possible. If the
IO in Phobos has been as slow as you say, I highly doubt that Tango has
been in similar ranges, given that it obviates C IO by going directly to
the OS via a buffer.

Now, if you have tested that Tango's IO is slower than Phobos, then maybe you could spend some time helping to improve it too? Your approach above is rather unconstructive in an overall fashion.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> This ate a lot of time measuring, testing, and optimizing. So I have a
>> question - has anyone verified that Tango's I/O performance is up to
>> snuff? I see it imposes the dynamic-polymorphic approach, and unless
>> there was some serious performance work going on, it's possible it's
>> even slower than stdio.
> 
> If you have actually tested Tango IO and finds it to be slower than
> the "new" stdio, then this would be interesting to know, and also the test
> harness in use. If not, I find your suggestive tone above to be rather
> rude, given the time put into making Tango IO as good as possible. If the
> IO in Phobos has been as slow as you say, I highly doubt that Tango has
> been in similar ranges, given that it obviates C IO by going directly to
> the OS via a buffer.
> 
> Now, if you have tested that Tango's IO is slower than Phobos, then maybe
> you could spend some time helping to improve it too? Your approach above is
> rather unconstructive in an overall fashion.

This is a misunderstanding. To date I haven't downloaded Tango.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:

> Lars Ivar Igesund wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>> 
>>> This ate a lot of time measuring, testing, and optimizing. So I have a question - has anyone verified that Tango's I/O performance is up to snuff? I see it imposes the dynamic-polymorphic approach, and unless there was some serious performance work going on, it's possible it's even slower than stdio.
>> 
>> If you have actually tested Tango IO and finds it to be slower than
>> the "new" stdio, then this would be interesting to know, and also the
>> test harness in use. If not, I find your suggestive tone above to be
>> rather rude, given the time put into making Tango IO as good as possible.
>> If the IO in Phobos has been as slow as you say, I highly doubt that
>> Tango has been in similar ranges, given that it obviates C IO by going
>> directly to the OS via a buffer.
>> 
>> Now, if you have tested that Tango's IO is slower than Phobos, then maybe you could spend some time helping to improve it too? Your approach above is rather unconstructive in an overall fashion.
> 
> This is a misunderstanding. To date I haven't downloaded Tango.

Then you should before making any sorts of comments in this vein. Maybe you even should have compared Tango's IO performance to Phobos' prior to making such huge efforts to improve on it (Phobos IO)?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>>> This ate a lot of time measuring, testing, and optimizing. So I have a
>>>> question - has anyone verified that Tango's I/O performance is up to
>>>> snuff? I see it imposes the dynamic-polymorphic approach, and unless
>>>> there was some serious performance work going on, it's possible it's
>>>> even slower than stdio.
>>> If you have actually tested Tango IO and finds it to be slower than
>>> the "new" stdio, then this would be interesting to know, and also the
>>> test harness in use. If not, I find your suggestive tone above to be
>>> rather rude, given the time put into making Tango IO as good as possible.
>>> If the IO in Phobos has been as slow as you say, I highly doubt that
>>> Tango has been in similar ranges, given that it obviates C IO by going
>>> directly to the OS via a buffer.
>>>
>>> Now, if you have tested that Tango's IO is slower than Phobos, then maybe
>>> you could spend some time helping to improve it too? Your approach above
>>> is rather unconstructive in an overall fashion.
>> This is a misunderstanding. To date I haven't downloaded Tango.
> 
> Then you should before making any sorts of comments in this vein. Maybe you
> even should have compared Tango's IO performance to Phobos' prior to making
> such huge efforts to improve on it (Phobos IO)?

Could you please put the gun down. Sheesh. Which comments? What vein? It was a question. I simply asked whether there has been performance work on Tango's I/O, without having any prior experience with it. I don't see reason for anyone to get offended about that.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> 
> Could you please put the gun down. Sheesh. Which comments? What vein? It was a question. I simply asked whether there has been performance work on Tango's I/O, without having any prior experience with it. I don't see reason for anyone to get offended about that.

I think the Tango IO package is all about only paying for what you need.  This is one reason for its modular design.  That said, I don't think anyone has ever done a performance comparison with C, Phobos, etc.  If you're inclined to do so, I would love to see the results.


Sean

Andrei Alexandrescu (See Website For Email) wrote:

> Lars Ivar Igesund wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>>> This ate a lot of time measuring, testing, and optimizing. So I have a question - has anyone verified that Tango's I/O performance is up to snuff? I see it imposes the dynamic-polymorphic approach, and unless there was some serious performance work going on, it's possible it's even slower than stdio.
>>>> If you have actually tested Tango IO and finds it to be slower than the "new" stdio, then this would be interesting to know, and also the test harness in use. If not, I find your suggestive tone above to be rather rude, given the time put into making Tango IO as good as possible. If the IO in Phobos has been as slow as you say, I highly doubt that Tango has been in similar ranges, given that it obviates C IO by going directly to the OS via a buffer.
>>>>
>>>> Now, if you have tested that Tango's IO is slower than Phobos, then maybe you could spend some time helping to improve it too? Your approach above is rather unconstructive in an overall fashion.
>>> This is a misunderstanding. To date I haven't downloaded Tango.
>> 
>> Then you should before making any sorts of comments in this vein. Maybe you even should have compared Tango's IO performance to Phobos' prior to making such huge efforts to improve on it (Phobos IO)?
> 
> Could you please put the gun down. Sheesh. Which comments? What vein? It was a question. I simply asked whether there has been performance work on Tango's I/O, without having any prior experience with it. I don't see reason for anyone to get offended about that.

No, I was not offended (not easily done), but I did find your wording suggestive. And you did give the impression that you had _some_ knowledge of Tango.

As for that exact question; yes, performance is an important facet of Tango, IO likewise. Slow IO in Tango would be a defect. And it would be nice to have an unbiased comparison of the two.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>>> Lars Ivar Igesund wrote:
>>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>>
>>>>>> This ate a lot of time measuring, testing, and optimizing. So I have a
>>>>>> question - has anyone verified that Tango's I/O performance is up to
>>>>>> snuff? I see it imposes the dynamic-polymorphic approach, and unless
>>>>>> there was some serious performance work going on, it's possible it's
>>>>>> even slower than stdio.
>>>>> If you have actually tested Tango IO and finds it to be slower than
>>>>> the "new" stdio, then this would be interesting to know, and also the
>>>>> test harness in use. If not, I find your suggestive tone above to be
>>>>> rather rude, given the time put into making Tango IO as good as
>>>>> possible. If the IO in Phobos has been as slow as you say, I highly
>>>>> doubt that Tango has been in similar ranges, given that it obviates C
>>>>> IO by going directly to the OS via a buffer.
>>>>>
>>>>> Now, if you have tested that Tango's IO is slower than Phobos, then
>>>>> maybe you could spend some time helping to improve it too? Your
>>>>> approach above is rather unconstructive in an overall fashion.
>>>> This is a misunderstanding. To date I haven't downloaded Tango.
>>> Then you should before making any sorts of comments in this vein. Maybe
>>> you even should have compared Tango's IO performance to Phobos' prior to
>>> making such huge efforts to improve on it (Phobos IO)?
>> Could you please put the gun down. Sheesh. Which comments? What vein? It
>> was a question. I simply asked whether there has been performance work
>> on Tango's I/O, without having any prior experience with it. I don't see
>> reason for anyone to get offended about that.
> 
> No, I was not offended (not easily done), but I did find your wording
> suggestive. And you did give the impression that you had _some_ knowledge
> of Tango.
> 
> As for that exact question; yes, performance is an important facet of Tango,
> IO likewise. Slow IO in Tango would be a defect. And it would be nice to
> have an unbiased comparison of the two.

Excellent! I have collected some data on stdio and a couple of baselines, and I'll install Tango now. In fact I've already hit a hitch:  README.txt sends the reader to http://dsource.org/projects/tango/wiki/TopicInstallTango which says one should run ./lib/install-dmd.sh, which is not to be found in the distribution... probably I'll need to set an account on dsource.org and ask there.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Could you please put the gun down. Sheesh. Which comments? What vein? It was a question. I simply asked whether there has been performance work on Tango's I/O, without having any prior experience with it. I don't see reason for anyone to get offended about that.

Phobos' std.stdio's performance sucked because I'd never done a benchmark of it. It was one of those things I cranked out because something was needed, intending to go back and optimize later but never did...

Anyhow, Andrei's and my experiments with stdio once again showed that designing something to be fast and it actually being fast are two very different things. We were misled several times by our own preconceived notions about what was cheap and what was expensive. Nothing beats actually running a benchmark.

The benchmarks we used were all trivial programs, like a loop that just reads its stdin, line by line, and then stuffing a 30 Mb file down its maw. For example:

import std.stdio;

int main()
{
    char[] buf;
    while (readln(stdin, buf))
     { }
    return 0;
}

Yes, readln() will be in the next update.

Our benchmarking also suggested a couple performance related improvements to the gc interface, which I am working on.

Andrei Alexandrescu (See Website For Email) wrote:

> Over the past couple of weeks Walter and I have worked on improving the stdio module, following my shocking discovery that its performance was inadequate for any amount of serious coding. To say nothing about the lack of the input routines readf, readln, etc.

It's excellent news that std.stdio is finally getting revamped!
Hopefully you were able to make some use of our previous code
and suggestions, from the discussions held earlier (in 2005).

> I was actually surprised that nobody seems to have discovered the abysmal performance of the writef family. If they did, they would have likely posted reports on this newsgroup.

I'm afraid that at least some were more worried about the missing
features initially, and figured that performance would come "later".
Or even that one should use the std.c.stdio functions instead...

For the greatest of times, printf was the recommended output method.
(for instance, looking at "hello.d" in DMD 1.009 shows printf use.
Looking at the "pi.d" example, and it shows using using sscanf ?)

BTW: I don't think there is anything wrong with using "C" I/O routines,
on the contrary it is very useful when quickly porting programs over,
but it does suggest that "D" I/O methods in Phobos were not up to it ?

--anders