Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I'm running sbcl 1.05 on AMD64. The server has 4 CPUs with 2 cores per CPU.
Via slime, I execute multiple background (say 3) threads on
Strangely, when I use the Unix "top" command to examine the CPU load
across cores, I see something like this (when I issue 3 threads):
Here, Cpu0 and Cpu1 are the cores for the 1st physical CPU. Cpu2 and
Cpu3 are the cores for the 2nd physical CPU.
The CPU % always adds up to approximately 100%, so somehow my threads
are essentially sequential. So I am puzzled at why this happens.
My threads are not modifying shared data, so there are no explicit
locks. They are reading shared data though (in hash tables).
I also tried having sbcl compile a big program while the other 3
threads are running. Again, the 4 threads then add up to 100%.
In addition, I have a multiple-threaded Java program that is able to
max out all cores at 100% (for a total of 800%), so the problem seems
to be sbcl specific.
My compile settings are:
(declaim (optimize (speed 3) (safety 3) (debug 3)))
"Alistair Gee" <alistair.gee@...> writes:
> Via slime, I execute multiple background (say 3) threads on
> CPU-intensive tasks. [ ... ]
What happens if you run three threads on CPU-intensive tasks that are
only CPU-intensive: that is, take some function which does nothing but
arithmetic on local data, say, and run it in multiple threads?
(Without any more information on what you are actually doing, it is
difficult to guess what might be going wrong; without access to your
system and your code, it's difficult for any member of this list to
diagnose the problem. The above suggestion is the first thing I would
suggest you try, but it might lead you to try other things to
determine the bounds of the problem.)