Author: Robert Hyatt
Date: 08:29:13 12/07/02
Go up one level in this thread
On December 07, 2002 at 09:58:09, Vincent Diepeveen wrote: >On December 06, 2002 at 23:44:17, Robert Hyatt wrote: > >>On December 06, 2002 at 19:33:58, Vincent Diepeveen wrote: >> >>>On December 06, 2002 at 11:53:26, Robert Hyatt wrote: >>> >>>>On December 06, 2002 at 10:31:54, Vincent Diepeveen wrote: >>>> >>>>>On December 06, 2002 at 10:24:22, Robert Hyatt wrote: >>>>> >>>>>>On December 06, 2002 at 07:14:29, Vincent Diepeveen wrote: >>>>>> >>>>>>>On December 06, 2002 at 05:40:25, Matt Taylor wrote: >>>>>>> >>>>>>>>On December 06, 2002 at 05:09:03, Daniel Clausen wrote: >>>>>>>> >>>>>>>>>http://www.theinquirer.net/?article=6586 >>>>>>>>> >>>>>>>>>I love marketing. :) >>>>>>>>> >>>>>>>>>Sargon >>>>>>>> >>>>>>>>Offhand I would have said the one on the left was a Williamette. ;) >>>>>>>>Then again, Intel claimed that both chips had HT. >>>>>>>> >>>>>>>>The only thing I can figure is that someone made a big typo. >>>>>>>> >>>>>>>>-Matt >>>>>>> >>>>>>>Test results provided by Robert Hyatt i see in small font right bottom :) >>>>>> >>>>>> >>>>>>What are you talking about here? I haven't given them any results at all. In >>>>>>fact, >>>>>>I have had a hyperthreading CPU in my office for two days now and the only >>>>>>result I have provided to anyone was what I provided here (SMT on = 1.33X SMT >>>>>>off). >>>>> >>>>>Can you please post verbose outputs with for each ply also the number >>>>>of nodes printed? >>>>> >>>>>That factor 9 times speedup of their own test is a bit much though :) >>>>> >>>>>Thanks, >>>>>Vincent >>>> >>>> >>>>I can post output. I can't print nodes between plies for the same reason I have >>>>never >>>>been able to do that. All I can do is search to a specific depth and print the >>> >>>Why can everyone print nodes and you cannot? >> >>Is it absolutely necessary that I explain this 6-8 times per year to you? >>The reason hasn't changed. It won't change... >> >> >>> >>>Simple parallel insight. >>> >>>When you have a parallel program like crafty and end an iteration. >> >> >>You have been asking me to print the nodes each time I print a new PV. >>I can't do that because I split at the root. >> >> >> >> >>> >>>It is easy to proof then that no other thread is busy searching >>>then, because otherwise you would not have finished the ply. >>> >>>Proof ends. >> >> >>So? I don't do this. I am not going to do this. end of story... >>It serves _no_ purpose. >> >> >> >> >>> >>>Same is true for displaying mainlines when you don't split in root. >> >>However I _do_ split in the root... > >even then it's trivial that for the move it is a 100% correct number of >nodes. No it isn't, but I am not going to try to explain _why_ again... > >Also it is interesting to know how many nodes you burned before you >got to get this pv, so if you see that as a condition, then you have >a correct node count anyway. Again, I don't have a correct "partial" node count. Each thread counts its own nodes. I don't know which thread searches what... > >You want to see how many nodes a second you get. Simple as that. you don't >want to see it after 2 minutes of search because you do not see >then how it goes first few seconds. > >The first few seconds are crucial to see simply. Nodes burned to other >root moves are simply wasted for this PV, and you *did* burn them. So >you have to count them. No I don't "have to count them". If I am interested, I will simply run the same position N times, the first to depth 1, then again to depth 2, and so forth... However, time is the issue, not nodes. And I do print time everywhere since it is unrelated to who helped who. > >So it is logically that the numbers there apply too. It may be "logically" to you. It isn't to me... > >Best regards, >Vincent > >> >>> >>>In case of DIEP i nowadays simply have node counts for each processor. >>>It simply adds up node counts of other processors at each mainline. >>> >>>It could be incorrect but practically that hardly happens. At end of >>>iteration it is never incorrect though, despite that i do not lock. >>> >>>Best regards, >>>Vincent >>> >>>>node counter >>>>when the search completely stops. >>>> >>>>I ran a dual-thread test with SMT off, and a quad-thread test with SMT on. >>>> >>>>The single position I tried searched 1.5M nodes per second with SMT off, and >>>>2.1M >>>>nodes per second with SMT on. I haven't had time to run exhaustive tests and I >>>>haven't >>>>tried to find time as I need to fix the spinlock and spinwait stuff anyway, >>>>adding the >>>>pause instruction... >>>> >>>>the 9x has to be a typo. The best I have heard was Eugene's 2.0 speedup running >>>>two >>>>tablebase compression programs at the same time...
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.