The Computer Language Shootout Benchmarks

The Computer Language Shootout Benchmarks

[Martin Krischik]

Hello

Ada is currently missing 2 programs on the "The Computer Language Shootout
Benchmarks" [1].

I would not mind having a go. But before I start:

One test [2] needs a hash table implementation. The compiler used has
no Ada 2005 features so one need to add the implementation to the code
itself. Anybody can got a stand alone implementation? Or knows which
collections class lib could easily been torn apart?

The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
could bind to gmp - but I don't like the idea if pragma Import in the code.
Anybody got a native Ada solution?

The implementation missing are:

Martin

[1] http://shootout.alioth.debian.org/
[2]
http://shootout.alioth.debian.org/debian/benchmark.php?test=knucleotide&lang=all#about
[3]
http://shootout.alioth.debian.org/debian/benchmark.php?test=pidigits&lang=all#about

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[jimmaureenrogers]

Martin Krischik wrote:
> Hello
>
> Ada is currently missing 2 programs on the "The Computer Language Shootout
> Benchmarks" [1].
>
> I would not mind having a go. But before I start:
>
> One test [2] needs a hash table implementation. The compiler used has
> no Ada 2005 features so one need to add the implementation to the code
> itself. Anybody can got a stand alone implementation? Or knows which
> collections class lib could easily been torn apart?
>
> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
> could bind to gmp - but I don't like the idea if pragma Import in the code.

This is precisely why I have not found the motivation to complete those

two benchmarks.

Jim Rogers

Re: The Computer Language Shootout Benchmarks

[Gautier]

Martin Krischik:

> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
> could bind to gmp - but I don't like the idea if pragma Import in the code.
> Anybody got a native Ada solution?

Please look there:
   http://www.chez.com/bignumber/index.html
You have:
- 1 binding to GMP
- 4 native solutions
HTH
_______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: The Computer Language Shootout Benchmarks

[Tapio Kelloniemi]

Martin Krischik <krischik@users.sourceforge.net> wrote:
>Hello
>
>Ada is currently missing 2 programs on the "The Computer Language Shootout
>Benchmarks" [1].
>
>I would not mind having a go. But before I start:
>
>One test [2] needs a hash table implementation. The compiler used has
>no Ada 2005 features so one need to add the implementation to the code
>itself. Anybody can got a stand alone implementation? Or knows which
>collections class lib could easily been torn apart?

Since the compiler is most likely GNAT, there are always the
GNAT.[Dynamic_]HTable packages. I assume they are also faster than
Ada.Containers.Hashed_Maps would be.

-- 
Tapio

Re: The Computer Language Shootout Benchmarks

[Matthew Heaney]

Tapio Kelloniemi wrote:
>
> Since the compiler is most likely GNAT, there are always the
> GNAT.[Dynamic_]HTable packages. I assume they are also faster than
> Ada.Containers.Hashed_Maps would be.

And why do you assume that???

Re: The Computer Language Shootout Benchmarks

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> One test [2] needs a hash table implementation. The compiler used has
> no Ada 2005 features so one need to add the implementation to the code
> itself. Anybody can got a stand alone implementation? Or knows which
> collections class lib could easily been torn apart?

The latest versions of GCC have Ada 2005 support, and a full implementation of
the Ada 2005 container library.  You're sure the shootout people aren't using
the latest GCC version?  (You have to compile with -gnat05 of course.)

If you need a hashed map, then you can always use Charles, which compiles under
Ada95:

http://charles.tigris.org/

If you prefer an Ada95 version of the Ada 2005 container library, I can modify
the GCC sources to compile under Ada95 and add that to the Charles repository.

-Matt

Re: The Computer Language Shootout Benchmarks

[Tapio Kelloniemi]

"Matthew Heaney" <mheaney@on2.com> wrote:
>Tapio Kelloniemi wrote:
>>
>> Since the compiler is most likely GNAT, there are always the
>> GNAT.[Dynamic_]HTable packages. I assume they are also faster than
>> Ada.Containers.Hashed_Maps would be.
>
>And why do you assume that???

Because GNAT.[Dynamic_]HTable has been designed to be extremely efficient.
Note that this is just an assumption, I have not read the code of GNAT's
HTable implementation, but at least GNAT.Dynamic_Tables is more efficient
than Ada.COntainers.Vectors since it does not use controlled types, it allows
direct access to the data structure and it uses realloc to resize the table.
When Ada.Containers container is resized, new memory must be allocated, data
must be copied and the old memory must be freed. Realloc may avoid this.

However, my opinion is that Ada.Containers is much more convenient and also
safer.

-- 
Tapio

Re: The Computer Language Shootout Benchmarks

[Matthew Heaney]

Tapio Kelloniemi wrote:
> "Matthew Heaney" <mheaney@on2.com> wrote:
> >And why do you assume that???
>
> Because GNAT.[Dynamic_]HTable has been designed to be extremely efficient.

