On 4/2/08, Charles Oliver Nutter [EMAIL PROTECTED] wrote:
I ran into a very strange effect when some Sun folks tried to benchmark
JRuby's multi-thread scalability. In short, adding more threads actually
caused the benchmarks to take longer.
The source of the problem (at least the source
John Wilson wrote:
On 4/2/08, Charles Oliver Nutter [EMAIL PROTECTED] wrote:
I ran into a very strange effect when some Sun folks tried to benchmark
JRuby's multi-thread scalability. In short, adding more threads actually
caused the benchmarks to take longer.
The source of the problem
I ran into a very strange effect when some Sun folks tried to benchmark
JRuby's multi-thread scalability. In short, adding more threads actually
caused the benchmarks to take longer.
The source of the problem (at least the source that, when fixed, allowed
normal thread scaling), was an
On 4/2/08, Charles Oliver Nutter [EMAIL PROTECTED] wrote:
John Wilson wrote:
That is rather odd.
Shouldn't count be volatile?
If it's declared as volatile does that make any difference?
I had not tried it because I expected volatile would only make it
slower. And in this
Attila Szegedi wrote:
No. You know your JVM bytecodes, Charlie - the only incrementing
bytecode in existence is IINC and it only works on an integer local
variable.
Yes, I know that...but I hadn't dug into what code was actually being
generated for a field++. Looking now they don't
On 4/2/08, Charles Oliver Nutter [EMAIL PROTECTED] wrote:
I ran into a very strange effect when some Sun folks tried to benchmark
JRuby's multi-thread scalability. In short, adding more threads actually
caused the benchmarks to take longer.
Was this work being done on Intel hardware?
Jochen Theodorou wrote:
I think there is not enough data to see a trend. I modified your test,
made it run from 1-20 threads and for 50 loops, making an average time
containing the time it took to execute all threads and put these in a
diagram. I used a Q6600 Quadcore intel CPU with java
On Apr 2, 2008, at 4:01 AM, John Wilson wrote:
I'm just wondering if this might be some issue with the cache on Intel
mutli core processors (i.e. the cache is constantly being
invalidated).
Yes, that code will in general cause cache ping-ponging,
which in the long run will harm sharing and
Hi,
Here's a slightly reduced example, with most important tings in just
two lines, one marked SLOW and another marked FAST.
http://pastie.org/174059
// if ((i++ 0xFF) == 0) firedCount++; // SLOW
// if ((i++ 0xFF) == 0) Counter.firedCount++; // FAST
The difference in timings on my Dual-Core
