[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?
From: |
Michael Petch |
Subject: |
Re: [Bug-gnubg] How many threads can gnubg (reliably) handle? |
Date: |
Thu, 10 Sep 2009 17:30:00 -0600 |
User-agent: |
Microsoft-Entourage/12.20.0.090605 |
On 10/09/09 4:33 PM, "Ingo Macherius" <address@hidden> 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).
Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?, Jonathan Kinsey, 2009/09/11
Re: [Bug-gnubg] How many threads can gnubg (reliably) handle?, Jonathan Kinsey, 2009/09/12