And why do you assume that Ada.Containers.Hashed_Maps aren't also
designed to be extremely efficient?  Why would the designer do it any
other way?


> Note that this is just an assumption, I have not read the code of GNAT's
> HTable implementation,

If you haven't read the sources, then how do you know?


> but at least GNAT.Dynamic_Tables is more efficient
> than Ada.COntainers.Vectors

But we were talking about Dynamic_Tables vs. Hashed_Maps.


> since it does not use controlled types,

A specious argument, since the only thing controlled types are used for
is to reclaim storage when the scope of the declaration of the
container object ends.  The fact that the hashed_map container type
privately derives from type Controlled has no bearing on the efficiency
of insertions, deletions, or searches.



> it allows
> direct access to the data structure

Again, this is a specious argument, since having access to the
underlying data structure is irrelevant.  It's direct access to an
element that's important.

The standard library provides something very close to direct access: it
allows in situ access to elements via Query_Element and Update_Element.


> and it uses realloc to resize the table.

Well obviously this will only work if the element type isn't
controlled.  So you're comparing apples to oranges, since the standard
containers must support any non-limited type, including controlled type
and discriminated types.


> When Ada.Containers container is resized, new memory must be allocated, data
> must be copied and the old memory must be freed. Realloc may avoid this.

This is all very confused.

In the case of the vector container, then yes, to expand the container
(that is, increase its capacity), then you must allocate a new, longer
internal array (assuming it's implemented that way), and then copy the
existing items onto the new array.

It is specious to argue that "realloc can avoid this," since you can't
use realloc to expand an array whose components are controlled or have
default initialization.  (Or to put it another way, you could use
realloc, but then you'd have to use compiler magic to perform
controlled actions.)

Furthermore, your argument ignores the fact the expansion of the vector
capacity is not done willy-nilly.  Expansion occurs in a specific way,
such that the *amortized* cost of insertion has a time complexity of
O(1).  Hard to beat that!  So the realloc argument is a red herring,
since you can't do any better then O(1).

The situation for hashed containers is a different.  When a hashed
container expands, then elements aren't copied, they are moved.  This
is distinctly unlike the case for vector.

A hashed container has an internal hash table, which is just an array
whose components are pointers to nodes, which hold an element and a
pointer to the next node in that bucket.  When you expand a hashed
container, you allocate a new buckets array, then re-hash elements from
the old buckets array onto the new one.  To be sure there is a cost for
this, but it's not because of copying of elements.

Again, realloc wouldn't help here, since you have to ensure that each
bucket is initialized to null (indicating that there are no elements in
that bucket).


> However, my opinion is that Ada.Containers is much more convenient and also
> safer.

And on that point we agree.

Note that I'm giving a tutorial on the standard container library in
Porto on 5 June.

Regards,
Matt

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

jimmaureenrogers@worldnet.att.net wrote:

> 
> Martin Krischik wrote:
>> Hello
>>
>> Ada is currently missing 2 programs on the "The Computer Language
>> Shootout Benchmarks" [1].
>>
>> I would not mind having a go. But before I start:
>>
>> One test [2] needs a hash table implementation. The compiler used has
>> no Ada 2005 features so one need to add the implementation to the code
>> itself. Anybody can got a stand alone implementation? Or knows which
>> collections class lib could easily been torn apart?
>>
>> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
>> could bind to gmp - but I don't like the idea if pragma Import in the
>> code.
> 
> This is precisely why I have not found the motivation to complete those
> two benchmarks.

And somehow I feel that one of those tests has been make to make debians
hash tables for C shine.

Also C cheats:

1) Thy don't check for ">THREE" as demanded but only for ">TH" making up for
a propper string compare. I think that Ada won't need that

2) They use a dynamicly growing buffer with an initial size large enough to
hold the hole dateset. This we can dupplicate using the old recursive
string concaternation with an initial string size just as big as C's so it
never goes into recursion.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

Matthew Heaney wrote:

> The latest versions of GCC have Ada 2005 support, and a full
> implementation of the Ada 2005 container library. ï¿œYou're sure the
> shootout people aren't using the latest GCC version? ￜ(You have to compile
> with -gnat05 of course.)

GNAT 3.4.3
GNAT 4.0.4 20060422 (prerelease) (Debian 4.0.3-2)

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

Tapio Kelloniemi wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>>Hello
>>
>>Ada is currently missing 2 programs on the "The Computer Language Shootout
>>Benchmarks" [1].
>>
>>I would not mind having a go. But before I start:
>>
>>One test [2] needs a hash table implementation. The compiler used has
>>no Ada 2005 features so one need to add the implementation to the code
>>itself. Anybody can got a stand alone implementation? Or knows which
>>collections class lib could easily been torn apart?
> 
> Since the compiler is most likely GNAT, there are always the
> GNAT.[Dynamic_]HTable packages. I assume they are also faster than
> Ada.Containers.Hashed_Maps would be.

