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.
Have computers or JIT compilers gotten fast enough that people actually do ray tracing in Java?
Think Deeply.
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.
The two OSs were similar in ray-tracing, and Vista was faster at Java OpenGL due to shortcomings with the Linux graphics driver.
I know this will be seen as a troll, but who the hell uses Java for ray-tracing or with OpenGL?
Its possible that the Windows Java defaults to client, while the Server mode was used in Linux. That could account for the major speed improvements seen in the Linux versions. I would like to see the Server mode forced on all the JVM's and the tests re-run.
I've been using scimark for years to evaluate system performance with java.
Try it yourself.
Linux has outperformed windows (on average) for years, and OSX as well until recently. (java 1.4 performance on OSX was dismal)
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
Now, if they tested webapps performance, say on Tomcat on both OSes, the results would be quite different. I would guess Vista would be faster for a single thread test but would not scale at all.
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.
Not, strictly speaking, true...
The NTFS-3g driver for Fuse works very well, at this point, and there are ext2/3 drivers for Windows if you look for them (Albeit the free one that I know about doesn't handle journaling in Ext3).
Here you go!
My personal favorite setup is having an ext3 home directory in Linux, and using the My Documents folder in NTFS as a media directory.
Slight annoyance of having two desktops, but other than that, pretty ideal.
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.
One also has to wonder how well they "tuned" the Vista install.
Everything left to default, including desktop effects according to TFA.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
When was the last time you tried running Windows 64 bit? My experience is that both Vista 64 and Win7 64 both have great driver support now (never tried XP64, but the XPDM (XP driver model) is deprecated, so I understand why finding hardware for the platform is hard). In fact, the issues at Vista launch were largely due to moving to the new driver model, and hardware vendors not being up to speed. Two years later, those issues are no longer a problem.
Or was your comment sufficiently advanced satire that I'm missing? :)
That's gotta be the stupidest comment I've ever read. Congratulations.
Programming languages are not IO bound. Operating systems aren't IO bound. TASKS are IO bound. ALGORITHMS are IO bound.
Karma: Poor (Mostly affected by lame karma-joke sigs)
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.
See my previous comment. My Vista install still has everything turned on - and realistically it makes zero difference.
I'd suggest either the JVM sucks, or their tests sucked.
3laws: No freebies, no backsies, GTFO.
That is part of the point. Java on both platforms is very similar (though not exactly the same), so the test is more of 'Which OS is faster?' than 'Which Java is faster?'