Toga (not derivates like Grapefruit etc.) : only 32 bit?

[Norbert Raimund Leisner]

Hello together,

does anybody know (maybe some experts from CEGT, CCRL) if Toga 1.4.1 / 3.1.2 and others (not derivates like Grapefruit ....) exists as "pure" 64-bit-versions or were these UCI engines only created for 32-bit? I ask this question because the "Toga family" is a little bit difficult to survey. Thanks!

Best wishes,
Norbert

[Marc Lacrosse]

There have been some 64-bits compiles of some of these Toga versions but they are a little weaker than their 32-bits counterparts even under 64-bits windows.
Toga does not benefit from the 64-bit compiles because it is not bitbase-based.
So you should better use the 32-bits versions even under 64-bits OS (XP64 or Vista64).

Marc

[bob]

There have been some 64-bits compiles of some of these Toga versions but they are a little weaker than their 32-bits counterparts even under 64-bits windows.
Toga does not benefit from the 64-bit compiles because it is not bitbase-based.
So you should better use the 32-bits versions even under 64-bits OS (XP64 or Vista64).

Marc

I would still think 64 bit would be faster. You get an extra 8 general-purpose registers which gives the compiler a lot more room to optimize by keeping important things in registers rather than using temp memory variables to hold them...

[Dirt]

I would still think 64 bit would be faster. You get an extra 8 general-purpose registers which gives the compiler a lot more room to optimize by keeping important things in registers rather than using temp memory variables to hold them...

Testing has shown that 64 bit compiles are slower. Perhaps that will change with different processors and compilers, but while the best speed is from 32 bit compiles then that's what people should use.

[pedrox]

In my case the 64-bit version is a 2-3% slower than 32-bit.

[Gian-Carlo Pascutto]

I would still think 64 bit would be faster. You get an extra 8 general-purpose registers which gives the compiler a lot more room to optimize by keeping important things in registers rather than using temp memory variables to hold them...

As well as pushing more things out of cache because of bigger pointers and bigger code size

Loads from L1 are almost free in out of order processors. Just see Nehalem where it was worthwhile to increase L1 latency to 4 clocks and it's still faster than Core 2.

[bob]

I would still think 64 bit would be faster. You get an extra 8 general-purpose registers which gives the compiler a lot more room to optimize by keeping important things in registers rather than using temp memory variables to hold them...

As well as pushing more things out of cache because of bigger pointers and bigger code size

Loads from L1 are almost free in out of order processors. Just see Nehalem where it was worthwhile to increase L1 latency to 4 clocks and it's still faster than Core 2.

All I can state with certainty is that for every test case I have tried, 64 bit was faster. And this does not include just chess programs. Yes code gets a bit bigger. But I do not believe this offsets the advantage of having another 8 registers which eliminates lots of memory temporaries and some cache replacements that result from that. The last test was a LU factorization program on the Nehalem we had and the 64 bit compile was faster. I don't remember exact numbers, but we were simply checking this (using intel 32 bit and 64 bit compiler versions) to see how things looked.