I found them and I think they will do nicely.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

Matthew Heaney wrote:

>> Because GNAT.[Dynamic_]HTable has been designed to be extremely
>> efficient.
> 
> And why do you assume that Ada.Containers.Hashed_Maps aren't also
> designed to be extremely efficient? ï¿œWhy would the designer do it any
> other way?

Well, when the code is finished we can have a container shootout as well.
But for the main shootout it will be GNAT.HTable - it does the trick and it
is there (won't increase out lines of code rating).

Martin 
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[Tapio Kelloniemi]

"Matthew Heaney" <mheaney@on2.com> wrote:
>Tapio Kelloniemi wrote:
>> "Matthew Heaney" <mheaney@on2.com> wrote:
>> >And why do you assume that???
>>
>> Because GNAT.[Dynamic_]HTable has been designed to be extremely efficient.
>
>And why do you assume that Ada.Containers.Hashed_Maps aren't also
>designed to be extremely efficient?  Why would the designer do it any
>other way?

To support some Ada features (such as controlled types) or to increase safety 
with additional run-time checks. This is of course how a standard library 
implementation must behave, but some particular hash table implemetation could 
drop support for controlled types and suppress all checks, if such features 
woudn't be required (or were considered to be too expensive).

>> Note that this is just an assumption, I have not read the code of GNAT's
>> HTable implementation,
>
>If you haven't read the sources, then how do you know?

I expected that they had taken the same aggressive approach with Htables as 
with Tables, but diving into the code reveals that this is not the case (at 
least not with the Simple_Htable). However, the Static_Htable can be more 
efficient than Ada.Containers.Hashed_Maps, depending on the situation. Sorry 
for misinforming.

>> it allows
>> direct access to the data structure
>
>Again, this is a specious argument, since having access to the
>underlying data structure is irrelevant.  It's direct access to an
>element that's important.
>
>The standard library provides something very close to direct access: it
>allows in situ access to elements via Query_Element and Update_Element.

But if we want to get every microsecond out of it, though generally we don't 
want to.

>> and it uses realloc to resize the table.
>
>Well obviously this will only work if the element type isn't
>controlled.  So you're comparing apples to oranges, since the standard
>containers must support any non-limited type, including controlled type
>and discriminated types.

I was considering something that could be used in the shootout tests and I 
think that support for controlled types is not needed there. But this is now 
unrelevant since GNAT.HTable does not use realloc as I thought, so the only 
benefit gained by using GNAT.HTable is that it reduces the number of lines of 
code when there is no need to include the hash table implementation in the 
code (LOCs are also measured in shootout).

-- 
Tapio

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On Tue, 02 May 2006 21:14:19 +0200, Gautier wrote:
>Martin Krischik:
>
>> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
>> could bind to gmp [...]
>Please look there:
>   http://www.chez.com/bignumber/index.html
>You have:
>- 1 binding to GMP

That bignumbers webpage is out of date. It is of 2003, and by Jerome
Delcourt. GMP is of http://www.swox.com/gmp/.

I have fuller GMP bindings (that lack all types of arbitrary viral
licences [anyone got a website categorizing the different types that
neutralise threats?]):

  http://terratope.tigris.org/source/browse/terratope/trunk/cy/ (GMP)

  **  An initial investigation that is a standard preliminary before
      a wise comp.lang.ada might start to favour some debian.org
      webpage ***

I looked at the Debian shootout page

   http://shootout.alioth.debian.org/debian/ada.php
   "Ada 95 GNAT" (Debian Sempron)

and it seems all untrue. For example, the main table in the centre is
titled:

   "How many times faster or smaller are the Ada 95 GNAT programs than
          the corresponding C gcc programs?

   "GNAT x times better
   - gcc x times better"

So most of the numbers are nearly all negative.

Thus it is probable that the creator of the website wishes to present
himself/herself as observing that GNAT executables
   finish running before they start.

That gives a narrow to print out backtraces...

For a clarification, the "ada.php" webpage shows an image that
contains images of horizontal bars.

Of them I note:

  * none are labelled. However the first word on the webpage is 
   "Debian" (rather than, eg., "Linux").

  * Something is labelled in the plot: and that is the horizontal
   axis.  It has two labels that are not clarified:

      (a) "GNAT better" (on the right)
      (b) "gcc better" (on the left).

So what is the "-" symbol mean, in the text "- gcc times better".

Special reasoning skills are possibly needed to prevent modifying
scripts so that --sysroot is added to ld linker operations and then
the GNAT compiler is actually built under the FreeBSD emulator.
FreeBSD seems to be getting faster, and maybe the buildword is
less likely to crash too.

Here is the competing Windows "shootout" webpage:

   http://dada.perl.it/shootout/





>- 4 native solutions
>HTH
>_______________________________________________________________
>Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm

Craig Carey

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On Thu, 04 May 2006 14:01:24 +1200, Craig Carey wrote to comp.lang.ada:
>On Tue, 02 May 2006 21:14:19 +0200, Gautier wrote:
>>Martin Krischik [wrote]
...
>   "How many times faster or smaller are the Ada 95 GNAT programs than
>          the corresponding C gcc programs?
>
>   "GNAT x times better
>   - gcc x times better"
>
...
> That gives a narrow   to print out backtraces...
.                     ^ window


I considered that I may have made a mistake in my last message, by 
not considering that the figures in the table were found in this
way:

  Benchmark timing results for FSF GNAT and GCC C of unknown version,
   were T1 and T2.

  Compute   F = T1 / T2.
  The results displayed is:   (F  -  (1 / F))

Here is the page after the undefined data-massaging formula is applied
(the formula is not in the FAQ, meaning that debian programmers don't
frequently inquire about the origin of figures finding every compiler
except one to be not-best):

http://shootout.alioth.debian.org/debian/ada.php

| Program & Logs . .Faster . .Smaller: Memory Use . .Smaller: Code Lines
| binary-trees . . . . -1.8 . . . . . . -1.6 . . . . . . . . -1.2 . . .

So GNAt is slower than version ?.?.? Gcc and got a -1.8.

Using the F - 1/F finds that the figure ought be -1.17.

http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=gcc

| binary-trees benchmark | C gcc  | binary-trees full data
|  binary-trees C gcc program
|  N . . . . .Full CPU Time s . . . . Memory Use KB . . . . Code Lines
| 16 . . . . . . . . . . 4.12 . . . . . . . . 4,528 . . . . . . . . 80
|   contributed by Kevin Carson

http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=gnat&id=0

| binary-trees benchmark | Ada 95 GNAT  | binary-trees full data 
|  binary-trees Ada 95 GNAT program
|  N . . . . .Full CPU Time s . . . . Memory Use KB . . . . Code Lines
| 16 . . . . . . . . . . 7.21 . . . . . . . . 7,360 . . . . . . . . 99
| -- Contributed by Jim Rogers

Calculations:
   Full CPU Time:
      4.12 / 7.21 = 0.57143 ; 0.57143 - (1 / 0.57143) = -1.17856563
   Memory Use:
      4528 / 7360 = 0.61522 ; 0.61522 - (1 / 0.61522) = -1.01021
   Code Lines:
        80 / 99   = 0.80808 ; 0.80808 - (1 / 0.80808) = -0.42942124


The GNAT "pragma Suppress" improves GNAT's timing results by enough to
cause it to be used.

It is not clear why "gcc" has two names at the alioth website: "C gcc",
and "gcc". Ada is part of Gcc and use of svn can show that.

Concluding, the competitor to Ada found that its competitor was
boosted by +53%. (1.8/1.17 = 1.53846154). Though almost certainly an
attack on Ada, there was simply no admission of that, just a straight
face presentation of the bare facts...




Craig Carey













>So most of the numbers are nearly all negative.
>
>Thus it is probable that the creator of the website wishes to present
>himself/herself as observing that GNAT executables
>   finish running before they start.
>
>That gives a narrow to print out backtraces...
>
>For a clarification, the "ada.php" webpage shows an image that
>contains images of horizontal bars.
>
>Of them I note:
>
>  * none are labelled. However the first word on the webpage is 
>   "Debian" (rather than, eg., "Linux").
>
>  * Something is labelled in the plot: and that is the horizontal
>   axis.  It has two labels that are not clarified:
>
>      (a) "GNAT better" (on the right)
>      (b) "gcc better" (on the left).
>
>So what is the "-" symbol mean, in the text "- gcc times better".
>
>Special reasoning skills are possibly needed to prevent modifying
>scripts so that --sysroot is added to ld linker operations and then
>the GNAT compiler is actually built under the FreeBSD emulator.
>FreeBSD seems to be getting faster, and maybe the buildword is
>less likely to crash too.
>
>Here is the competing Windows "shootout" webpage:
>
>   http://dada.perl.it/shootout/
>
>
>
>
>
>>- 4 native solutions
>>HTH
>>_______________________________________________________________
>>Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
>
>Craig Carey

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

Martin Krischik wrote:

> jimmaureenrogers@worldnet.att.net wrote:
> 
>> 
>> Martin Krischik wrote:
>>> Hello
>>>
>>> Ada is currently missing 2 programs on the "The Computer Language
>>> Shootout Benchmarks" [1].
>>>
>>> I would not mind having a go. But before I start:
>>>
>>> One test [2] needs a hash table implementation. The compiler used has
>>> no Ada 2005 features so one need to add the implementation to the code
>>> itself. Anybody can got a stand alone implementation? Or knows which
>>> collections class lib could easily been torn apart?
>>>
>>> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
>>> could bind to gmp - but I don't like the idea if pragma Import in the
>>> code.
>> 
>> This is precisely why I have not found the motivation to complete those
>> two benchmarks.
> 
> And somehow I feel that one of those tests has been make to make debians
> hash tables for C shine.
> 
> Also C cheats:
> 
> 1) Thy don't check for ">THREE" as demanded but only for ">TH" making up
> for a propper string compare. I think that Ada won't need that
> 
> 2) They use a dynamicly growing buffer with an initial size large enough
> to hold the hole dateset. This we can dupplicate using the old recursive
> string concaternation with an initial string size just as big as C's so it
> never goes into recursion.

