Re: Ada bench : count words

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 27 Mar 2005 22:14:04 +0200, jtg wrote:

> Dmitry A. Kazakov wrote:
>> 
>> BTW, I think that this challenge is wrong because it does not filter I/O
>> issue out. In real-life applications it is not Text_IO (or its equivalent
>> in any other language) which is the bottleneck. Text_IO could be 10 times
>> slower and still impose no or little problems, because string processing in
>> the true sense, is usually 1000 times slower.
>> 
> IMHO the challenge is OK. Look at the system commands (in UNIX). In
> many cases text I/O performance is crucial. But since
> existing commands are very fast, nobody even thinks about it.

Ah, you hit my sore spot! In my view this is the problem of bad design. It
is characteristic of UNIX which said has three mouse drives, one per
button, but only for UNIX. [ The famous idea of splitting an application
into a chain of tiny commands like wc, sort etc is attractive but
altogether wrong. There is no universal way to do it. Then what about pipes
overhead and need of multiple re-scans. I don't buy it, and scripting
languages too. ]

> Recently I had to write some simple programs in C (after years of pure
> Ada) and I/O performance was my biggest problem. I compared my I/O
> results with wc command and wc was substantially faster than my
> pure I/O! So I downloaded
> the code and looked into it. That was mess&magic. They must have
> spent much time to get really fast I/O, and they had a good
> reason for it.
> I think that instead of blaming the challenge we must face reality:
> this test indicates that existing implementation of Ada is worse than C
> in pure I/O applications (like system commands).

But people don't use wc, they do OpenOffice (I suppose it wasn't written in
awk! (:-)). The style of programming acceptable for wc would be a disaster
for a product like OpenOffice.

> Maybe instead of
> improving the program it would be better to look into the GNAT
> source and improve things there.

In my experience, GNAT always had bad performance, and not only in
Ada.Text_IO, which is a minor problem for the mentioned above reasons, but
in far more important parts. As for patching GNAT, well, maybe next time...
(:-)) Anyway Ada.Text_IO performance is not on the top of my list. I'd
better improve ADT, add full MI and MD, make T'Class for all types, tasks
and protected types tagged, allow multiple parties rendezvous etc. (:-))

> Or to notify GNAT team about the
> problem. It would not only give Ada better
> position in this challenge, but also speed up text I/O operations of
> all the programs compiled with future versions of GNAT.

If you are a paying customer of ACT, you can try... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de