multi-core CPU and multithreading

[Chen]

Hi there

I want to programme multithreading on multi-core CPU. What should I do
to fully utilize the multi-core? Will the multi-threads automatically
be assigned to different cores?

Thanks

Chen

 

[roger.jakobsen]

I don't think the old JVM will fully utilize all cores. When my
Eclipse hangs, or "works", it will never chew more than 25 % of my
processor power As you can probably guess I'm working on a 4 core
platform.

A few simple tips:
-The number of simultaneously active threads should be less than the
number of hardware threads.
-You should minimize writes to shared data since the processor must
acquire data ownership. This usually
means a write to plus a read from long-latency memory.
-Shared data reads are not expensive

Read more at:
http://it.sun.com/sunnews/events/2007/sept/jc07/pdf/Milano_JavaTrack1/TD_MILAN_Intel_Guermonprez.pdf

 

[Lew]

I don't think the old JVM will fully utilize all cores. When my
Eclipse hangs, or "works", it will never chew more than 25 % of my
processor power As you can probably guess I'm working on a 4 core
platform.

Eclipse? It's hard to draw conclusions when you're working within the nest of
the IDE. You've got debug compiles, non-optimized JVM settings, low-level IDE
hooks and the like going on.

A few simple tips:
-The number of simultaneously active threads should be less than the
number of hardware threads.

This directly contradicts the advice given in the link you provided, which says,

Number of simultaneously active software threads should be >= number of hardware threads.

Bear in mind that you can more threads *open* than you have processors for
some applications, e.g., I/O-bound processes.

-You should minimize writes to shared data since the processor must
acquire data ownership. This usually
means a write to plus a read from long-latency memory.

That depends - many writes are uncontended and the JVM will optimize the locks
(on recent Java platforms).

-Shared data reads are not expensive

Unless there's a cache miss or the read has to access local memory from a
different CPU's local RAM region.

Read more at:
http://it.sun.com/sunnews/events/2007/sept/jc07/pdf/Milano_JavaTrack1/TD_MILAN_Intel_Guermonprez.pdf

Read more at IBM DeveloperWorks and all over Sun, too.

 

[Nigel Wade]

Hi there

I want to programme multithreading on multi-core CPU. What should I do
to fully utilize the multi-core? Will the multi-threads automatically
be assigned to different cores?

That should be up to the OS. If you have multiple threads within a Java
application the JVM will attempt to schedule those which are able to run (i.e.
not blocked for some reason). The OS should in turn allow these threads to run
on any processor/core which is available. Of course, there are ways with each
OS to modify this behaviour, but I don't think there is any way within Java.

 

[Arne Vajhøj]

I want to programme multithreading on multi-core CPU. What should I do
to fully utilize the multi-core? Will the multi-threads automatically
be assigned to different cores?

If you make your app multithreaded, then most modern JVM's and OS's
will be able to utilize multi-core.

Arne

 

[Arne Vajhøj]

I don't think the old JVM will fully utilize all cores. When my
Eclipse hangs, or "works", it will never chew more than 25 % of my
processor power As you can probably guess I'm working on a 4 core
platform.

Maybe IDE's are a bit difficult to write as multi-threaded ...

Arne

 

[Mark Space]

Maybe IDE's are a bit difficult to write as multi-threaded ...

Arne

I don't see why. It's just an EDT thread plus some worker threads. Why
should that be difficult to make multi-threaded? It practically is by
default....

 

[Chen]

If you make your app multithreaded, then most modern JVM's and OS's
will be able to utilizemulti-core.

Arne

Does this mean Windows XP and Java 1.4 can do it automatically?

 

[Lew]

Does this mean Windows XP and Java 1.4 can do it automatically?

What to the Windows XP docs have to say about use of multiple cores?

Are you constrained to using Java 1.4, which has entered Sun's "End-of-Life"
process? Even Java 5 is slated to enter its End-of-Life this year.

