Hello,

I am now doing to project in part comparing Architectures and such. I have been using lots of benchmarks with different compiler options running i386, i686, AMD64 all using linux SUSE 10, when possible I have been replicating the test in Windows, (oh, and Linux is about 3-7% faster depending on Actual Bench run.)

It would be great if someone could compile this app for ARM so I could give it a go on my 5500. (it should come up with a horrible number with this Bench mark on ARM as this bench uses 64 bit Division.) As most of the benchmarks i have tried are really slow on the 5500, math is seriously slow on ARM.

http://homepages.cwi.nl/~tromp/c4/fhour.html

more specifically this file: http://homepages.cwi.nl/~tromp/c4/Fhourstones.zip

with this command: gcc -O3 SearchGame.c

I have a Zaurus 5500 Running Crow rom with 64 meg ram option.

(note: dont try to run unless you have a swap file as this App requires about 64 MB RAM)

Oh for those that are interested:

Run on AMD64 3200+ 512 MB Ram SUSE 10 64 bit System (has 32 bit compatability)
Compiled using GCC 4.0.2
32 Bit Executable: 2778.6 Kpos/sec
64 Bit Executable: 5221.4 Kpos/sec
also running the 32bit on a 32 bit SUSE OS vs 32 bit on a 64 bit SUSE OS was no diffrent.

This is one of the only applications that I have tried that actually almost doubles performance when compiled as a 64 bit vs 32 Bit. The writer of the application said that the extra registers in the AMD64 chip can be used for the 64Bit division when compiled as 64 bit.

If someone could compile this and forword me the binary, I would be great. Thanks.

-Daniel

Compiled with a 2.95.3 version of GCC.

Hopefully it'll work on your machine.

Cheers,


Si

Thank you lardman! I will try to run today...

later

Ok, It does run ok, Needed to enable a very large swap file for it to work as it uses about 66 MB of ram, I didnt have my power cable, so i had to kill the run before it finished due to weak battery, I will post the benchmark number tonight.

later

If you've had to use a large swap file I wonder whether your benchmark result is worthwhile (I wonder if it will be severely slowed by the swap performance).

What part of the performance are you trying to benchmark?

There are other benchmarks available (for example the ones in this post: http://www.oesf.org/forums/index.php?showtopic=3451&hl=)


Si

I was initially worried about that, but with a large swap enabled, it basically pshed out most of the memory the other apps were using, as the benchmark allocates 66+/- MB of ram, but seems to access about 37 MB at a time, I am using the Crow rom with 64 MB available, so I think its pretty accurate.

I have used some of the other benchmarks, but thanks for the link. I am interested in this benchmark in particular because of the 64 bit division that is implemented.

later

slow...

Run on AMD64 3200+ 512 MB Ram SUSE 10 64 bit System (has 32 bit compatability)
Compiled using GCC 4.0.2
32 Bit Executable: 2778.6 Kpos/sec
64 Bit Executable: 5221.4 Kpos/sec
also running the 32bit on a 32 bit SUSE OS vs 32 bit on a 64 bit SUSE OS was no diffrent.

Run on Zaurus 5500 64 MB ram, 70 MB swap on CF card.
lardman's compile: 93 Kpos/sec

If it floating point division or integer?

Si

I had the same question.

This is an email responce from other questions I had asked John.

This is from the creator of the code:

John Tromp
to me
More options Mar 9
hi Daniel,

> From your site: "By default, it uses a 64Mb transposition table with the
> twobig replacement strategy. Positions are represented as 64-bit
> bitboards, and the hash function is computed using a single 64-bit
> modulo operation, giving 64-bit machines a slight edge. The alpha-beta

> it runs twice as fast on my machine with 64 bit code vs 32 bit code.

The word "slight" above can be a bit of an understatement.
Apparently, trying to do 64 bit operations 32-bit at a time
incurs a lot more overhead than the simple factor of 2 suggests.
This is particularly true for 64 bit division, which requires many
32 bit operations to implement. Another contributing factor is
that activating the 64-bit extensions also gives you access to
a bigger register set.

> The 64 bit version is way faster. I was amazed. Using the same compiler
> options and machines with other benchmarks and applications and such, i
> usually only see a 5-14% increase in speed.
> I would like to understand why your benchmark is so much faster on the
> 64 bit than in 32 bit mode.

maybe Fhourstones is pretty unique in using 64 bit modulo operations...





And i had no idea what a modulo operation was until I decided to look it up:

http://en.wikipedia.org/wiki/Modular_arithmetic
So it is using Floating point.

Its also very interesting as to how slow this app is on my 1.25 GHz Mini Mac.

-Daniel

OK, UPdate from John, flourstones does not use floating point math, only integer math...

I am sooooo confused!!!, but he did tell me how to modify the code for it to fit in smaller amounts of Ram (the default is 64 MB table, he told me what to change to get it to only use 41 mb of ram which should fit fine w/o swap space), I may edit the code and upload it, if you want to compile it again, I am curious to see if it speeds up any if the swap file was slowing it down.

later

I'm happy to compile it again if you want.

I'd say you should probably go for a different benchmark method though, one that doesn't require these large tables (that are just part of the benchmark afaict) - why not modify it to just continuously perform some operations and not store the data, that way you'll eliminate the swap (and memory allocation time) issues completely.


Si