Detecting CPUs and cores

[Chris]

Is there any way for Java to detect the number of CPUs that are
available? Runtime.getRuntime().availableProcessors() returns the number
of cores, not CPUs.

 

[Joshua Cranmer]

Is there any way for Java to detect the number of CPUs that are
available? Runtime.getRuntime().availableProcessors() returns the number
of cores, not CPUs.

I don't think that is possible. The only OS I have experience with is
Windows, and that treats a dual-core as two CPUs; I believe that *nix
systems do the same as well.

 

[Daniel Dyer]

I don't think that is possible. The only OS I have experience with is
Windows, and that treats a dual-core as two CPUs; I believe that *nix
systems do the same as well.

I think that's reasonable behaviour. My dual-core Mac does the same under
OS X.

What's slightly less helpful is that my Windows PC at work returns 2 from
availableProcessors() despite the fact that it is single-core, albeit with
Intel's Hyper-Threading.

Finding out any more about the processors is probably going to require
some JNI.

Dan.

 

[Roedy Green]

Is there any way for Java to detect the number of CPUs that are

available? Runtime.getRuntime().availableProcessors() returns the number
of cores, not CPUs.

See http://mindprod.com/products1.html#PENTIUM
It is some JNI that probes various CPU attributes. If it does not
give you what you want, it could easily be extended to.

 

[Lew]

What's slightly less helpful is that my Windows PC at work returns 2
from availableProcessors() despite the fact that it is single-core,
albeit with Intel's Hyper-Threading.

That's not Window's nor Java's fault. The HT processor is electrically
equivalent to two CPUs to the rest of the system. So are multi-core CPUs.

Here's the $64,000 question - what is the value of knowing the number of dies
on which the cores reside? A "core" /is/ a CPU as far as any practical use of
it goes; same for the two virtual cores seen in a HyperThreaded processor.
You program them in every respect as if they were completely separate; the
fact that they happen to share some real estate couldn't be less relevant.

A difference that makes no difference is no difference.

 

[Eric Sosman]

That's not Window's nor Java's fault. The HT processor is electrically
equivalent to two CPUs to the rest of the system. So are multi-core CPUs.

Here's the $64,000 question - what is the value of knowing the number of
dies on which the cores reside? A "core" /is/ a CPU as far as any
practical use of it goes; same for the two virtual cores seen in a
HyperThreaded processor. You program them in every respect as if they
were completely separate; the fact that they happen to share some real
estate couldn't be less relevant.

A difference that makes no difference is no difference.

Well, yes: But it *does* make a difference. The difference
doesn't arise from the die layouts per se, but from attributes
that tend to go along with them. The cores may share resources
in ways that interfere and make their "computational power" non-
additive. Intel's hyperthreaded chips, for example, share a
single execution unit and a single path to memory; only one "CPU"
at a time can initiate an operation on either resource. Similar
remarks apply to Sun's T1 processor; the thirty-two "strands"
share eight execution units, one on-chip cache, and one floating-
point unit, but multiplex across four memory channels.

The differences make a difference -- but taking proper account
of them is far more involved than simply counting cores or chips.
You need to get into the architecture of what's shared and what
isn't, which components can run in parallel and to what degree,
and so on. This is well outside the scope of what cross-platform
Java is equipped to handle; one would need a lot of supplementary
information to make sense out of whatever number one obtained.

 

[Lew]

Well, yes: But it *does* make a difference. The difference
doesn't arise from the die layouts per se, but from attributes
that tend to go along with them. The cores may share resources
in ways that interfere and make their "computational power" non-
additive. Intel's hyperthreaded chips, for example, share a
single execution unit and a single path to memory; only one "CPU"
at a time can initiate an operation on either resource. Similar
remarks apply to Sun's T1 processor; the thirty-two "strands"
share eight execution units, one on-chip cache, and one floating-
point unit, but multiplex across four memory channels.

The differences make a difference -- but taking proper account
of them is far more involved than simply counting cores or chips.
You need to get into the architecture of what's shared and what
isn't, which components can run in parallel and to what degree,
and so on. This is well outside the scope of what cross-platform
Java is equipped to handle; one would need a lot of supplementary
information to make sense out of whatever number one obtained.

Given that I was speaking from the parochial point of view of being a
comp.lang.java.programmer, we are in agreement.

In Java terms, it makes no difference. The Intel HT is able to interleave
execution between its two virtual "cores" in its single actual core because of
its architecture; it actually achieves speedup from the parallelism. As a
Java programmer, one is divorced from the details of the "actual" differences
that you describe. As a Java programmer, the difference(s) make no
difference. Therefore as a Java programmer there really is no (useful)
difference between the multi-core imitation that an Intel HT gives, the actual
multi-core of an X2, or the separate die CPUs of a two-way Xeon motherboard.

