Diablo 0.5.1 x64 version?

[beachknight]

Hi all,

I am looking for 64 bit version of Diablo 0.5.1
that will compete my 64 bit engines league.

TIA,

[Jim Ablett]

Hi all,

I am looking for 64 bit version of Diablo 0.5.1
that will compete my 64 bit engines league.

TIA,

Hi Harun,

Diablo gains nothing from 64 bit being a non-bitboard based engine.
I can compile a 64 bit version for you though if you still wish it.

Jim.

[JuLieN]

Hi Jim,

I have a question. Prédateur isn't bitboard based either, and the only 64bits-long variables are the hash keys. Wondering if that could speed it up, I compiled a 64bits version and noticed no visible speedup compared with the 32bits version. Is it a general case when only hash keys are involved (remember they do are updated at least one time, and often more than one time at each node of the tree, not counting their writing/reading from the hash tables and comparisons), or would it be a tip that I implemented them in a poor way?
(It's a FreePascal engine, btw).

[Mincho Georgiev]

Pawny issued the same. The only way I've managed to speed up with 1-2%
for the 64-bit version (which is highly insignificant) was to switch from -O3 for the x86 to -O2 for the x64 PGO compile.

[Jim Ablett]

Hi Jim,

I have a question. Prédateur isn't bitboard based either, and the only 64bits-long variables are the hash keys. Wondering if that could speed it up, I compiled a 64bits version and noticed no visible speedup compared with the 32bits version. Is it a general case when only hash keys are involved (remember they do are updated at least one time, and often more than one time at each node of the tree, not counting their writing/reading from the hash tables and comparisons), or would it be a tip that I implemented them in a poor way?
(It's a FreePascal engine, btw).

You could run a profiler on your engine code you could see how much time it spends in different parts of your program.
I wouldn't expect changing hash variables to 64 bit would make much speed difference.

I'll tell you what can give definite speed up in nps to non-bitboard engine,
and that it to change all possible ints to unsigned ints. I did this with the pawny src code and got big nps increase.

Jim.

[JuLieN]

Ah, thanks, I'll check again about that. I remember I had a nps improvement by switching some Integers into SmallInt, too, but maybe it's specific to Pascal. (SmallInt are signed 16bits int). I found this a bit weird, as modern CPUs should handle 32bits values as good as 16bits ones... But, again, maybe it depends on the FPC compiler.

[Mincho Georgiev]

Hi Jim,

I have a question. Prédateur isn't bitboard based either, and the only 64bits-long variables are the hash keys. Wondering if that could speed it up, I compiled a 64bits version and noticed no visible speedup compared with the 32bits version. Is it a general case when only hash keys are involved (remember they do are updated at least one time, and often more than one time at each node of the tree, not counting their writing/reading from the hash tables and comparisons), or would it be a tip that I implemented them in a poor way?
(It's a FreePascal engine, btw).

You could run a profiler on your engine code you could see how much time it spends in different parts of your program.
I wouldn't expect changing hash variables to 64 bit would make much speed difference.

I'll tell you what can give definite speed up in nps to non-bitboard engine,
and that it to change all possible ints to unsigned ints. I did this with the pawny src code and got big nps increase.

Jim.

I thought about that some time ago, but back then I've decided to postpone this a bit, maybe i should consider it again. Thanks, Jim!

[Jim Ablett]

Hi Jim,

I have a question. Prédateur isn't bitboard based either, and the only 64bits-long variables are the hash keys. Wondering if that could speed it up, I compiled a 64bits version and noticed no visible speedup compared with the 32bits version. Is it a general case when only hash keys are involved (remember they do are updated at least one time, and often more than one time at each node of the tree, not counting their writing/reading from the hash tables and comparisons), or would it be a tip that I implemented them in a poor way?
(It's a FreePascal engine, btw).

You could run a profiler on your engine code you could see how much time it spends in different parts of your program.
I wouldn't expect changing hash variables to 64 bit would make much speed difference.

I'll tell you what can give definite speed up in nps to non-bitboard engine,
and that it to change all possible ints to unsigned ints. I did this with the pawny src code and got big nps increase.

Jim.

I thought about that some time ago, but back then I've decided to postpone this a bit, maybe i should consider it again. Thanks, Jim!

Hi Mincho,

These are the important files in Pawny to change from int to unsigned int. Changes in other files were found to be of negative effect or
even detrimental to speed >

Code: Select all

'eval.c'
'endev.c'
'movegen.c'
'io.c'
'tt.c'

By the way your windows compiles are very fast.
The only way I could make faster compiles was to change ints to unsigned.

Jim.

[Mincho Georgiev]

Thanks again, Jim! I will look into that. It appears that the warnings from the intel documentation sometimes are justified. In x86, O3 is doing the best job, in x64 however, O3 hurts performance exactly how this possibility is described by intel. This is source-code specific though and it is valid only in my case i guess. I.E. -O3 for x86, -O2 for x64 PGO's.

[beachknight]

Hi all,

I am looking for 64 bit version of Diablo 0.5.1
that will compete my 64 bit engines league.

TIA,

Hi Harun,

Diablo gains nothing from 64 bit being a non-bitboard based engine.
I can compile a 64 bit version for you though if you still wish it.

Jim.

Yep. I wish. Thank you.

Apart from only one group, I'll not test 32 bit engines to save
computer time.

Best,