Slashdot Mirror
Java Performance On Ubuntu Vs. Windows Vista
Henckle writes "Phoronix did a comparison of the Java performance between Ubuntu and Windows Vista. They tested both Java and OpenJDK on Ubuntu 8.10 and Java on Windows Vista Premium SP1, all with stock configurations. To no-one's surprise, Ubuntu was faster in a majority of the tests. The two OSs were similar in ray-tracing, and Vista was faster at Java OpenGL due to shortcomings with the Linux graphics driver."
that new 64-bit Java plugin for Linux is smokin! No waiting for applets to load or anything.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Just out of professional curiosity: what was the partition layout on the laptop? As benchmarks in some articles have shown, the early part of a drive is faster than later part (sequential transfer rate). With a constant areal density, data flies under the read/write heads faster on the outer larger-radius tracks.
This is a something that's hard to get right when benching win vs. lin on the same HW, since usually you have a fairly normal dual-boot install, and one has the advantage of the outer tracks.
It's probably not a big deal if you have two adjacent 10 or 15GB partitions, with a big data partition somewhere else.
Ideally you'd re-partition and run benchmarks with each system installed to the first few GB. To get reasonable numbers for I/O dependent tests, you could make a scratch partition that you reformat to ext3 or ntfs before running the tests. Then have I/O benchmarks do their work in that scratch partition). (or XFS, see my previous posts for XFS tuning . XFS's delayed allocation means it doesn't start writing until you runs low on RAM, or it otherwise decides it's time to start. This means uninterrupted reading for longer = less seeks = faster.) This tests fresh filesystems, not somewhat worn filesystems that everyone will actually have after even a day of use, but usually it's not a big difference because most filesystems don't suck that badly when they're not close to full.
I thought Vista SP1 was supposed to fix slow file I/O. Oh, IIRC, that was just slow file copying when you do it via the GUI shell. So never mind, I guess either your partitioning really skewed things in favour of GNU/Linux, Vista sucks at the file-encryption workload, or it was CPU-limited and the older JVM on Vista loses on that code.
Oh, well, sorry for the rambling, just my $1.00-.98....
=Smidge=
Is it just my observation, or is eldavojohn an idiot?
those tests (CPU burners) should perform the same on Linux or Windows, I don't see why JVM would behave differently.
they used java 1.6.0_10 on linux and 1.6.0_07 on windows. Hate to give the benefit of the doubt to ballmer & co but in spite of the minor version number, a lot of work in performance has been done on Java recently. The result is pretty meaningless.
Either give possible reasons for slow performance of one OS each time or don't do it at all. To excuse bad performances in a benchmark in such a selective manner reeks of bias. Who's to say the Vista performance gap wasn't caused by bad drivers? Indeed the a lot of the tests where it was slower are ones involving disk access and Vista is known for being slow at this sort of thing.
You're having a hard time picking between Linux or Windows? Go Linux, it's cheaper to change your mind.
Yes. Sunflow is one example. I did my own tests, java vs c++ (almoste the same code) and java was only about 1.3 times slower.
Extreme Programming - Redundant Array of Inexpensive Developers
I think you should check the Java port of Quake then: http://bytonic.de/html/jake2.html
To no-one's surprise, Ubuntu was faster
I'm surprised.
I'd expect Java to go faster in windows. I don't think the reasons for using Linux are speed and software availability. I'd expect much more attention is paid to the windows versions.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
Indeed, you're rambling. Partitioning schemes are not very relevant for this test suite. The only test that could realistically be considered HDD-bound is the file encryption one, and even then the performance difference is too large to be attributed to which bit of the disk you're reading. I'd guess that on-the-fly encryption is must more CPU-bound than it is HDD-bound, and under that light that test proves consistent with all the other raw maths performance tests.
If anything, what I'd like to see is the 3D rendering bit redone with an nVidea card (that actually has decent drivers), to actually test their assertion that the performance loss on the linux side is really due to the graphics drivers.
Various problems with the Phoronix test methodology have been noted before and before that. Without going over the same stuff, here are some potential questions about this benchmarking:
There are a lot of questions that this benchmarking should have answered, and a lot of assumptions made that could potentially be invalid.
No it isn't. How do you know that a particular sector of the hard disk isn't failing, causing access to that one sector to be a thousand times slower than other sectors? This is why experiments are supposed to be run many times, across different platforms, and the aggregate results taken. Without multiple experimental replicates you have no way of showing that the results you observe generalise at all; the observed problem could just be one bad run.
Yeah its pretty much assclowing IMO. I just booted my Vista laptop this morning. Process explorer shows 9300B idle cycles vs around 200B for other shit (mostly Opera, Steam, and sony's shitty phone sync). Taking them out we're left with bugger all - around 10B cycles "wasted" by default Vista services etc (well, actually SetPoint, AVG, Daemon tools, but regardless). Most of these aren't actually doing anything, just sitting there having started and are now idle. Looks like close as makes no odds 100% CPU avaliable for their JVM.
So according to this, the OS has fuck all overhead in terms of services. So either the kernel is managing the 50% overhead we saw in the SciMark test - or their tests / JVM are crap.
I'd tend towards thinking the latter.
3laws: No freebies, no backsies, GTFO.