Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?

Thu, 10 Sep 2009 16:30:17 -0700 


On 10/09/09 4:33 PM, "Ingo Macherius" <[email protected]> wrote:

> My benchmarks with 4 cores showed that the cache brings about 10% improvement,
> but look at what huge amount of bugs it caused recently, and how harmful it is
> to threading.

This is statement is true. Can't deny it. However regarding the bugs, 4ply
results with cache at maximum have matched my results with cache=0 with
recent builds with cache fixes. One other thing, and I won't say for
certainty (because I don't know what would have changed to resolve it) but
it appears the situation where a rare analysis takes 40% less time with
cache on is gone. I have a suspicion that its the same thing that caused
your results to have significant dips on some trials. What I do know is that
in my case the matches that took 40% less time did not produce the same the
result (but interestingly enough very close), and the elapsed time reported
by /usr/bin/time was not skewed (to verify I ran the date command before and
after just a sanity check in the event the skew in elapsed run time was
thread related).




_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg






















					Reply via email to