Author: Vincent Diepeveen
Date: 16:43:33 09/13/03
Go up one level in this thread
On September 13, 2003 at 11:22:39, Gerd Isenberg wrote:
>On September 13, 2003 at 10:10:17, Vincent Diepeveen wrote:
>
>>On September 12, 2003 at 16:59:13, Dieter Buerssner wrote:
>>
>>>On September 12, 2003 at 16:53:44, Omid David Tabibi wrote:
>>>
>>>>assuming 'table_size' is a power of 2, the following two expressions are
>>>>equivalent:
>>>>
>>>>address = key % table_size;
>>>>address = key & (table_size - 1);
>>>
>>>Omid, read over this thread, again. I think, there is no doubt, that Gerd is
>>>very well aware of the above. It seems, you are not aware of all the
>>>consequences (GCP gave you a hint).
>>>
>>>Regards,
>>>Dieter
>>
>>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.
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.
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.
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!
>
>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.
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.