Author: Gerd Isenberg
Date: 01:48:48 09/14/03
Go up one level in this thread
<snip>
>>>I seriously doubt Gerd is aware how slow bitboards are and how difficult they
>>>are to use in complex software to improve for example ones evaluation function.
>>>
>>>Also i seriously doubt Gerd knows the penalty for % at the opteron.
>>>
>>>Regards,
>>>Vincent
>>
>>Vincent! You are playing games with me :-)
>>I seriously doubt thet you read my initial post.
>>
>>About opterons %:
>>
>>Athlon
>>DIV mreg16/32 VectorPath 24/40
>>MUL mreg32 VectorPath 6
>>
>>Opteron
>>DIV mreg16/32/64 VectorPath 23/39/71
>>MUL mreg64 Double! 5!
>>MUL mreg32 Double! 3!
>
>Yes i saw your post on this. No i am not ignoring you.
>I just post less to nonsense threads and i don't have time
>to read all postings at CCC, as a person needs to work in life too
>as you might very well know, that's all.
>
>Read the opteron manual again.
>
>It's 78 cycles for DIV if you measure at opteron. That's what opposing hardware
>engineers post as being the penalty for DIV at opteron.
>
>You can so to speak XOR the entire board for that.
>
>I am amazed that you are toying with this then.
>
>All discussions closed about the topic. Period.
>
Hmm... my post was about avoiding mod, but doing four 32-bit muls instead.
On opteron one may use two 64-bit muls for that purpose, like this:
mov rax, 0x00014FAC00053EB1 ; (((2^64)+49981-1)/49981)
mov rcx, [rbx.m_PawnBB + 0] ; white pawns
sub rcx, [rbx.m_PawnBB + 8] ; -black pawns
mov rbx, 49981
mul rcx
mov rax, rbx
mul rdx
sub rcx, rax
mov rax, rcx
sar rcx, 63 ; extend sign bit to mask
and rcx, rbx ; if ( modulus < 0 )
add rax, rcx ; modulus += 49981;
Not sure whether zobrist key hashing outperforms this routine,
specially if it is embedded inside some independent other stuff.
Anyway, it is negligible. As i already mentioned, i don't probe pawn hash,
if i got a hit from eval hash or from main transposition table.
>In makemove you have to XOR the pawns with the hashkey anyway with the position
>hashkey in order to use that for transposition.
>
>Instead of XORing that key you can of course use 2 keys.
>
>1 for pieces. 1 for pawns. To combine them for transposition table
>
>hashkeyhi = hashpawn.hi^hashkey.hi;
>hashkeylo = hashpawn.lo^hashkey.lo;
>
>
>I figured that out in 1995 already for DIEP.
>
Great - i did't got the idea with zobrist keys for pawn hashing.
In about 93 or 94 iirc, when implementing pawn hash tables the first time,
it was "obvious" to me to generate an index by some calculations from pawn
bitboards.
>One 2 years ago i also tried to measure the difference at K7 and P3 between
>storing the hashkey in 1 data element of 64 bits versus
> struct {
> unsigned int lo;
> unsigned int hi;
> }
>
>It was *significant* faster to store it in 2 x 32 bits.
>
Aha, but isn't a __int64 handled in that way internally on 32-bit machines?
>Perhaps time for a new experiment?
>
>Just measure with grown up compilers like visual c++, gcc.
>
>And when it releases intel c++ 8.0 i will give another shot, the
>current 7.1 they find bug after bug at itanium2. Internal compiler errors in
>fact even.
>
>"Aster experiences
> Some users have come across a number of compiler bugs. In those case the
>compilation terminates with a message reporting an internal compiler error.
>Currently version 7.1 of the intel compilers is installed on Aster. We were
>informed by SGI..."
>
>From: Newsletter SARA #3 september 2003
>
>Perhaps also visible at sara.nl, not sure those stuff they only got on paper.
>"don't disturb the outside world with the bad news" i bet is the idea.
>
>Well intel c++ doesn't even run parallel, so diep won't crash at world champs
>thanks to intel c++ compiler bugs, don't worry.
>
>Anyway, i am no longer amazed after the last few months that your projects do
>not have any objective that is similar to mine.
>
>See you at the world champs!
>
No - i do not attend there.
>>
>>so doing some (32bit) muls instead of one 64-bit mod seems
>>not to be a bad idea on opteron - if your tables are not power of two sized.
>
>Right.
>
>>See you in Leiden, where we may discuss about eval topics with bitboards ;-)
>>Gerd
>
>Not sure i join in Leiden. 2 weekends tournament organized at the last moment
>again. Invitation i got a week ago or so with the dates. Too late probably to
>arrange any kind of non-pc hardware.
>
>So what's the use of joining that tournament. It has zero use so short before
>world champs as there is no compare even remotely possible. Perhaps finding 1 or
>2 evaluation bugs that's all.
>
>My money is on Sjeng to win that tourney anyway.
>
Mine too - i guess Gian-Carlo comes up with an opteron box.
Regards,
Gerd
>I have to play in the belgium league at 19th october and operators always have
>made major errors and lost on average 20 to 25 minutes operating time a game,
>which for a slow searching program like diep at 90 0 is extra handicap apart
>from it of course tuned for 500 processors now.
>
>If i join it would be for fun again like ict3 was.
>
>Haven't decided yet.
>
>Hard choice to make.
>
>Perhaps i do both :)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.