Author: Uri Blass
Date: 04:52:43 04/19/03
Go up one level in this thread
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. 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. If size is not the amount of data structure then how do you calculate that amount? > >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. > >> >>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? 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.