Current timing for Ada looks quite ok:

++ ./knucleotide

real    0m0.251s
user    0m0.184s
sys     0m0.024s
++ ./KNucleotide_1

real    0m0.359s
user    0m0.288s
sys     0m0.004s
++ ./KNucleotide_2

real    0m0.299s
user    0m0.240s
sys     0m0.008s

First is gcc c - as I have not got the same setup as the shootout I use the
c version to compare myself against.

The other two are two different version of Ada. Both are not finished and
missing freeing heap memory.

Interestingly enough the two version allmost identical - In the 2nd version
I just rearraged the package/procedure hierarchy using a package local to a
procedure for the main work. I did this because I wanted to experiment with
region based storrage (not implemented yet) and this theems is consistently
faster.

Want a sneed preview, here you find the code:

http://svn.sourceforge.net/viewcvs.py/wikibook-ada/trunk/demos/Source/Language_Shootout/

There is only one problem: LOC rating is terrible, worse there is.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[tmoran]

> There is only one problem: LOC rating is terrible, worse there is.
Do they give LOCs for APL versions?

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On Thu, 04 May 2006 18:48:04 +0200, Martin Krischik wrote:
>Martin Krischik wrote:
...
>> Also C cheats:

In another sub-thread of this thread I noted that the teste tresults of
the website you keep steadily promoting, could be fraudulent
throughtout and uncompromisingly secretively adjusted by 53% to favour
your favourite OS,

