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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 5b1e799cdb,3ef3e78eacf6f938 X-Google-Attributes: gid5b1e799cdb,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news3.google.com!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 30 Jul 2009 18:10:23 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 Newsgroups: comp.lang.scheme,comp.lang.ada,comp.lang.functional,comp.lang.c++,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? References: <2009a75f-63e7-485e-9d9f-955e456578ed@v37g2000prg.googlegroups.com> <0bdf3c02-0565-40e2-95cc-c7f5eb546313@2g2000prl.googlegroups.com> <7xmy6mzy0q.fsf@ruckus.brouhaha.com> <4a714308$0$30229$9b4e6d93@newsspool1.arcor-online.net> <48679a94-4ce4-422e-8656-56bb682b08c0@d15g2000prc.googlegroups.com> In-Reply-To: <48679a94-4ce4-422e-8656-56bb682b08c0@d15g2000prc.googlegroups.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: <4a71c5f0$0$31880$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 30 Jul 2009 18:10:24 CEST NNTP-Posting-Host: 76480687.newsspool3.arcor-online.net X-Trace: DXC=_X[KP8LNDe3_A0jCfgHO6>McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb9=QiA5SOF:V;;9OJDO8_SK6NSZ1n^B98i:b fft1976 schrieb: > On Jul 29, 11:51 pm, Georg Bauhaus bug.bauh...@maps.futureapps.de> wrote: >> fft1976 wrote: >>> On Jul 29, 7:48 pm, Paul Rubin wrote: >>>> fft1976 writes: >>>>>> Where'd you get that idea? >>>>> http://shootout.alioth.debian.org/u32/benchmark.php?test=allāŒ©=gna... >> Last time I looked, the Ada programs had not been >> updated to use Ada's concurrent types to express the same >> devide and conquer strategy, which seems to be allowed now... >> The reported speedups for some C versions of the programs >> can be used as an estimate of a statistical correction >> to the (still sequential) Ada performance. >> This then will explain why a 2x slowdown of Ada, >> when compared to C, is not a realistic estimate. > > Try again. The link above is for single-threaded code. My fault. I had more general observations in mind which don't apply here, sorry. So I have looked at the fasta program as an example. It has a relation of roughly 1:2 in running time comparing C (No.1) to Ada at Shootout. But the relation is easily improved without really changing the program: First, I could confirm the relation of 1:2 on a GNU/Linux machine. Two changes shifted the relation towards 6.3s to ~8s in favor of C, starting from 6.6s to ~12.5s (which confirms the ratio 1:2). Change 1: Add pragma Inline(Select_Random); I did this because it seemed like the C compiler would do just this. (Looking at the disassembly.) Have the Ada compiler inline, too. This made the Ada program run another 2s faster (i.e. down another 2s from ~10s after Change 2). Change 2: Turn off I/O in both programs. While this defeats the purpose, it shows where much of the difference comes from: This change accounted for about 2s (down from ~12.5s) for the Ada program and for about 0.3s (down from ~6.6s) for the C program. So the I/O part in C is obviously high speed on Unix, not surprisingly, and Ada.Text_IO is notoriously slow (since it is a lot like an even more blown up printf(3)). Conclusions (so far, if the above can be reproduced): A fair bit of Ada's disadvantage is remedied by using Inline; another drag is Text_IO which is indeed slow. Real world needs might (and will) consider I/O routines that use OS functions, much like C on Unix does, more or less. The seemingly shaky results (if confirmed) also let me think that without constant attention, the Shootout can give a wrong impression (for any language :). >> A second reason why Ada has dropped at the Shootout is >> that the systems they use have older interim (from the Ada >> point of view) GCCs that are known to be broken. >> This makes some perfectly normal Ada programs fail there. >> As the code is available and did not fail when it was >> first ranked, and does not fail when used with an apt >> compiler like GCC 4.3.x, the Shootout is just showing its >> information potential ;-) > > How would this explain Ada's slow speed? I don't understand you. In the overall rating, failing programs or missing programs used to add to where a language was rated IIRC?