Author: Tony Werten
Date: 05:13:34 04/19/03
Go up one level in this thread
On April 19, 2003 at 07:52:43, Uri Blass wrote: >On April 19, 2003 at 06:35:42, Tony Werten wrote: > >>On April 19, 2003 at 05:08:40, Uri Blass wrote: >> >>>On April 19, 2003 at 04:54:29, Tony Werten wrote: >>> >>>>On April 19, 2003 at 04:07:37, Uri Blass wrote: >>>> >>>>>On April 19, 2003 at 03:37:06, Tony Werten wrote: >>>>> >>>>>>On April 17, 2003 at 20:35:35, James Robertson wrote: >>>>>> >>>>>>>Out of curiosity I tested just the move generation and basic board functions of >>>>>>>my bitboard chess program on several different computers. My home computer is a >>>>>>>Pentium 933mhz, and the other computers I used were Athlons in the 1.6ghz range. >>>>>>> >>>>>>>My program's move generator runs at roughly the same speed on both systems. I >>>>>>>was surprised and tested using several different compilers (VC5, VC6, .NET, >>>>>>>gcc), under Windows and under Linux. To compare more easily, I wrote a simple >>>>>>>non-bitboard move generator and tested this on all of the machines. The speed >>>>>>>differences scaled with the speed of the processors, which seemed logical. >>>>>>>However, I still cannot explain why the bitboard functions are so much slower on >>>>>>>the faster computers. The only difference I can see is that my home computer is >>>>>>>a pentium and the others are athlons. >>>>>>> >>>>>>>It seems strange that this would make such a large difference. Can anyone give >>>>>>>any reasons why? I used no assembly, just C/C++ code, with all the default >>>>>>>compiler options on all tests. >>>>>> >>>>>>I think it's because bitboards tend to fill up the caches, so memory becomes the >>>>>>bottleneck. >>>>>> >>>>>>With other approaches this doesn't happen, ( until you add the big stuff like >>>>>>eval ) so all things stay in chache wich makes it (almost) only processor >>>>>>limited. >>>>>> >>>>>>Tony >>>>> >>>>>Does it mean that bitboard chess programs or programs with big evaluation are >>>>>basically optimized for the old hardware because they cannot get much from new >>>>>hardware? >>>> >>>>No, because you're doing more then, wich can go faster with faster hardware. ie >>>>You don't reach the move generation bottleneck, but have others. >>>> >>>>But if all you are doing, has a memory bottleneck (wich happens when only >>>>generating moves with bitboards ), a faster cpu won't help very much. >>>> >>>>Tony >>> >>>The question is how can I identify memory bottleneck. >>> >>>I use bitboards only for pawn structure but I have a big move generator(some >>>thousands of C lines). >> >>I don't think the amount of code counts. It's the amount of datastructures it >>operates on. > >In that case I do not understand why bitboard cause a problems. > >How much data structure do you have with bitboards. 1-2 MB depending on your implementation. > >some 64 bit varaible and some arrays does not seem to me much relative to the >hash tables that is the biggest data structure that programs use. James wrote a move generator. I'm pretty sure he didn't use hashtables. Even so, 1 lookup in a 128 MB table will do less harm than 20 lookups in a total of 2 MB (for the cache) > >If size is not the amount of data structure then how do you calculate that >amount? It IS the size of datastructure. > > > >> >>Whatever you do in pawnstructure doesn't count. Time will be close to 1 memory >>lookup in the pawnhashtable. > >In other words you say that time is important and not only the amount of >datastructures the code operates on. In really other words yes. In my words no. (for pawnhash) 99.99% of all pawnpositions will be in the hashtable. That means (relatively) the amount of time to fill the table gets close to zero and pawnstructure will only cost 1 memory lookup. > >> >>> >>>Is the only way to buy fast hardware and see if my program is faster on faster >>>hardware or is there a better way? >> >>Almost any full chessprogram will always be faster on faster processors. The >>only exceptions I can think of could be those slow, highly positional/selective >>ones. For those I'd recommand not upgrading to a higher frequency processor, but >>going to one with bigger caches. But still, XiniX is a slow positional program ( >>ie 150 Kn/s in opening/early middlegame, max 400 Kn/s in endgame) and it's >>profiting a lot from faster cpu's. > >It is profiting a lot today but what is going to be the situation in the future >when even faster cpu's are going to be available? I'm not sure. In general, slower programs have smaller branchingfactors, so they need less speedup to get a ply deeper. Tony > >Is there a way to predict what is the limit when a program stops profiting from >faster cpu's without having the faster cpu's? > >Uri
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.