The C coder-community falsifications of findings seem to be big.

But there is a plan here....

>First is gcc c - as I have not got the same setup as the shootout

Oh, so you have not been falsifying data in e-mails to comp.lang.ada
yet ?. What could be worse about GNAT than slow speeds ...?

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

Craig Carey wrote:

> On Thu, 04 May 2006 18:48:04 +0200, Martin Krischik wrote:
>>Martin Krischik wrote:
> ...
>>> Also C cheats:
> 
> In another sub-thread of this thread I noted that the teste tresults of
> the website you keep steadily promoting,

I am not promoting them. I just hope to get good result for Ada. Please note
that a test not provided or failing gives worse result in the overall
result set. Besides it's fun.

> could be fraudulent 
> throughtout and uncompromisingly secretively adjusted by 53% to favour
> your favourite OS,
> 
> The C coder-community falsifications of findings seem to be big.
> 
> But there is a plan here....

Well, I found out today: The test date they provide are significantly
smaller then the test date they are actually going to us. And to my dismay:
with a full dataset the result look not so promising. Current results on an
AMD 64:

++ ./knucleotide

real    0m1.654s
user    0m1.352s
sys     0m0.096s
++ ./KNucleotide_1

real    0m2.508s
user    0m2.268s
sys     0m0.120s
++ ./KNucleotide_2

real    0m2.466s
user    0m2.200s
sys     0m0.148s
++ popd

>>First is gcc c - as I have not got the same setup as the shootout
> 
> Oh, so you have not been falsifying data in e-mails to comp.lang.ada
> yet ?. What could be worse about GNAT than slow speeds ...?

Of corse not. Why should I?

Martin

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[igouy]

Martin Krischik wrote:
> jimmaureenrogers@worldnet.att.net wrote:
>
> >
> > Martin Krischik wrote:
> >> Hello
> >>
> >> Ada is currently missing 2 programs on the "The Computer Language
> >> Shootout Benchmarks" [1].
> >>
> >> I would not mind having a go. But before I start:
> >>
> >> One test [2] needs a hash table implementation. The compiler used has
> >> no Ada 2005 features so one need to add the implementation to the code
> >> itself. Anybody can got a stand alone implementation? Or knows which
> >> collections class lib could easily been torn apart?
> >>
> >> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
> >> could bind to gmp - but I don't like the idea if pragma Import in the
> >> code.
> >
> > This is precisely why I have not found the motivation to complete those
> > two benchmarks.

>  And somehow I feel that one of those tests has been make to make debians
>  hash tables for C shine.

Get a life! :-)

k-nucleotide was worked out in complete ignorance of debian's hash
tables - and amazingly the C program uses the ancient hash table code
Doug Bagley did for the original shootout, here's the source

http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/shootout/bench/Include/simple_hash.h?cvsroot=shootout

If you want to add an Ada version that would be fine.

>
> Also C cheats:
>
> 1) Thy don't check for ">THREE" as demanded but only for ">TH" making up for
> a propper string compare. I think that Ada won't need that
>
> 2) They use a dynamicly growing buffer with an initial size large enough to
> hold the hole dateset. This we can dupplicate using the old recursive
> string concaternation with an initial string size just as big as C's so it
> never goes into recursion.
>
> Martin
> --
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[igouy]

