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: 103376,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Thread: 108717,a7c8692cac750b5e X-Google-Attributes: gid103376,gid115aec,gidf43e6,gid108717,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!blackbush.cw.net!cw.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Sun, 13 Mar 2005 05:37:36 +0100 From: Georg Bauhaus User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng,comp.programming Subject: Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)) References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <1110396477.596174.285520@o13g2000cwo.googlegroups.com> <112vb2t8eonuhed@corp.supernews.com> <1110422108.925127.54110@o13g2000cwo.googlegroups.com> <11329cb96h2p19f@corp.supernews.com> <113394jjvppao64@corp.supernews.com> <42329704$0$1096$9b4e6d93@newsread2.arcor-online.net> <1135sbpj9e9cd79@corp.supernews.com> In-Reply-To: <1135sbpj9e9cd79@corp.supernews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4233c357$0$1080$9b4e6d93@newsread2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 13 Mar 2005 05:36:39 MET NNTP-Posting-Host: b90f0289.newsread2.arcor-online.net X-Trace: DXC=a30>7mCD CTips wrote: > Georg Bauhaus wrote: > >> Anyway, here goes. > > > This is pretty good work. Thank you! >> C | Ada >> N R *T* TC *T* TC TU TUC >> ... >> ... >> 100000 2000 7.4 7.25 7.2 7.0 7.0 7.2 >> 200000 1000 7.38 7.26 7.22 6.9 6.8 7.1 > > > For some reason your numbers at the higher end are anamolous. The > checked code should not take less time than the unchecked code. There is > something else going on. I found this puzzling, too. I'll try some more combinations next week. > You're running on a 2-processor system, so you could be ping-ponging > between processors. Does the version of linux you are running have > processor affinity? Also, if you're running on an loaded system, this > would explain things. The system showed a load of 0.0 between tests, runlevel == 1, no jobs. I'll try again setting the affinity. > Ada is not faster- the results where Ada is faster are not trustworthy. > Replace the C checks with the alternate form, and run on an *unloaded* > machine. Well... To me, T TC T TC TU TUC >> 50000 4000 6.1 (6.4+) 6.7 6.1 6.4+- 5.9+- 7.1- >> 100000 2000 7.4 7.25 7.2 7.0 7.0 7.2 shows that apart from the 7.4/7.25 (C) and 7.2/7.0 (Ada) surprises in the TC columns (where both programs run faster with checks _on_) the unconstrained array version (Ada) appears indeed faster than anything else in this row, interpreting the stable 7.0 (TU) as less than all other stable timings in the 100000/2000 row. I agree that every number marked +- appears less trustworthy than the others, even though the reason is not clear. The two 200k arrays both almost fill the cache (256k PIII Coppermine), so maybe there is some "fuzzy" loading going on ... Perhaps between the procesors? I'll see next week. >> It takes a lot of time to really find out what >> and why. Still, you get fast code from either language front >> end, so if an Ada compiler will check more things at >> compile time, support more programming language, and you want >> your compiler to do this, it can be a plus. > > > And if you want performance, use C instead. In the current context I prefer to let the timings in both T columns favour neither language based on performance. Neither is really performing better than the other when no runtime checks have been added. So I get the same performance out of C or Ada, with an additional yield of either fewer or more compile time checks, respectively. Georg