Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Programming Operating Systems Software Windows Linux

Java Performance On Ubuntu Vs. Windows Vista 258

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."
This discussion has been archived. No new comments can be posted.

Java Performance On Ubuntu Vs. Windows Vista

Comments Filter:
  • by Thelasko ( 1196535 ) on Friday December 19, 2008 @10:52AM (#26173267) Journal
    that new 64-bit Java plugin for Linux is smokin! No waiting for applets to load or anything.
  • by Smidge207 ( 1278042 ) on Friday December 19, 2008 @10:53AM (#26173279) Journal

    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=

    • by xouumalperxe ( 815707 ) on Friday December 19, 2008 @11:34AM (#26173763)

      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.

      • by chrb ( 1083577 ) on Friday December 19, 2008 @11:46AM (#26173913)

        even then the performance difference is too large to be attributed to which bit of the disk you're reading

        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.

        • 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.

          True, reducing statistical bias is an important point. So is taking all the data into account and making sure your conclusions are consistent with all of it -- and doing so while not adding superfluous factors to the equation.

          My argument came in two points. First, that the performance difference was too big to be attributed to disk layout (which you then countered with faulty sectors, which is grabbing for straws). Moreover, I stated that the result was consistent with the other tests. Which is likelier: "t

    • by chrb ( 1083577 ) on Friday December 19, 2008 @11:35AM (#26173779)

      Various problems with the Phoronix test methodology have been noted before [slashdot.org] and before that [slashdot.org]. Without going over the same stuff, here are some potential questions about this benchmarking:

      • Where is the statistical analysis of these results - ok, you ran a test once and it was 30% slower. Is this reproducible? What is the variance? Is there any statistical difference between openjdk/sun java?
      • Why is the Java minor version different? Do you see the same results if the same minor version is used?
      • As mentioned in the previous discussions, exactly why is Windows slower on the file encryption task - it should be either limited by disk throughput, or by CPU throughput, so observing a 40% drop in performance attributed to the underlying I/O handling of the operating system is somewhat surprising; are you sure the test methodology is sound here, and if so, how do you explain the results?
      • Are these results applicable to both 32 and 64 bit distributions and JDKs?
      • How do you know that the 2D benchmark performance on Linux is attributable to poor graphics drivers? Why not run the test on another PC and then swap out graphics cards (hence eliminating all other factors) and report on the results?

      There are a lot of questions that this benchmarking should have answered, and a lot of assumptions made that could potentially be invalid.

    • by LWATCDR ( 28044 )

      One also has to wonder how well they "tuned" the Vista install.
      Was it running antivirus or indexing in the background?
      Vista tends to have a lot of "stuff" running in the background. A lot of of which you can turn off.
      They also really should have used the .10 release. It was a huge point release.

      • Stock configurations (Score:3, Informative)

        by DrYak ( 748999 )

        One also has to wonder how well they "tuned" the Vista install.

        Everything left to default, including desktop effects according to TFA.

      • 'Vista tends to have a lot of "stuff" running in the background. A lot of of which you can turn off.'

        That is a design decision of the operating system. An optimized system is NOT representative of average vista performance. A default install is.

      • Re: (Score:3, Informative)

        by ozphx ( 1061292 )

        See my previous comment [slashdot.org]. 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.

  • that's odd (Score:4, Insightful)

    by z-j-y ( 1056250 ) on Friday December 19, 2008 @10:56AM (#26173301)

    those tests (CPU burners) should perform the same on Linux or Windows, I don't see why JVM would behave differently.

    • Re:that's odd (Score:5, Informative)

      by Shados ( 741919 ) on Friday December 19, 2008 @10:58AM (#26173321)

      They -are- different JVM builds, so its possible (as is common in the JVM's history) that some bug fixes improve performance wildly... Not across the board though, so something's wrong, either with the JVM, or with Windows itself... but something is seriously messed up.

    • by MancunianMaskMan ( 701642 ) on Friday December 19, 2008 @11:02AM (#26173367)
      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.
      • Excellent point, u10 was the next "major" minor release after u07, check out the release notes for it here, they're... long.

        http://java.sun.com/javase/6/webnotes/6u10.html [sun.com]

      • by samkass ( 174571 )

        Indeed, the u10 version of JDK6 is probably the biggest "point" release Java's ever had. For some strange reason Sun has decided not to use the last decimal point of their version numbers, but really this was JDK 1.6.1.

        Any comparison of pre-u10 benchmarks with u10-or-later are pretty much completely invalid. This is especially true on Windows, which now uses hardware accelerated pipelines all over the place, so will probably be even more dramatically faster than Linux on the graphics tests.

      • Re: (Score:3, Informative)

        by jfim ( 1167051 )

        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.

        Indeed, this is a fairly lame benchmark. Java 6 update 10 is when they switched to the "consumer JRE" (also known as update "N"), which included a lot of changes to lower the footprint of the JRE, improve startup time, etc.

      • Yeah, that's a pretty bad comparison. Were the testers at Phronix completely unaware of the performance work Sun has been putting into update 10? They've only been talking about it for like a year.

      • Re: (Score:2, Interesting)

        by Vellmont ( 569020 )


        they used java 1.6.0_10 on linux and 1.6.0_07 on windows.

        Yah, and they also tested with the new openJDK 1.6.0_0, which had nearly identical results as Suns JVM. The differences between Windows and Linux are NOT subtle, and you normally don't get 3x performance increases with mature code. So I have a hard time believing that these major performance differences are really from going from 07 to 10, especially when you factor in the results from openJDK.

        I still think it'd be interesting to repeat the tests wi

    • those tests (CPU burners) should perform the same on Linux or Windows, I don't see why JVM would behave differently.

      They left on Aero, and acutally spent more money to get the version of Vista with it. The graphics chip was the weakest integrated chip that, according to the manufacturer, supported Aero. In reality, no doubt, the Intel chip pushes work onto the CPU because we know what happens when a manufacturer claims that the hardware is just able to support a feature. Hell, even their website phrases

      • by nxtw ( 866177 )

        The graphics chip was the weakest integrated chip that, according to the manufacturer, supported Aero. In reality, no doubt, the Intel chip pushes work onto the CPU because we know what happens when a manufacturer claims that the hardware is just able to support a feature. Hell, even their website phrases the compatibility in weasly terms.

        The article mentions that the laptop uses the PM965, which is the GPU-less mobile chipset - they probably mean GM965. The GM965 isn't the weakest Intel GPU than can run A

    • The JVM still has to work with the OS to make things work so things are different between the the JVMs and performance can vary depending on how the underlying OS deals with certain things.
    • by Fweeky ( 41046 )

      Java has quite a few tuning options; limits on heap and garbage pool sizes, different garbage collectors and strategies for running them, different optimization levels. Maybe it's defaulting to client mode on Windows, thus putting more effort into reducing memory use by running the gc before growing the heap (and placing stricter limits on its size and the sizes of the gc generation pools), doing less aggressive optimizations and putting them off later.

      Java also has bit of a history of enjoying cheap sys

    • First of all, I think it's interesting that someone would bother to use Java (instead of, say, C) for ray-tracing. I guess JVMs have come a long way.

      those tests (CPU burners) should perform the same on Linux or Windows, I don't see why JVM would behave differently.

      Yep, although if they had used a more interesting test machine (dual Opterons instead of a single CPU), then the different kernels (not JVMs) might have made a difference, thanks to NUMA-related issues.

    • The two JVMs are different, and actually use different logic inside. One has to use the POSIX APIs while the other is using Windows APIs to get to OS services like reading files and drawing to the screen.

      But you are correct if the test is a simple compute loop. One would think it should be the same. But no not really because one JVM was built with gcc and the other with some Microsoft compiler. Simply upgrading gcc might change the result. The JVMs really are different

  • Ray tracing in Java (Score:4, Interesting)

    by olddotter ( 638430 ) on Friday December 19, 2008 @11:04AM (#26173393) Homepage

    Have computers or JIT compilers gotten fast enough that people actually do ray tracing in Java?

    • by Yetihehe ( 971185 ) on Friday December 19, 2008 @11:10AM (#26173483)
      Yes. Sunflow [sourceforge.net] is one example. I did my own tests, java vs c++ (almoste the same code) and java was only about 1.3 times slower.
    • by shutdown -p now ( 807394 ) on Friday December 19, 2008 @12:20PM (#26174293) Journal

      Compared to plain C/C++ code (no non-standard compiler intrinsics etc), Java has been fast enough for a long time now. Think about it: it's all just math, and JIT (which may itself be slow - it doesn't matter!) generates pretty much the same native code as a C compiler would. g++ can still do some trickier optimizations, which may account for the odd 5-10% of difference; but hardly more than that. .NET can actually fare even better, because it supports raw unsafe code and data pointers with arithmetic, dynamic allocation of stack memory (alloca), and unions - this essentially covers all optimization tricks available in ANSI C.

    • Have computers or JIT compilers gotten fast enough that people actually do ray tracing in Java?

      I can believe it could be. Java can be just as fast as C as long as you write code the way you'd write it in C. That means statically allocating your data in arrays and avoiding creating new objects (which results in allocation, constructor and GC overhead, as well as cache thrashing).

      The problem most people have with Java performance is that most problems become very unwieldy if written in a C-like fashion, and everything in the Java language and culture encourages new object creation rather than reuse of

    • Java is not much slower once it gets going in a loop (like ray-tracing, where it runs the same chunk of code over and over again), because once it is compiled it will run as assembly code.

      In my experience, the thing that java does the worst on performance-wise is arrays: it has to check to make sure you don't overflow the array. This can slow down an array-element access as much as 10 times. I actually knew a guy who was so annoyed that he wrote a java pre-processor that converted his array into a seque
  • Fairness (Score:4, Insightful)

    by abigsmurf ( 919188 ) on Friday December 19, 2008 @11:04AM (#26173399)
    I love the way in every test test Vista loses it's "Ubuntu is faster" but in the test where Vista wins, they explain and excuse it going "bad opengl drivers".

    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.

    • Re: (Score:2, Insightful)

      When "Vista is known for being slow at this sort of thing", that's a cause of the OS itself, which is different than something that the OS relies on. You can't say that Vista lost at some benchmark because it's a shitty OS, therefore, it's not fair to call it a shitty OS.
    • Re: (Score:3, Insightful)

      by Chirs ( 87576 )

      Likely they mention the issue being the graphics drivers in linux because graphics drivers are a continuing sore spot.

      As for disk access, in my experience the vast majority of disk access speed issues are not driver related, but are due to the I/O subsystem, elevator algorithms, and filesystem code in the OS.

      • Graphics drivers have been continually improving on Linux.

        Intel, Nvidia and ATI hardware all works MUCH, MUCH better than it used to.

        Not that things are perfect, but it's important to point out that things are getting better all the time.

        • by jo_ham ( 604554 )

          Just to latch onto this with someone who's had more experience with it, I just recently installed Ubuntu 8.10 onto my 15" Powerbook to give it a go (1.5Ghz, ATI 64Mb graphics), and it runs much hotter than OS X.

          I was expecting something like this, since obviously all the OS X software is tuned up to work with the Powerbook, and that Ubuntu is doing its best but can never be as good [at using the sensors and fans] as OS X without extra help from Apple.

          I installed the sensor applet and am getting consistent 5

    • Re:Fairness (Score:5, Insightful)

      by Vellmont ( 569020 ) on Friday December 19, 2008 @11:16AM (#26173551) Homepage


      I love the way in every test test Vista loses it's "Ubuntu is faster" but in the test where Vista wins, they explain and excuse it going "bad opengl drivers".

      Maybe that's because Ubuntu is an open source application where we actually know why the test gave bad performance, and actually know that it's going to improve in the future?

      Who's to say the Vista performance gap wasn't caused by bad drivers?

      Don't dismiss the advantages of an open system where you can actually understand what's under the hood as just "test bias".

      • Re: (Score:3, Insightful)

        by abigsmurf ( 919188 )
        Sorry, that's just a stupid argument. Because an application is closed source they're never going to boost performance? Because you can't see the source code, you don't know if it's drivers causing bad performance?

        You can see through benchmarking and general usage where an application is falling down in performance terms, is doesn't matter if you've access to course code or not. You say Vista will never have it's performance boosted? Have you seen the comparisons between a clean install and the latest up
        • Re: (Score:2, Interesting)

          by Vellmont ( 569020 )


          Sorry, that's just a stupid argument. Because an application is closed source they're never going to boost performance?

          No, because the OS is closed source you'll always be at the mercy of the license provider to boost performance. Honestly, how much does Microsoft _really_ care about Java performance? Not a hell of a lot.

          Besides which, benchmarks are for the here and now. OpenGL drivers may improve for Linux, Vista may improve its file handling, JavaVMs may see better optimisation, heck, even the damn ben

          • Re: (Score:3, Interesting)

            by jellomizer ( 103300 )

            By your argument Linux in theory should be light-years faster then Windows Mac OS or any other OS. However there are things that are slow in Linux. Why is Open GL so slow. Couln't you make MesaGL faster and more compatible with OpenGL.

            You may be at the mercy of Microsoft yes Microsoft may not care about Java vs. its own .NET platform. However if Microsoft could whip Linux in Java Performance they would love it. Fine Vista loss these benchmark but the excusing the one area it did win was in very poor tast

          • by Splab ( 574204 )

            I bet you are also the kind of Linux fanatic who keeps telling people, "the source is right there, fix it yourself".

            Even though source code is available it can be quite a daunting task to figure out why something is running slow, end even then you are still faced with the task of making it go faster. Poking around some CMS or other (usually) small scale system with a few thousands lines of codes is not a biggie, but trying to fix something with 100.000+ lines of code is pretty much impossible unless you hav

      • by Ed Avis ( 5917 )

        Maybe that's because Ubuntu is an open source application where we actually know why the test gave bad performance, and actually know that it's going to improve in the future?

        I don't think you can assume that. Remember the recent benchmarks showing that Ubuntu had become slower in recent releases? Even if those were flawed, you still can't assume that future releases will be faster, any more than you could assume that future Windows releases will be an improvement. It's quite possible for software to get


        • It's quite possible for software to get slower not faster.

          Very true. I guess I was referring to this specific instance, where the article mentions the openGL layer of Mesa wasn't geared towards performance yet, but eventually will be.

        • It's quite possible for software to get slower not faster.

          Indeed, that's what history has shown us. Software usually gets fatter and slower. All the achievements done by the hardware folks is normally negated by the software.

      • by chrb ( 1083577 )

        we actually know why the test gave bad performance

        No we don't. If they had compared many different graphics cards on the same Linux system, and shown that there was some performance degradation on a particular card that occurred every time the test was run, then we might know why the test performed badly. At the moment the idea that it was the graphics drivers is just a hypothesis.

    • After all, that's what everyone is going to be running on their laptops from now on, right?

  • 3D in Java? (Score:4, Insightful)

    by SilentChris ( 452960 ) on Friday December 19, 2008 @11:06AM (#26173435) Homepage

    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?

    • Re:3D in Java? (Score:5, Informative)

      by Nicopa ( 87617 ) <nico@lichtmaier.gmail@com> on Friday December 19, 2008 @11:11AM (#26173493)

      I think you should check the Java port of Quake then: http://bytonic.de/html/jake2.html [bytonic.de]

      • Grandparent asked who USED it, not "who created pointless, idiotic demos of it".

        If you bought a copy of Quake, would you get the Java one? No? Then nobody uses it.

    • It's just a model. Oh, I mean "test".

    • I know this will be seen as a troll, but who the hell uses Java for ray-tracing or with OpenGL?

      I'm not sure about the former, but there have been some interesting uses of the latter. Check out Jake2 [bytonic.de] sometime. It's Quake2 recoded in Java with full OpenGL support. Obviously it's not going to perform as well as it's native counterpart, but it is very playable and cross-platform.

    • I can't gauge it's performance relative to a c-based raytracer, but you should really checkout Sunflow [sourceforge.net].

      It can produce gorgeous results, and it'll use as many cpu's as you can throw at it. I'm not sure how much commercial use it enjoys, but it's well beyond the "ooh check out this glass sphere" java raytracer applets you typlically see.

  • by Yahma ( 1004476 ) on Friday December 19, 2008 @11:07AM (#26173451) Journal
    While interesting, the results pose more questions than they answer. I can see several problems with the benchmark:
    • Slightly different Java versions used in the tests.
    • The tests should have all been forced to use either Client or Server mode.

    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.

  • Not surprising (Score:4, Interesting)

    by greg_barton ( 5551 ) <greg_barton&yahoo,com> on Friday December 19, 2008 @11:08AM (#26173459) Homepage Journal

    I've been using scimark for years to evaluate system performance with java.

    Try it yourself. [nist.gov]

    Linux has outperformed windows (on average) for years, and OSX as well until recently. (java 1.4 performance on OSX was dismal)

  • I was surprised (Score:5, Insightful)

    by spottedkangaroo ( 451692 ) * on Friday December 19, 2008 @11:14AM (#26173537) Homepage

    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.

    • Re:I was surprised (Score:5, Interesting)

      by LWATCDR ( 28044 ) on Friday December 19, 2008 @12:09PM (#26174191) Homepage Journal

      You shouldn't be.
      Most java development these days takes place on the server side. Linux is has a large precentage of the server market. Then you must know that Sun is a Unix company. They push Solaris and java on Solaris. Solaris is a lot more like Linux than Windows. The the final piece is that in the Windows server market Java shares space with .net.
      So as far as the amount of attention I would say that Solaris/Linux/Unix gets just as much attention as Windows does.

    • I'm also surprised, but for another reason. A few years ago, it was common knowledge that Sun optimizes Java for Solaris first (duh), Windows second (Sun has a long history of "partnership" with MS), and Linux last (why support competition for the server market?). Either things have changed, or the study isn't all that good. Seeing how they compare two different Java releases, I guess it's the latter.

      • Re: (Score:3, Insightful)

        But Microsoft spends a huge amount of effort making sure that Java is a slow as possible on Windows machines.

        Take Hero Designer, takes a few moments to start on both machines. But leave it running, and then go out to lunch. On Linux its there waiting for you, on windows you're better off rebooting, than you are trying to switch back to it.

        • But Microsoft spends a huge amount of effort making sure that Java is a slow as possible on Windows machines.

          Do you have links to prove it?

          Do not assume (Microsoft's) malice where (Sun's) incompetence is enough to explain things.

          By the way, why would Microsoft deliberately make Java run slow under Windows? It makes no marketing sense - it just means that whoever wants Java (which is a lot of people) would just use a Solaris or Linux server instead - and that isn't good for MS. They'd rather have you run Jav

          • But Microsoft spends a huge amount of effort making sure that Java is a slow as possible on Windows machines.

            Do you have links to prove it?

            Do not assume (Microsoft's) malice where (Sun's) incompetence is enough to explain things.

            Gee I don't know, how about the non-public APIs they use, vs the public APIs they give everybody else? Was even documented in the MFC/C++ manual, that Microsoft did not use that API for office.

            You'll also notice that while they made C# an open standard, they did not make the standard API part of they.

            By the way, why would Microsoft deliberately make Java run slow under Windows? It makes no marketing sense - it just means that whoever wants Java (which is a lot of people) would just use a Solaris or Linux server instead - and that isn't good for MS. They'd rather have you run Java on Windows Server and pay them for the license (bonus points if you also use MSSQL, which is my Microsoft actually provides JDBC drivers for SQL Server [microsoft.com]).

            How about because they want to lock you into their product suite with C# and asp?

            Microsoft does not play nicely with others, ever. Even when MS is being nice, never trust them, they're like a crack dealer givin

  • So javaQuake in an applet viewer is faster, try using ANY browser available for Ubuntu and load the applet in it... now use a naked IE activeX control (or even an IE window) to host the applet.

    Linux fails, because the overhead of running ubuntu gets COMBINED with the overhead of running FireFox of Epiphany or whatever, whereas windows overhead already includes IE.

    Pretty much the only thing "taxing" I use my laptop for is playing Runescape (browser hosted 3d rendered 100% java applet MMORPG) and with the
    • Pretty much the only thing "taxing" I use my laptop for is playing Runescape

      Please turn in your geek card now.

      • A laptop dedicated to an weird MMO is not geeky?

        I didn't say it was the most taxing thing I do on computers, just on that particular laptop...
        • A laptop dedicated to an weird MMO is not geeky?

          Nethack would be geeky, Runescape is just wrong...

          N.B. I'm mostly kidding.

    • by NullProg ( 70833 )

      it is 100% flawless under windows in IE and almost unplayable in Ubuntu for any combination of browser and JDK that I have tried

      Your doing something wrong. What I dont know (Make sure your using the SUN JVM instead of the default OpenJDK). My twelve year old plays the premium Runescape every day under Ubuntu+Firefox, no problems and its much faster than the windows machine.

      Enjoy,

    • Linux fails, because the overhead of running ubuntu gets COMBINED with the overhead of running FireFox of Epiphany or whatever, whereas windows overhead already includes IE.

      Yes, because IE is compiled with -fomit-instructions and runs infinitely fast.

    • Re: (Score:2, Informative)

      by nxtw ( 866177 )

      Linux fails, because the overhead of running ubuntu gets COMBINED with the overhead of running FireFox of Epiphany or whatever, whereas windows overhead already includes IE.

      Nonsense. Windows overhead doesn't "include" IE; the shell uses the IE rendering engine. If you run Firefox in Linux, you've got one copy of the Firefox rendering engine loaded and you're using that copy of it in Firefox. If you run IE, you've got one copy of rendering engine loaded and both the shell (explorer.exe) and Internet Explo

  • by BigGerman ( 541312 ) on Friday December 19, 2008 @11:32AM (#26173731)
    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.
    • by Shados ( 741919 )

      If you wanted to do that, then you'd want to test on WinServer 2008, not Vista, in which case it definately WOULD scale.

    • Dunno about that. We have a tomcat app as our main product, and we've found invariably that Linux performs better than Windows with it.

    • Java on desktop is irrelevant in what way? As in the performance is good enough that it doesn't matter or as in it's not really used on the desktop, anyway? I'm curious because I have several java desktop apps that I use on a regular basis in both windows and linux.

    1. On Windows they use 1.6_07, while on Linux they use 1.6_10. With different JVMs. So we have different JVMs with potentially different levels of optimization, and potentially different supporting JARs.
    2. They use Windows Vista SP1, which is a desktop OS version. Ubuntu is not. They should have tested on Windows Server 2008 SP1 or SP2-Beta.
    3. They use a graphics-intensive benchmark like OpenGL. Duh. No wonder Vista out-performs: you're testing the video driver, not the Java code or the OS internals.
    4. They use
  • Interesting how much quicker Ubuntu is, especially since the sun java should be built off the same codebase...

    I was always under the impression that Intel graphics chipsets were well supported by Linux and had faster opengl performance than windows running on the same chipset, at least some games like quake3 seemed considerably quicker on linux when using intel chips, or is it OSX that has lousy intel video drivers?

    It would be interesting to add XP into the mix and see if java performs any better on that, a

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Working...