Date: Mon, 18 Dec 2006 09:19:06 -0800 (PST) From: Nick Johnson <freebsd@spatula.net> To: freebsd-java@freebsd.org Subject: Re: Performance of Java on FBSD vs. others... Message-ID: <20061218083751.T28249@turing> In-Reply-To: <200612181737.39000.achill@matrix.gatewaynet.com> References: <20061110203714.GA89006@ace.b020.ceid.upatras.gr> <B142E761BC54C0CA22CD9BFD@rambutan.pingpong.net> <200612181737.39000.achill@matrix.gatewaynet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061218083751.T28249>