Java Threads on Windows, multi-core processor...

[Daniel Pitts]

I have a program I'm working on (a ray tracer to be exact) that uses
multiple threads to do the hard work.
According to windows task manager, I'm only utilizing around 50%(±10%)of
my CPU power.

This makes me think that either I'm spending too much time synchronizing
(darn), or I'm only using one CPU.

Anyone have suggestions on which it is? I'm using a BlockingDeque to
pass my work load off to worker threads, and I thought that wouldn't
have a lot of synch cost to it.

 

[Knute Johnson]

I have a program I'm working on (a ray tracer to be exact) that uses
multiple threads to do the hard work.
According to windows task manager, I'm only utilizing around 50%(±10%)of
my CPU power.

This makes me think that either I'm spending too much time synchronizing
(darn), or I'm only using one CPU.

Anyone have suggestions on which it is? I'm using a BlockingDeque to
pass my work load off to worker threads, and I thought that wouldn't
have a lot of synch cost to it.

On Windows with a Pentium D processor and only one thread running, the
processors run at a total of about 50%, one using 60% and the other 40%.
If I run two threads, then both run at 100%. I don't know what this
means but it is interesting. I think there are a lot of scheduling
issues that are obscured.

public class test7 implements Runnable {
public void run() {
while (true) ;
}
public static void main(String[] args) {
new Thread(new test7()).start();
new Thread(new test7()).start();
}
}

 

[Owen Jacobson]

I have a program I'm working on (a ray tracer to be exact) that uses
multiple threads to do the hard work.
According to windows task manager, I'm only utilizing around 50%(±10%)of
my CPU power.

This makes me think that either I'm spending too much time synchronizing
(darn)

Depending on your strategy for parallelization, this may be very
likely. If you're spinning off a task for each pixel (or each ray)
and synchronizing when you add the results of that ray to the overall
image, there will almost always be someone holding the lock on the
result handler.

A fairly standard approach to parallelizing ray-tracing is to break
the image into panels and render each panel in a single thread, and
stitch the panels together to form an image either after all threads
have completed or as threads complete their panels. You can combine
this with 1-thread-per-core (maximum efficiency, for CPU-intensive
tasks) and a queue of rendered panel bounds to pull from as each
thread completes its current panel. I've had good luck parallelizing
ray-tracing across 2 CPUs before using POV-RAY (and running two
complete processes); it should work fine in a single process as well
and use the majority of the available CPU time.

, or I'm only using one CPU.

Anyone have suggestions on which it is? I'm using a BlockingDeque to
pass my work load off to worker threads, and I thought that wouldn't
have a lot of synch cost to it.

A blocking queue has (at least notionally) synchronization at every
put or take from the queue.

 

[Kevin McMurtrie]

I have a program I'm working on (a ray tracer to be exact) that uses
multiple threads to do the hard work.
According to windows task manager, I'm only utilizing around 50%(±10%)of
my CPU power.

This makes me think that either I'm spending too much time synchronizing
(darn), or I'm only using one CPU.

Anyone have suggestions on which it is? I'm using a BlockingDeque to
pass my work load off to worker threads, and I thought that wouldn't
have a lot of synch cost to it.

You could be spending a huge amount of time in garbage collection. Some
JVMs default the wrong collector for the hardware.

I've also seen odd threading optimizations on some hardware. For
example, a synchronized block inside a for-loop may never yield its
synchronization to other threads on some platforms. It's hardly a safe
optimization for the compiler to make. In my case, it blocked
heartbeats on a multiplexed communications socket during high load. The
lack of heartbeats caused it to fail every 15 minutes.

You can try using a profiler with all thread states enabled for
profiling.