Often people will say, "That's the platform I'm stuck with." This begs the
question of why one is stuck with the platform. What are the reasons?

It can't be acquisition cost, which approximates zero. Labor costs for
installation are minimal. Conversion costs are next to zero. Risk is also
near zero, and since the benefits are large, the cost-benefit and risk-reward
analyses should strongly favor going with a (more) current Java version.

Are you still using the 2002 version of Windows XP, or have you upgraded to
service pack 2 by now? Java 5 is roughly the same age as XP SP2.

 

[Andreas Leitgeb]

Often people will say, "That's the platform I'm stuck with." This begs the
question of why one is stuck with the platform. What are the reasons?

Ever so often the reason is: "Never change a running system"

Conversion costs are next to zero. Risk is also near zero,

These are where you might find some disagreement out there in the fields

 

[Lew]

Ever so often the reason is: "Never change a running system"

That doesn't apply in this case, since the question was sparked by someone
needing to write new code.

It's a good principle, except for the part about never changing a running system.

The problem is that running systems frequently are not error free, and further
often do not adapt well to changing needs or circumstances.

These are where you might find some disagreement out there in the fields

That's what I want to hear. What are the (perceived) risks, and how are they
measured? Show me the money.

 

[Andreas Leitgeb]

It's a good principle, except for the part about never changing a running system.

Not much left then ...

That's what I want to hear. What are the (perceived) risks, and how are they
measured? Show me the money.

I know of a project, that back in java 1.3 days used a method "assert(...)"
in almost every single class. It was no sophisticated work, to globally
search for that method-name, and either rename it, or make it a proper
assertion, but for some reason, the customers did not want to spend any money
for that work, until the dead-line for java 1.3 was really approaching.

There were, of course, also slight GUI-glitches to solve, where some
default changed (font-size, colors), or setting background color of some
component no longer had any effect, resulting in a white-on-white textfield.
Some of these effects were actually from workarounds for bugs in 1.3, that no
longer worked with 1.4 (again only some of them just weren't necessary anymore
for 1.4).

Then there was some incompatibility with a third-party-library, whose newer
version had dropped a certain needed feature, which they had deprecated, but
without providing an alternative that satisfied the needs, resulting in that
crap having to be replaced.

Even if no line of source were needed to be changed, it still requires at
least a complete(as far as possible) testing walk-through to detect
"suddenly white-on-white" text-elements.

That should be enough - I will not go into more detail. If you don't
believe me, that's not my problem.

 

[Nigel Wade]

That's what I want to hear. What are the (perceived) risks, and how are they
measured? Show me the money.

The risk is breaking existing software. The cost is in determining whether that
risk is real.

Before updating the JVM on a production system it's a good idea to test your
existing software with the new JVM somewhere else. That involves cost, both in
terms of hardware and manpower. Of course there may be other considerations
such as whether the software you need to test is licensed to run anywhere other
than the production server...

 

[Arne Vajhøj]

Does this mean Windows XP and Java 1.4 can do it automatically?

Yes.

Arne

 

[Arne Vajhøj]

Often people will say, "That's the platform I'm stuck with." This begs
the question of why one is stuck with the platform. What are the reasons?

It can't be acquisition cost, which approximates zero. Labor costs for
installation are minimal. Conversion costs are next to zero. Risk is
also near zero, and since the benefits are large, the cost-benefit and
risk-reward analyses should strongly favor going with a (more) current
Java version.

Well if fixing all 1.5 language things and testing the entire
app cost a million dollars then you can bet that finance will
ask what benefits that upgrade has.

Arne

 

[Arne Vajhøj]

That doesn't apply in this case, since the question was sparked by
someone needing to write new code.

It may not apply in this case.

But in the real world starting with a blank sheet of paper
is rare.

Maintenance of existing apps or new apps that need to run in the
same environment as existing apps are more the norm than the exception.

Arne