Performance of Java on FBSD vs. others...

[Nick Johnson]

On Mon, 18 Dec 2006, Achilleas Mantzios wrote:

> Raising such an important issue as the current thread,
> i think deserves something more than complete silence.

The silence is probably because a lot of us have jobs and lives to lead 
and can't spend our every waking moment focused on Java performance on 
FreeBSD.  Few people, if any, are getting paid to work on this.  It isn't 
rational to set high expectations for responses.  I suspect performance 
comes second to functional problems and bugs as well.

I think I'd be more comfortable seeing the results of some *comprehensive* 
benchmarks, rather than just one case that seems to perform better on one 
platform than another.  If you put some thought into it, I wager you could 
always find some test case that works well on one architecture and poorly 
on another.

I'd also like to see it run on a *STABLE* branch of FreeBSD, rather than 
on CURRENT, since CURRENT is likely to be filled with all manner of 
debugging noise and so-on.  It should also be run with libthr as the 
threading library, as the consensus seems to be that this provides better 
performance than libpthread (libkse).

Wherever possible, it is important to compare apples to apples as well.  
So if the libraries and binaries are stripped on Linux, they need to be 
stripped on FreeBSD.  If it's not a debug build on Linux, it needs not to 
be a debug build on FreeBSD.  JVM garbage collection and memory allocation 
strategies need to be the same, *and they might not be by default* 
depending on how Java was compiled.

There are so many problems with the "benchmark" presented that I don't 
believe it can be used as the basis for troubleshooting performance 
problems.  We need to see a benchmark that does comprehensive testing of 
performance for a variety of Java functions on the same hardware with the 
same internal configuration.  Maybe SPECjbb2005 or CaffeineMark 3.0?

Whatever benchmark is used should be run with profiling switched on, so if 
there *is* a difference in timings, one can look at the profile data and 
see where the additional time is being spent.  It's also important to run 
the benchmarks with plenty of memory allocated to take resource 
constraints out of the picture.  I'd go so far as to set the minimum and 
maximum heap sizes to the same value to get all of the memory allocated 
up-front.

Without a clear problem definition and a methodical strategy for 
investigating any actual or perceived performance differences, you're 
taking a vague assertion and stabbing around in the dark trying to change 
it. 

   Nick

-- 
When you're a kid, they tell you it's all grow up, get a job, get married,
get a house, have a kid, and that's it.  No, the truth is the world is so
much stranger than that.  It's so much darker, and so much madder.
And so much better.
  -- Elton, Doctor Who, "Love and Monsters"
This message has been brought to you by Nick Johnson 2.1 and the number 6.
http://healerNick.com/       http://morons.org/        http://spatula.net/