Martin Krischik wrote:
> Martin Krischik wrote:
>
> > jimmaureenrogers@worldnet.att.net wrote:
> >
> >>
> >> Martin Krischik wrote:
> >>> Hello
> >>>
> >>> Ada is currently missing 2 programs on the "The Computer Language
> >>> Shootout Benchmarks" [1].
> >>>
> >>> I would not mind having a go. But before I start:
> >>>
> >>> One test [2] needs a hash table implementation. The compiler used has
> >>> no Ada 2005 features so one need to add the implementation to the code
> >>> itself. Anybody can got a stand alone implementation? Or knows which
> >>> collections class lib could easily been torn apart?
> >>>
> >>> The  other test [3] needs some Unbounded_Integer / BigInt etc. type. We
> >>> could bind to gmp - but I don't like the idea if pragma Import in the
> >>> code.
> >>
> >> This is precisely why I have not found the motivation to complete those
> >> two benchmarks.
> >
> > And somehow I feel that one of those tests has been make to make debians
> > hash tables for C shine.
> >
> > Also C cheats:
> >
> > 1) Thy don't check for ">THREE" as demanded but only for ">TH" making up
> > for a propper string compare. I think that Ada won't need that
> >
> > 2) They use a dynamicly growing buffer with an initial size large enough
> > to hold the hole dateset. This we can dupplicate using the old recursive
> > string concaternation with an initial string size just as big as C's so it
> > never goes into recursion.
>
> Current timing for Ada looks quite ok:
>
> ++ ./knucleotide
>
> real    0m0.251s
> user    0m0.184s
> sys     0m0.024s
> ++ ./KNucleotide_1
>
> real    0m0.359s
> user    0m0.288s
> sys     0m0.004s
> ++ ./KNucleotide_2
>
> real    0m0.299s
> user    0m0.240s
> sys     0m0.008s
>
> First is gcc c - as I have not got the same setup as the shootout I use the
> c version to compare myself against.
>
> The other two are two different version of Ada. Both are not finished and
> missing freeing heap memory.
>
> Interestingly enough the two version allmost identical - In the 2nd version
> I just rearraged the package/procedure hierarchy using a package local to a
> procedure for the main work. I did this because I wanted to experiment with
> region based storrage (not implemented yet) and this theems is consistently
> faster.
>
> Want a sneed preview, here you find the code:
>
> http://svn.sourceforge.net/viewcvs.py/wikibook-ada/trunk/demos/Source/Language_Shootout/
>
> There is only one problem: LOC rating is terrible, worse there is.

On Gentoo:Intel the source code GZip is used instead of LOC - some folk
were starting to write obfuscated code to lower the line count.

>
> Martin
> --
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[igouy]

Craig Carey wrote:
> On Thu, 04 May 2006 14:01:24 +1200, Craig Carey wrote to comp.lang.ada:
> >On Tue, 02 May 2006 21:14:19 +0200, Gautier wrote:
> >>Martin Krischik [wrote]
> ...
> >   "How many times faster or smaller are the Ada 95 GNAT programs than
> >          the corresponding C gcc programs?
> >
> >   "GNAT x times better
> >   - gcc x times better"
> >
> ...
> > That gives a narrow   to print out backtraces...
> .                     ^ window
>
>
> I considered that I may have made a mistake in my last message, by
> not considering that the figures in the table were found in this
> way:
>
>   Benchmark timing results for FSF GNAT and GCC C of unknown version,
>    were T1 and T2.
>
>   Compute   F = T1 / T2.
>   The results displayed is:   (F  -  (1 / F))

When F < 1 the result displayed is -1/F

Someone looking at GNAT vs C GCC will see the same numbers as someone
looking at  C GCC vs GNAT, but in gray with a different sign.

