Author: Robert Hyatt
Date: 11:22:27 11/19/02
Go up one level in this thread
On November 19, 2002 at 13:57:02, Vincent Diepeveen wrote: >On November 19, 2002 at 13:30:57, Christophe Theron wrote: > >>On November 19, 2002 at 13:15:09, Gerd Isenberg wrote: >> >>>On November 19, 2002 at 12:25:11, Gian-Carlo Pascutto wrote: >>> >>>>On November 19, 2002 at 11:35:24, Robert Hyatt wrote: >>>> >>>>>Bitboards have a bit of a performance advantage on 64 bit processors, >>>> >>>>Proof? >>>> >>>>-- >>>>GCP >>> >>>Hi Gian-Carlo, >>> >>>I think that's evident. If the none bitboarders have to use implicite native >>>data-width of 64 bit integers, they have to transfer 32 additional zero bits >>>without any additional information for each integer access. Of course you will >>>pack some data, but all the local ints... >>> >>>So the information density for bitboarders grows with 64bit-architectures >>>relative to none bitboarders. That also effects register usage, and that's IMHO >>>more important. On x86-32bit architectures you can only hold three bitboards in >>>registers, and thats even most a hard task. Actually, if you have a local >>>routine with three bitboards and a few ints on the stack, there are a lot >>>register/memory moves. Simply the data-width doubles the number of bitboard >>>registers, not considered the increase in general purpose registers, or with >>>hammer the number of mmx- and 128-bit xmm registers. >>> >>>Whether a bitboard based program is stronger than a none bitboard program >>>depends obviuosly also on other things, but in principle :) >>> >>>Cheers, >>>Gerd >> >> >> >>You have just explained why the bitboarders are less handicapped on 64 bits >>machines. >> >>You have not explained why they are supposed to have "a bit of performance >>advantage on 64 bits processors". >> >> >> >> Christophe > >Exactly, > >But more important is that they are not in the same league at 32 bits >processors with knowledge. As soon as they need more knowledge they >run into problems. My move generation in itself eats 0.6% of the system >time. My evaluation nearly all of it. >\ That is crap. Crap. MORE CRAP. Anything you can do with your current data structure, I can do with bitmaps. And I do mean _anything_... Please give _one_ example of something that I _can't_ do with bitmaps. >Yet a crucial aspect of evaluating is scanning and that's something >where bitboards are handicapped with 1 or 2 exceptions (you can >quickly scan a rank or file for presence of a piece X). So at 64 >bits CPUs a hybrid model is something which is possible but the >majority of the cases just having 1 bit available with bitboards >and needing an extra >array lookup to index all the different arrays for having the bit >set true, that's pretty slow. > >Yet if you keep your program dumb and fast, you don't suffer from >that lack of course and will never be able to realize it. > >In which case there is no advantage of course, because crafty is >at a McKinley like 1.5MLN nodes a second, whereas a program which >is equally weak tactical last so many plies and in qsearch (saving >out loads of system time which most stronger programs prefer to >spent there), to make it in non-bitboards, is easily going to >get the same number of nps with those blazing fast 6 instruction >bundles a clock. again, crap, more crap and more crap. you can wave your hands. You can repeat that as many times as you want... but it won't make it true... you don't understand bitmaps. you haven't spent the necessary time to learn how to do them. you once told me that I couldn't do "decent mobility" on a Cray where I would have a different value for each square. I showed you how to do it easily and quickly, even though you said "you can't do that." This is more of the same... Just because you can't write code to do something, doesn't mean everybody else can't do it either. The "shift/compare" post from Eugene was a classic. you can't do that. Eugene shows you that you can. So you switch to "but that compiler can't be used, or it is too expensive, or it makes it too easy to disassemble or ..." And once again, you end up dead wrong... as usual. Why not let the people that know about bitboards talk about them? And the ones that want to _learn_ about them learn about them? > >In a simple experiment of mine where i just did recaptures based >upon a single simplistic attacktable in qsearch (only generated >that attacktable at root in qsearch not the innernodes in qsearch), >i got at a P5-100 already blazingly fast. 200k nps initially. When >i then tried to search deeper it got down to 100-150k nps, depending >whether i tried to do less in qsearch or more. You really can't follow a discussion at all. My q-search is simple for _one_ reason. My early q-searches did checks. They did check escapes. you can look at the comments in main.c to see when that was removed. I removed it because I liked the program better with a simple q-search so that I could work on extensions in the normal search without worrying about q-search explosions. It is _not_ simple because I want it to be fast, in terms of NPS. It is not simple because I can't do checks in the q-search. It is simple because in a discussion Bruce and I had prior to the Jakarta WMCCC event, he had removed q-search checks and liked the result and he told me about it. I removed them and also decided that I liked the result. not for the reason _you_ are giving, however. > >In all these cases bitboards is a major handicap at 32 bits processors >and at 64 bits processors the % you lose to bitboards versus non bitboards >is depending upon non-bitboards code in the search simply. It is a _terrible_ handicap. That is why there are _several_ bitboarders running today. It is so terrible that Frans decided to wreck his program by going to use them. > >Best regards, >Vincent
This page took 0.01 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.