Of course I realize that in some universe there are differences between these
that matter; that is the Zen of the pithy maxim that I offered. So let's
recast that cute little poster saying in order to maximize satori,

"When does the difference make a difference?"

 

[Patricia Shanahan]

Eric Sosman wrote:
....

The differences make a difference -- but taking proper account
of them is far more involved than simply counting cores or chips.
You need to get into the architecture of what's shared and what
isn't, which components can run in parallel and to what degree,
and so on. This is well outside the scope of what cross-platform
Java is equipped to handle; one would need a lot of supplementary
information to make sense out of whatever number one obtained.

A programmer may have determined experimentally that two threads running
on different cores get significantly more throughput than one, but that
the same two threads running hyper-threaded get less throughput than
one. The program is written so that the number of threads is a free
parameter.

The program should limit the number of threads to be no more than the
number of cores, but cannot because it cannot tell the difference
between two separate cores and a single hyper-threaded core.

Patricia

 

[Twisted]

The differences make a difference -- but taking proper account
of them is far more involved than simply counting cores or chips.

There is no real "taking proper account of them" for the programmer to
do, other than that to get maximum use you need to have at least as
many concurrent threads of program as there are cores/hyperthreads/
whatever. In otherwords, at least the number returned by
availableProcessors().

Optimizations for the details of the specific hardware architecture's
details are for the JIT.

Only JVM coders need concern themselves with these.

 

[Twisted]

Eric Sosman wrote:

...


A programmer may have determined experimentally that two threads running
on different cores get significantly more throughput than one, but that
the same two threads running hyper-threaded get less throughput than
one. The program is written so that the number of threads is a free
parameter.

The program should limit the number of threads to be no more than the
number of cores, but cannot because it cannot tell the difference
between two separate cores and a single hyper-threaded core.

Actually, it's the responsibility of the OS (or maybe the VM) to
schedule threads in such a way as to maximize throughput, modulo
thread-priority semantics anyway.

 

[Patricia Shanahan]

Actually, it's the responsibility of the OS (or maybe the VM) to
schedule threads in such a way as to maximize throughput, modulo
thread-priority semantics anyway.

It would be wonderful if the OS could ensure that increasing the number
of threads, within the limit of the number of hardware threads, never
makes performance worse. Unfortunately, the CPU dispatcher faces a
couple of problems:

1. It also has to ensure that all threads make some progress. If it does
not, it may be hanging a thread that should interact with a human being
or another system.

In the 1970's, I would kick a thread out for seconds to minutes at a
time to ensure that the jobs I was running had all the memory they
needed to run with minimal paging, but that was on batch systems.

2. It is often not obvious whether time is being wasted or not, when it
comes to overloaded caches, branch predictors etc.. The programmer can
measure real throughput, in transactions per second or equivalent. The
dispatcher can only measure how much CPU time it is giving a thread, not
the effectiveness of that CPU time.

Patricia

 

[Twisted]

2. It is often not obvious whether time is being wasted or not, when it
comes to overloaded caches, branch predictors etc.. The programmer can
measure real throughput, in transactions per second or equivalent. The
dispatcher can only measure how much CPU time it is giving a thread, not
the effectiveness of that CPU time.

Really? It can't, by some law of mathematics, actually briefly run the
threads separately, then simultaneously, and see how fast their
program counters advance?

Anyway, if it's ever the case that running two threads concurrently on
HT is slower than running them sequentially on HT (as in it actually
takes longer clock time for both to finish), it sounds like evidence
that the hardware implementation of HT in that case is woefully broken
and perhaps that it was misdesigned, or even that HT as a whole is a
poor cousin of true dual-core processors. In which case poor HT
performance is really a hardware problem and again not the software
developer's responsibility to fix.

 

[Lew]

A programmer may have determined experimentally that two threads running
on different cores get significantly more throughput than one, but that
the same two threads running hyper-threaded get less throughput than
one. The program is written so that the number of threads is a free
parameter.

The program should limit the number of threads to be no more than the
number of cores, but cannot because it cannot tell the difference
between two separate cores and a single hyper-threaded core.

It is likely that the two hyper-threaded cores will achieve more throughput
than on one of those "cores". The reason Intel provided hyperthreading is
that it increases throughput on the chip.

 

[Daniel Dyer]

It is likely that the two hyper-threaded cores will achieve more
throughput than on one of those "cores". The reason Intel provided
hyperthreading is that it increases throughput on the chip.