>
> Here is the page after the undefined data-massaging formula is applied
> (the formula is not in the FAQ, meaning that debian programmers don't
> frequently inquire about the origin of figures finding every compiler
> except one to be not-best):
>
> http://shootout.alioth.debian.org/debian/ada.php
>
> | Program & Logs . .Faster . .Smaller: Memory Use . .Smaller: Code Lines
> | binary-trees . . . . -1.8 . . . . . . -1.6 . . . . . . . . -1.2 . . .
>
> So GNAt is slower than version ?.?.? Gcc and got a -1.8.
>
> Using the F - 1/F finds that the figure ought be -1.17.
>
> http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=gcc
>
> | binary-trees benchmark | C gcc  | binary-trees full data
> |  binary-trees C gcc program
> |  N . . . . .Full CPU Time s . . . . Memory Use KB . . . . Code Lines
> | 16 . . . . . . . . . . 4.12 . . . . . . . . 4,528 . . . . . . . . 80
> |   contributed by Kevin Carson
>
> http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=gnat&id=0
>
> | binary-trees benchmark | Ada 95 GNAT  | binary-trees full data
> |  binary-trees Ada 95 GNAT program
> |  N . . . . .Full CPU Time s . . . . Memory Use KB . . . . Code Lines
> | 16 . . . . . . . . . . 7.21 . . . . . . . . 7,360 . . . . . . . . 99
> | -- Contributed by Jim Rogers
>
> Calculations:
>    Full CPU Time:
>       4.12 / 7.21 = 0.57143 ; 0.57143 - (1 / 0.57143) = -1.17856563
>    Memory Use:
>       4528 / 7360 = 0.61522 ; 0.61522 - (1 / 0.61522) = -1.01021
>    Code Lines:
>         80 / 99   = 0.80808 ; 0.80808 - (1 / 0.80808) = -0.42942124
>
>
> The GNAT "pragma Suppress" improves GNAT's timing results by enough to
> cause it to be used.
>
> It is not clear why "gcc" has two names at the alioth website: "C gcc",
> and "gcc". Ada is part of Gcc and use of svn can show that.
>
> Concluding, the competitor to Ada found that its competitor was
> boosted by +53%. (1.8/1.17 = 1.53846154). Though almost certainly an
> attack on Ada, there was simply no admission of that, just a straight
> face presentation of the bare facts...
>
>
>
>
> Craig Carey
>
>
>
>
>
>
>
>
>
>
>
>
>
> >So most of the numbers are nearly all negative.
> >
> >Thus it is probable that the creator of the website wishes to present
> >himself/herself as observing that GNAT executables
> >   finish running before they start.
> >
> >That gives a narrow to print out backtraces...
> >
> >For a clarification, the "ada.php" webpage shows an image that
> >contains images of horizontal bars.
> >
> >Of them I note:
> >
> >  * none are labelled. However the first word on the webpage is
> >   "Debian" (rather than, eg., "Linux").
> >
> >  * Something is labelled in the plot: and that is the horizontal
> >   axis.  It has two labels that are not clarified:
> >
> >      (a) "GNAT better" (on the right)
> >      (b) "gcc better" (on the left).
> >
> >So what is the "-" symbol mean, in the text "- gcc times better".
> >
> >Special reasoning skills are possibly needed to prevent modifying
> >scripts so that --sysroot is added to ld linker operations and then
> >the GNAT compiler is actually built under the FreeBSD emulator.
> >FreeBSD seems to be getting faster, and maybe the buildword is
> >less likely to crash too.
> >
> >Here is the competing Windows "shootout" webpage:
> >
> >   http://dada.perl.it/shootout/
> >
> >
> >
> >
> >
> >>- 4 native solutions
> >>HTH
> >>_______________________________________________________________
> >>Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
> >
> >Craig Carey

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On Fri, 05 May 2006 20:15:18 +0200, Martin Krischik wrote:
>Craig Carey wrote:

I wrote to Mr Isaac Gouy since he owns half of the
 shootout.alioth.debian.org website. The site seems to contain two
 sites of two persons, and Mr Gouy's "Intel P4" part of the website
 could not have the 53% adjustment since got compares the speeds of
 computer lanugages using 'seconds of time'.

>> On Thu, 04 May 2006 18:48:04 +0200, Martin Krischik wrote:
>>>Martin Krischik wrote:
...
>I am not promoting them.

...Grouping together two leader/webmasters that apparently can't agree
on the most convincing way to process timing figures ?.

A Haskell Usenet group noticed that there had been bias at that
website.

...
>> could be fraudulent 
>> throughtout and uncompromisingly secretively adjusted by 53%
 [to favour C].
...
>> Oh, so you have not been falsifying data in e-mails to comp.lang.ada
>> yet ?. What could be worse about GNAT than slow speeds ...?
>
>Of co[u]rse not. Why should I?

I am not retracting my suggestion because the falsification seems
real; Ada is not defended, C is not defended, you produced a bunch of
timing figures again ... which causes readers to wonder just how big
a pro-C bias has to get before your aim of tweaking GNAT Ada 95 code
collapses?. Could it be 2005% ? ... and Leroy said that there is no
shortage of ideas in ARG.

Here's is Mr Isaasc Gouy's e-mail address since it really looks like
comp.lang.ada lacks ideas.

   Isaac Gouy <igouy@yahoo.com>

Apologies for this, but I ask Mr Krischik to disclose the date when
he typed something into a Debian distr console.


Craig Carey

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On 6 May 2006 00:34:06 -0700, igouy@yahoo.com wrote:
...
>
>When F < 1 the result displayed is -1/F
>

The allegations of fraud have not been removed.

There is nothing to suggest that you are an authoritity on the
topic, and also the data does not provide any support, since
there is still a mismatch between the numbers.

The facts taken from the named webpages:

 Summary: -1.8

 Raw Data: 7.21 secs for GNAT, and 4.12 secs for C.

