Author: martin fierz
Date: 11:16:11 12/11/01
Go up one level in this thread
On December 10, 2001 at 18:39:49, Miguel A. Ballicora wrote: >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? that is a good question :-) actually, i believe profiling gets it roughly right, but not exactly. so if the profiler tells me that my hashing uses no time, i tend to believe it. especially since reading/writing from/to the hashtable needs very few instructions. >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. oh, that's a really strange experience! thanks for sharing it - it's one of the reasons i asked. if my slowdown is something inpredictable, then i don't worry about the few % speed decrease i get. in another build, they may be back. however, if somebody could tell me that this was a real slowdown because of reason XY, then i would care about it. because if you have a few times a few %, it will start to matter... thanks martin
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.