Java Performance: Ubuntu Linux vs. Windows Vista

[phoronix]

Phoronix: Java Performance: Ubuntu Linux vs. Windows Vista

Have you ever wondered on what operating system Java works the best? While by no means is it a conclusive multi-platform comparison, for this article we ran a number of Java benchmarks on both Windows Vista Premium and Ubuntu Linux to see how the Java Virtual Machine performance differs. In addition, when running Ubuntu we had tested Sun's official Java package as well as the OpenJDK alternative.

http://www.phoronix.com/vr.php?view=13282

[ethana2]

page 2

Sunflow, in seconds
'less is better'
Ubuntu : 19.65, 19.75
Vista : 20.2

'Windows Vista was faster, but not even by a few points.'

The graph indicates the Vista was slower, I think that's a typo.
Delete this comment when issue is resolved.

[RealNC]

Linux got owned where it matters the most: Graphics.

[llama]

Phoronix: Java Performance: Ubuntu Linux vs. Windows Vista
http://www.phoronix.com/vr.php?view=13282

What was the partition layout on the laptop? As benchmarks in some of your previous 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.

[Nille]

What is with the latest Test ? where is the Sun VM on Linux ?

[kgonzales]

Linux got owned where it matters the most: Graphics.

Tell that the people running Java application servers or programs using Java on the backend. They would have a different take.

[hubick]

I don't think the results would be much different had they been implemented in any other language. That is to say, I think most of these tests probably say more about the platforms kernel and graphics drivers than it does Java itself.

[RealNC]

Tell that the people running Java application servers or programs using Java on the backend. They would have a different take.

I don't think Phoronix is for Java application server dudes.

[sc3252]

What was the partition layout on the laptop? As benchmarks in some of your previous 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.

+1 to this.
I would also like to know if it was a clean slate from benchmarking, I understand if you couldnt because of time, but it would be nice to know.

[ProTech]

Why don't you used the same version of java on both Windows and Linux. There was big changes in 6u10 (1.6.0_10). e.g.: use Direc3D to speed up rendering on Windows. So it would been better to use that version on Windows not just on Linux. Probably Linux would beat Windows with that version too.