From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8de7eedad50552f1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!fr.ip.ndsoftware.net!newsfeed.freenet.de!feed.news.tiscali.de!news.belwue.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada bench : count words Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <87vf7n5njs.fsf@code-hal.de> <423f5813$0$9224$9b4e6d93@newsread4.arcor-online.net> <18arnvu705ly4$.1wz6ybz1jt70y$.dlg@40tude.net> <1q9cx4jt7802s.k45m6mcntl87$.dlg@40tude.net> <460oxs2p0hbc.yjqxjeasx37r.dlg@40tude.net> <1spfhtlo4ya1w.1a8leo0bqclk8.dlg@40tude.net> Date: Sun, 27 Mar 2005 23:22:10 +0200 Message-ID: NNTP-Posting-Date: 27 Mar 2005 23:22:01 MEST NNTP-Posting-Host: 7b178979.newsread2.arcor-online.net X-Trace: DXC=7>__XD[6LHn;2LCVNVVa[ZlQni_A0?Z0TfkRELB X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:10048 Date: 2005-03-27T23:22:01+02:00 List-Id: 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