Re: Java slow on Xeon processors ?

From: Marc Slemko (marcs_at_znep.com)
Date: 05/25/04 

Date: 25 May 2004 03:25:15 GMT

In article <987ebcdd.0405240650.4040252f@posting.google.com>, Michael Kreitmann wrote:

> First of all: Thanks for your answers!
> I've done another test on my P4 with activated Hyperthreading and ...
> the performance is very bad (9s <> 2s without HT).
> (The test on the 1xXeon/1800 will hopefully come tomorrow!)
>
> So: Java (?) does have a problem running on dual-processor machines ?
> Can this be right ? I can't believe, but what can I do ??

Do you have to do anything?

Do you have reason to think this is a performance issue in your
code caused by this?

What your code is doing is essentially 35 million synchronized
method calls per second. Yes, synchronization is typically more
expensive on a multiproc system.

With some JVMs on some systems, adding a synchronized(result) block
around the whole result.append() loop could reduce this overhead;
with other JVMs it may hurt.

If you need this case to perform well, you need something like the
StringBuilder class in 1.5 that isn't synchronized. The typical
app, however, isn't going to be doing 35 million StringBuffer.append()
calls per second, so it becomes a very trivial difference in
performance.

I can reproduce the behaviour you desribe, if I change to a
StringBuilder then a dual 2.4 GHz Xeon is slightly faster than a
single 2.4 GHz P4, which is pretty much exactly what is expected.

There are all sorts of interesting differences... why the 1.5 beta JVM
is slower on a single proc system ... why the IBM 1.4 JDK is slower if
you add the synchronized block I mention ... but the bottom line
is that there are very few applications where it matters. For some
it does, which is the reason why the unsynchronized StringBuilder
was added to 1.5.

Performance is important, yes, but in context.

Relevant Pages

  • Re: threads and Window.dispose
    ... >> I'm working on a large java app which was written by someone else. ... >> class SomeWindow extends Window ... > synchronization behaviour of this class is. ... It entirely possible that there is no good reason for ...
    (comp.lang.java.gui)
  • Re: PostMessage and C# multithread application - HOW IT REALLY WORKS
    ... > Hi Paul, ... You give me a reason why, so I don't need to go ... > windows owned by the same application with the windows message way. ... >> numerous synchronization issues to be handled. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Server time question
    ... but why i can do this on the workstation, do they have a different settings? ... or is they a way to stop synchronization? ... time for any reason, you should take it out of the domain, ...
    (microsoft.public.windows.server.general)
  • Re: Avoid memory collisions
    ... interested in modifying is not under my control. ... For this reason I ... cannot add synchronization to it. ...
    (comp.sys.hp.hpux)
  • HEADSUP ABI breakage for future LOCK_PROFILING + non-LOCK_PROFILING usage
    ... The following change will go in shortly unless I hear a good reason ... bottom and lock_object ha been moved to the end of all synchronization ... primitives so that a kernel compiled without LOCK_PROFILING will ... It also gets us closer ...
    (freebsd-current)