but what if the quick result is bmkbhearn wrote:The point is it's the quick result that's the 'bug' if anything, not the take forever result.
I dont know if I am mad or sad or laughing or disgusted or
Moderator: Ras
-
- Posts: 2016
- Joined: Sun Feb 17, 2008 4:19 pm
Re: I dont know if I am mad or sad or laughing or disgusted
-
- Posts: 2053
- Joined: Wed Mar 08, 2006 8:30 pm
Re: I dont know if I am mad or sad or laughing or disgusted
Hi Kim,kgburcham wrote:Here is 12 core on first run:
Using 12 thread(s), 4096 MB hash LP=on
Engine: Critter 1.6a 64-bit (4096 MB)
by Richard Vida
If you want to investigate more the occurrence of "SMP bad luck", you can do it 10 times (stopping after 1 min analysis) or even 100 times (or even more...) if automated (Fritz GUI - Tools - Analysis - Process test set).
Also have a look at the experiment I led quite a few years ago:
http://rybkaforum.net/cgi-bin/rybkaforu ... 5#pid27295
Actually there can be several humps to the distibution curve, corresponding to different depths where the solution is found.
-
- Posts: 5758
- Joined: Tue Feb 28, 2012 11:56 pm
Re: I dont know if I am mad or sad or laughing or disgusted
The reason for the SMP variation is mainly that any (not uselessly inefficient) SMP implementation will search some moves in a different order than the single-threaded implementation. Slight changes in move ordering together with how alpha beta works and how pruning decisions are made can result in very different search trees.
If you take a single-threaded engine and slightly tweak how it orders the moves, the tree will also change. Some positions will be solved earlier. Other positions will be solved later. This is why so much testing needs to be done for every litle change, since running a change on just a few positions is pretty much meaningless.
I suppose it is possible to reduce the SMP variation by severely limiting the type of pruning decisions made (but that will still not get rid of it entirely, unless you also remove the hashtable and probably more stuff), but the resulting engine will just play weaker.
If you don't want the variation, run the engine single-threaded (and make you sure you don't change other parameters such as hashtable size). One thing is sure though, on average the engine will need much more time to find the best move.
If you take a single-threaded engine and slightly tweak how it orders the moves, the tree will also change. Some positions will be solved earlier. Other positions will be solved later. This is why so much testing needs to be done for every litle change, since running a change on just a few positions is pretty much meaningless.
I suppose it is possible to reduce the SMP variation by severely limiting the type of pruning decisions made (but that will still not get rid of it entirely, unless you also remove the hashtable and probably more stuff), but the resulting engine will just play weaker.
If you don't want the variation, run the engine single-threaded (and make you sure you don't change other parameters such as hashtable size). One thing is sure though, on average the engine will need much more time to find the best move.
-
- Posts: 2016
- Joined: Sun Feb 17, 2008 4:19 pm
Re: I dont know if I am mad or sad or laughing or disgusted
Ernest, I built this 12 core on 6/1/2010.If you want to investigate more the occurrence of "SMP bad luck", you can do it 10 times (stopping after 1 min analysis) or even 100 times (or even more...) if automated (Fritz GUI - Tools - Analysis - Process test set).
So I have been looking at, dealing with, and eating smp variation for over two years now.
You want to see smp variation? Get a bunch of cores.
I am glad I have this system, I just think that someone someday, will come along and make the variation less.
I do not except the variation as "it has to be there".
kgburcham