Author: F. Huber
Date: 12:37:12 12/11/03
Go up one level in this thread
Hello Gerd, >todays processors behave a bit chaotical due to lot of internal heuristics which >may greatly affect performance. Maybe some Athlons are more sensible about some >very special code or data movements/replacements. There are register stalls, >load-store stalls, code and data size and alignment issues, code and data >caches, branch prediction heuristics, virtual to physical memory mapping with >4KByte pages etc. Some minor changes may result in exceeding of some critical >thresholds. >Sometimes changing the order of some data members of a struct/class or the >placement of global variables inside modules has enormous effect, sometimes >negligible. yes, I´m of course aware of all those things, but I really can´t believe, that this could explain such a _big_ slowdown - maybe 2-3%, but 10% ?? >Did you perhaps change the order you link your modules? Definitely NO - all of Chest´s source module are combined together to one big source file with ´#include ...´, and their order hasn´t changed. >Did you renamed some source files? Also NO. >Seems you need that hardware first to reproduce the effects by your self. >You have to reproduce the previuos and faster Chest-version. That´s one of my biggest problems - but of course I can´t buy an AMD system only for this purpose. ;-) >Generate map-files (project-settings/Link/general) with symbols and their >addresses - compare them. Profiling both versions may give some hints... >And comparing debug versions and probably several kinds of optimizations. That all could help, but it looks like a task for _months_. :-( >I often found size optimization was faster than speed optimization. _This_ was exactly the ´solution´ that I mentioned. Because I had the idea, that - with some more commands in my new version - the code would eventually no longer fit into the internal processor cache, I´ve tried a compilation with optimizing for size: the result was _much_ faster (still faster than the old 2.8 version) - but: ONLY on my old K6 !! On every other processor it slowed down again for some percent! >I want to add that also the compiler and not only the processor may behave >chaotical due to minor changes. May be some optimization pattern don't longer >apply anymore, aliasing issues, short hotspot code/data fitting in N cachelines >before now need N+1 due to slight movements. Hey, are we talking about ´computers´ or about ´random number machines´? ;-) >Do some minor Chest changes influence the shape of the search tree, >or is it only a loss of speed with exact the same search behaviour? Thats not easy to say for me without an AMD-system. For me here there´s no problem, and of course the found solution is still correct (at least I hope so ;-)) Anyway, thanks for your answer, Franz.
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.