That's the theory, but it's less clear cut than with a "proper" dual core
chip. There is anecdotal evidence of people turning *off* Hyper-Threading
in the BIOS to improve the performance of their applications.

http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm
http://www.javalobby.org/java/forums/t54590.html

I haven't personally benchmarked the effect of Hyper-Threading but, if
your application is relying on the result of availableProcessors() to fine
tune it's concurrency strategy, it's important to be aware that 1 HT CPU
may behave quite differently from 1 dual-core CPU.

Dan.

 

[Roedy Green]

taking proper account of them is far more involved than simply counting cores or chips.
That is one aspect of a bigger problem, tweaking an app to run most
efficiently on different machines. There are various parameters you
intensive algorithms. There is no one size fits all.
See http://mindprod.com/jgloss/tweakable.html and
http://mindprod.com/project/tweakable.html

 

[Lew]

That's the theory, but it's less clear cut than with a "proper" dual
core chip. There is anecdotal evidence of people turning *off*
Hyper-Threading in the BIOS to improve the performance of their
applications.

http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm
http://www.javalobby.org/java/forums/t54590.html

I haven't personally benchmarked the effect of Hyper-Threading but, if
your application is relying on the result of availableProcessors() to
fine tune it's concurrency strategy, it's important to be aware that 1
HT CPU may behave quite differently from 1 dual-core CPU.

There is evidence that multiple CPUs can reduce throughput relative to a
single CPU, too. It depends on the software.

I am not arguing that HyperThread is as effective as multiple cores. In fact,
HT is a hack devised by Intel to counteract excessive pipeline stalling, so it
stands to reason that its performance would differ perhaps significantly from
true multiple-CPU scenarios. The trick is to discern when the number of CPUs
reported by Java is a reliable number and when it isn't.

My point is that most times to the Java world it doesn't matter. You use the
number as reported. Like every performance issue, especially in Java, it is
nigh impossible to make /a priori/ judgments about the impact this will have,
especially cross-platform /a priori/ judgments. So unless we decide in a
particular case that the difference makes a difference, we pretend that it is
no difference. To the JVM, a HT (with both "cores" enabled) acts like two
CPUs, smells like two CPUs, quacks like two CPUs, so we pretend that it is two
CPUs.

Performance optimization comes after the fact.

 

[Eric Sosman]

That's the theory, but it's less clear cut than with a "proper" dual
core chip. There is anecdotal evidence of people turning *off*
Hyper-Threading in the BIOS to improve the performance of their
applications.

One computer company (no, not the one I work for -- not
to my knowledge, anyhow) has published benchmarks in which it
disabled one of the two cores on each dual-core chip, getting
better throughput by reducing competition for the on-chip cache.

 

[Patricia Shanahan]

It is likely that the two hyper-threaded cores will achieve more
throughput than on one of those "cores". The reason Intel provided
hyperthreading is that it increases throughput on the chip.

On average. For typical threads, especially threads that appear in the
benchmarks that they simulate during processor design.

Patricia

 

[David Gourley]

Here's the $64,000 question - what is the value of knowing the number of
dies on which the cores reside?

Some 3rd party software vendors are now licensing software based on
number of sockets instead of number of cores....

which may mean that to comply software has to perform a socket check.

Dave

 

[Twisted]

Some 3rd party software vendors are now licensing software based on
number of sockets instead of number of cores....

which may mean that to comply software has to perform a socket check.

This sort of brain-dead artificial scarcity enforcement deserves to
fail. It doesn't even cost the vendor proportionately to the number of
users or installed copies, let alone the number of dies, cores,
sockets, or hyperthreads. Why in Christ's name do they feel justified
in making the price so proportional then? Even copyright law provides
no legal or rational basis for charging proportionally to anything but
installed copies or perhaps copies in concurrent use. Even supposing
multi-CPU (but not single dual-core CPU?!) systems spawned two
transient copies during execution in place of one, such transient
copies as are made during normal use of the software are legit as per
17 USC section 117(a)(1) and do not require separate permission from
(or payment to) the copyright holder. One legitimately purchased and
installed copy can be used as the user sees fit as per first sale
doctrine; they only infringe if they install more copies or install
and keep but sell the original media or something.

The only (flimsy) legal justification these companies can muster is
some dialog-box text they claim somehow constitutes a legally binding
contract between the user and the vendor that supersedes all existing
tacit agreements made through the process of purchasing a copy from
the retail outlet as well as all state and federal law governing
retail sales and copyright, supposedly enforceable despite the vendor
having no signed document to that effect as evidence of such an
agreement having been made, and despite being a contract of adhesion
even if so.

As for moral justification for why they deserve to be paid for every
separate CPU chip it runs on ... well they have none of course. That's
just pure unadulterated greed.