The bounds are:
   7.215 / 4.115, = 1.7533414
   7.205 / 4.125, = 1.7466666

The figure -1.8 is outside of the range.

Now there is resaon to suspect that the purpose for the Intel
'half' of the website may be unacceptable to an Ada community.

You didn't put enough words into the e-mail to actually make out
an argument. So far the topic here is one of getting rid of the
allegation that final results are falsified. This is not a
Haskell mailing list that hints the corruption might have been
a motive by pretending to have a leaked e-mail from a
benchmark website subvrting bribe-paying C consortium.

Re: The Computer Language Shootout Benchmarks

[igouy]

Craig Carey wrote:
> On 6 May 2006 00:34:06 -0700, igouy@yahoo.com wrote:
> ...
> >
> >When F < 1 the result displayed is -1/F
> >
>
> The allegations of fraud have not been removed.

It would be polite to check your assumptions before making public
accusations of fraud.

> There is nothing to suggest that you are an authoritity on the
> topic,

Read the FAQ
http://shootout.alioth.debian.org/gp4/faq.php#start

Read the acknowledgements
http://shootout.alioth.debian.org/gp4/miscfile.php?file=acknowledgements&title=acknowledgements

Read the copyright notice in the PHP code that generates the webpage
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/shootout/website/lib/headtohead.tpl.php?rev=1.42&content-type=text/x-cvsweb-markup&cvsroot=shootout

Read the PHP code that generates the webpage
if ($cpuValue<1 && $cpuValue!=0){ $cpuValue = -1/$cpuValue; }
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/shootout/website/lib/headtohead.tpl.php?rev=1.42&content-type=text/x-cvsweb-markup&cvsroot=shootout

> and also the data does not provide any support, since
> there is still a mismatch between the numbers.
>
> The facts taken from the named webpages:
>
>  Summary: -1.8
>
>  Raw Data: 7.21 secs for GNAT, and 4.12 secs for C.

More false assumptions - that is not "Raw Data" - those numbers are
being rounded to 2 places for display.

The calculation is not done with those numbers or with "Raw Data". The
calculation is done with data rounded to 3 places - these numbers 7.207
4.118 - you can find them data.csv
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/shootout/website/data/data.csv?rev=1.437&content-type=text/x-cvsweb-markup&cvsroot=shootout

>
> The bounds are:
>    7.215 / 4.115, = 1.7533414
>    7.205 / 4.125, = 1.7466666
>
> The figure -1.8 is outside of the range.

More false assumptions.

4.118 / 7.207 = 0.57138
-1 / 0.571 = -1.75012
rounded to 1 place for display = -1.8

>
> Now there is resaon to suspect that the purpose for the Intel
> 'half' of the website may be unacceptable to an Ada community.
>
> You didn't put enough words into the e-mail to actually make out
> an argument. So far the topic here is one of getting rid of the
> allegation that final results are falsified. This is not a
> Haskell mailing list that hints the corruption might have been
> a motive by pretending to have a leaked e-mail from a
> benchmark website subvrting bribe-paying C consortium.

The topic here is someone making malicious public accusations based on
nothing more than their own ignorance.

Re: The Computer Language Shootout Benchmarks

[tmoran]

> Current results on an AMD 64:
   I don't think that's multi-core, is it?  Ada tasking can make a nice
improvement on some benchmarks on a multi-core or multi-CPU machine.

Re: The Computer Language Shootout Benchmarks

[Martin Krischik]

igouy@yahoo.com wrote:

>> There is only one problem: LOC rating is terrible, worse there is.
> 
> On Gentoo:Intel the source code GZip is used instead of LOC - some folk
> were starting to write obfuscated code to lower the line count.

Indeed I am considering to use "gnat pretty -M200" before submitting. AFAIK
the RM states that 200 characters per line must be accepted by any Ada
compiler.

Martin 
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: The Computer Language Shootout Benchmarks

[Marc A. Criley]

igouy@yahoo.com wrote:

> The topic here is someone making malicious public accusations based on
> nothing more than their own ignorance.

Since I haven't seen you around on comp.lang.ada before, I'll clue you 
in on Craig Carey.  He is, unfortunately, the comp.lang.ada newsgroup's 
resident wacko.  While he does occasionally make some coherent postings 
regarding Ada, they're usually accompanied with various accusations 
about fraud, conspiracies, etc.

You'd be better off just plonking him.

Hope this helps.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: The Computer Language Shootout Benchmarks

[Craig Carey]

On Mon, 08 May 2006 08:24:46 -0500, "Marc A. Criley" wrote:
...
>Since I haven't seen you around on comp.lang.ada before, I'll clue you 
>in on Craig Carey.  He is, unfortunately, the comp.lang.ada newsgroup's 
>resident wacko.

Well, it is not for long that I shall be silent.

>-- Marc A. Criley
>-- McKae Technologies
>-- http://www.mckae.com/
   hedges