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-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 31 Jul 2009 13:13:27 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
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>
 	<h4qvgd$j4t$1@aioe.org>
 <0bdf3c02-0565-40e2-95cc-c7f5eb546313@2g2000prl.googlegroups.com>
 	<7xmy6mzy0q.fsf@ruckus.brouhaha.com>
 <c23ffb32-27f2-4190-a10c-e2ce5cb9359b@p10g2000prm.googlegroups.com>
 	<4a714308$0$30229$9b4e6d93@newsspool1.arcor-online.net>
 <48679a94-4ce4-422e-8656-56bb682b08c0@d15g2000prc.googlegroups.com>
 	<4a71c5f0$0$31880$9b4e6d93@newsspool3.arcor-online.net>
 <8d2fb978-19d3-46fb-baf3-4e82b5a96ac9@d15g2000prc.googlegroups.com>
 <878534cf-fc84-49b8-af29-78446bf6fbd4@i18g2000pro.googlegroups.com>
In-Reply-To: 
 <878534cf-fc84-49b8-af29-78446bf6fbd4@i18g2000pro.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4a72d1d8$0$31876$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 31 Jul 2009 13:13:28 CEST
NNTP-Posting-Host: 0db0386d.newsspool3.arcor-online.net
X-Trace: 
 DXC=d_0YBCGW0Y3NTD<CL>55K=McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb932LghY[]J15;9OJDO8_SK6NSZ1n^B98i:0I0K<IK\Ub8
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.scheme:6241 comp.lang.ada:7481
 comp.lang.functional:2570 comp.lang.c++:48804 comp.programming:12192
Date: 2009-07-31T13:13:28+02:00
List-Id: <comp.lang.ada>

fft1976 schrieb:
> On Jul 30, 10:59 am, Isaac Gouy <igo...@yahoo.com> wrote:
> 
>> "shaky results"? Didn't you confirm those results yourself?
> 
> Perhaps he is referring to I/O being the bottleneck. I have to say, if
> this is true, it undermines the usefulness of the benchmark to me.

I/O and a few other things are necessrily changing over time,
affecting (perceived) results.  Without intending any complaint:
programs like the fine tests presented at Shootout will
almost inevitably produce some variation along
several dimensions, and this should be expected:

- compilers change

- system libraries/services change

- I/O routines, string processing, matrix handling and
  more are different between languages, and they are not
  always srictly isolated into the test programs.
  If someone wanted to do this kind of specific comparison,
  different programs might profit from slightly different design
  guidelines than those you get for free at the Shootout.

- interpretation of result is correspondingly brittle

An example case is asking (or not) which specific part of a
program is causing its overall running time.

When changing the regex-dna program for Ada some
time ago, I noticed that the GNAT's Spitbol pattern matching
is just as fast as the other fast pattern matching specialists
at the time.  However, the Ada program gets really busy when
reassembling the result string.  So the less astute human
reader might (wrongly) interpret the regex-dna test result as
indication that pattern matching using Ada is not that fast.

Right now the same regex-dna program is failing on the
new Shootout systems; I suspect that the ubiquituous stack size
thing of newer GCCs may be causing this (dictating that stack frames
should be small, i.e. for non-Pascal languages, IIUC);
$ ulimit -s is only partly helpful.  I'm looking into this for the
knuleotide test; a patch and more on the latter in c.l.ada.