Author: Miguel A. Ballicora
Date: 15:39:49 12/10/01
Go up one level in this thread
On December 10, 2001 at 16:17:35, martin fierz wrote: >On December 10, 2001 at 10:57:30, Miguel A. Ballicora wrote: > >>On December 09, 2001 at 21:09:17, martin fierz wrote: >> >>>aloha, >>> >>>i have written a checkers interface and a checkers engine, and recently i made a >>>change so that the user can set the hashtable size in the interface and it is >>>communicated to the engine. >>>up to now, my code looked like this: >>> >>>// global variables >>>struct hashentry hashtable[BIGNUMBER]; >>> >>>now it looks like this: >>> >>>// global variables >>>struct hashentry *hashtable; >>> >>>// initialization >>>hashtable = malloc(BIGNUMBER*sizeof(struct hashentry)); >>> >>>later in the code i access the hashtable just as before with hashtable[i]. >>>i would have expected these two approaches to be equivalent, but the new one >>>drops a few % of speed overall. that's a lot, because the whole hashing stuff >>>only takes up a few % of my work, so it looks like that part is something like >>>half as fast as earlier. >> >>But you do not know that for sure without profiling. Maybe your hashtables >>accesses are the same but the different setup in memory causes to drop few % >>of efficiency in a bottleneck, somewhere else. >>Your evidence that you have a big performance problem in the hashing is >>too indirect. >>I do not think that any conclusion can be drawn without a profile. >> >>Regards, >>Miguel > >i don't believe in profiles. during profiling, everything is different than >during normal program execution because of the profiling code which is needed. >example: i make a big effort in move ordering. my profiler tells me that my >makemovelist function needs 40% of the time. if i turn move ordering off, the >profiler tells me that makemovelist needs 1% of the time, so that means my >program should run at 100/61 = 64% faster, in terms of kN/s. does it do that? >no, it runs about 30% faster. i quote the numbers from memory, which is a bit >dangerous, but i'm sure the profiler was off by more than a factor of 2. >i prefer to change something in my program and measure how long it takes it to >run through a couple of test positions under realistic conditions. seems much >more accurate to me! > >cheers > martin If you don't believe in profiling, how do you know that your hashing is very fast compared to the rest of your program? The point is that you guess that you hashing stuff got slower but you are not certaing about it. Maybe it is running at the same speed and something else is slower; particularly when you say that the slowdown was only a few % (I think that you mean a low single digit). Your memory setup changed completely, why would you expect the rest of your program to run exactly the same? I once got a slowdown of 20% just renaming a file (something like srch.c to ab_srch.c). It just got linked in a different order by the linker since it did alphabetically! I would not be worry about little slowdowns. Regards, Miguel
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.