How fast is Java on OS X? Taking a look at the Scimark benchmarks results, I see Apple’s VM consistently giving results below the 100 mark, yet other VMs like Sun and IBM give very high results.
Now I know that Scimark is a microbenchmark of sorts and the usual caveats apply, but the results are still surprising.
Is there a problem with the Apple VM, or is it something to do with the PPC architecture?
The Apple VM is a few years behind the current Windows ones but it’s not really incredibly slow… it runs my game at full speed so I’m not that fussy 
PPC architecture is slightly less well suited to the stack-oriented JVM architecture, AFAIK, but it shouldn’t be a killer.
Cas
A few years behind? I’m sorry, I don’t quite understand that. OS X is at 1.4.2, and Windows is at 1.4.2 (if you disregard the 1.5 beta). Its a year behind, at the most.
There are nice things about Java on OS X, but performance doesn’t seem to be one of them.
From a strictly computational point of view the Mac JVM seems decent - sometimes faster than Sun’s windows VM, sometimes slower, depending on what you are testing, e.g. floating point appears to be slightly faster, but some of Java Cool Dude’s demos (e.g. cloth) run very very slow. So it is hard to get a good idea in general until you actually run your app.
Where it really sucks for games is the graphics. The graphics routines are significantly slower on the current Mac VM (1.4.2_03). There is no hardware acceleration. Use JOGL or LWJGL. For now I would have to recommend JOGL (sorry Cas :)), because LWJGL has some significant compatibility issues on the Mac platform. Xith3D works well.
Given that the Apple Java team has been playing catch-up for a while to get a 1.4.2 release I am hoping that now they will have a little more time to do some optimizations that they didn’t have time for before… I could be dreaming though, cause they might be swamped with work on 1.5 so they aren’t ‘behind’ again when Sun releases it. They are working on bug fixes for their current 1.4.2 JRE as I understand it though, so maybe some performance enhancements are in the works too.
[quote]A few years behind? I’m sorry, I don’t quite understand that.
[/quote]
Sun’s VM engineers have been working on Hotspot for several years before Apple even started on their port, is what I mean. Expect the very latest clever techniques to be missing from the Apple JVM. Mostly ones in the Sun server VM, I should think.
Cas
Apple doesn’t have the server VM at all - so yah that is missing. But the rest of HotSpot 1.4.2_03 optimizations I would expect are mostly implemented, since Apple has the Sun’s code. The difference is that they have to do code generation for PPC… so that particular aspect may not be as tuned. But in terms of inlining, and eliminate redundant checks - the Apple VM should be at the same level as the client VM on windows… or maybe sightly behind if for some reason the port was complicated. (I would expect the main effort to be in the code generation for PPC though.)
At this stage it’ll all be down to the quality of the generated code, which I bet has room to improve.
Cas
FWIW my expereinces with the Apple VM is that it is as good as, or maybe even slightly better then, our Win32 VM in terms of performance.
As others point out its hard to do an exact comparison due to differences in hardware BUT on what I would consider a comperable level of machine Java programs seem to ru nas well or a bit better then in Win32 IME.
Ofcourse they have some OS advantages. OSX is a heck of a lot better at threading, being a Unix, then Winblows is. Also since they are working in a cooperative environment with their OS maker, rather then the competitive one we are, they probably have better opportunities to really tune to their platform.
Thanks for all the replies.
[quote]OSX is a heck of a lot better at threading, being a Unix, then Winblows is.
[/quote]
Do you have evidence for this or is it merely prejudice. Windows 9X undoubtedly isn’t that good at threading, but Windox NT (2000, XP) does threading quite well. It isn’t appropriate to tarnish all Windows variants with the deficiencies of one version.
Linux (is that a ‘Unix’) has until fairly recently been rather poor at certain aspects of threading.
[quote]It isn’t appropriate to tarnish all Windows variants with the deficiencies of one version.
[/quote]
Mark makes a good point here. I find that the term, “DosWindows” is a much more accurate term to use when discussing any non-NT based version of Windows.
It’s kind of misleading of him, though, to compare the threading performance of Linux to anything else. Linux is still working on basic Posix performance. It’s a “baby” Unix in that sense. In general, it doesn’t make any sense to compare generic “Unix” performance against Windows - you can talk about the difference in APIs though. Most unices provide an implementation of pthreads, which is a sound threading API. Windows, however, has a threading API that has several flaws in it. I’m sure if you do a Google search through comp.programming.threads you’ll see what I mean.
God bless,
-Toby Reyelts
Most of the complaints I can find amount to Windows Threading != pthreads. While this may be unpleasant for people trying to write portable programs (and especially efforts like cygwin), it doesn’t really indicate that either API is intrinsically worse than the other.
Note also that quite a few people are horrified at some of the more interesting threading behaviour that is legal for Java (even with the new memory model).
You’re not looking at the right threads then. Experts like Dave Butenhof complain that the API is just busted in certain ways. WaitForMultipleObjects comes to mind as an example.
God bless,
-Toby Reyelts
WaitForMultipleObjects works fine, but there is no simple mapping between it and anything in pthreads. That group has quite a few people looking for WFMO functionality in pthreads. So Win32 doesn’t work as Dave Butenhof would like it to work, and usually requires a largely separate design of the thread intensive components. Well such is life. If you want ‘easy’ portable multi-threading, forget C/C++ and use Java!
(Not that multi-threaded programming is ever really easy, but particularly with the new concurrent utilities in 1.5 Java is about as nice as it gets — in my opinion).
WaitForMultipleObjects works fine…
No, it doesn’t.
Well such is life. If you want ‘easy’ portable multi-threading, forget C/C++ and use Java!
Or use an implementation of pthreads on Windows.
(Not that multi-threaded programming is ever really easy, but particularly with the new concurrent utilities in 1.5 Java is about as nice as it gets — in my opinion).
I love Doug Lea’s library and have been using it for about the last four years. You do know that its design is based entirely around pthreads, right?
God bless,
-Toby Reyelts
It isnt appropriate to tarnish real *nixs with Linux.
Linus Torvalds for a long time resisted ANY threading model in Linux at all.
My experiecne is that WInNT threading compared to what I consider an appropriate commercial Unix (Solaris, AT&T, Berkeley Unix, etc) is klunky and erratic. Win32 has too many places where it simply locks the whole system up with competing mutexes until an operation gets done. (Example: I have yet to have ANY version on Win32 on my desktop that didnt lock my GUI at times during secondary storage IO.)
My understanding was that Solaris was still in a league of it’s own for threading? I have that paper lying around somewhere which describes how fine grained Solaris’ locking is, the benefits to performance, and the nightmare for Sun of maintaining it.
Ah…as I understand it, that’s simply total cr*p MS programmers working on the shell (Windows Explorer, and all the other MS apps that have it integrated). With recent NT’s (5 and 6) I’ve only seen this happen with MS apps, not with anything else. Oh, except Lotus Notes, which used to do it all the time because their GUI event thread was somehow shared with the network comms thread (very, very, very stupid when your app is a replicating DB system; you could lock up for several minutes every half hour on user’s desktop machines!).
Sorry, that was just bait
[quote]Example: I have yet to have ANY version on Win32 on my desktop that didnt lock my GUI at times during secondary storage IO.)
[/quote]
I don’t recall it being a problem on NT 3.51. Yes, as Blah^3 notes the current desktop/explorer stuff is deeply flawed, but it is that application rather than the threading system which is at fault.
[sidetrack]…Usually a scratched CD, or an RW in a drive that doesn’t support them, or a DVD in a CD-RW drive, is enough to knock out everything from your start menu to MSIE (which will even stop repainting!) for a minute or two. I’ve seen this on everything up to XP - and it only happens with MS apps.
It makes you feel really good that your web-browser, your shell, your desktop, your start menu, and the dialog boxes for many MS apps are all single-tasking dependent on your CD drive. MS has kindly ensured that we never forget what Windows 3.x was like (before pre-emption). ;D. Who needs nostalgia when you can repdroduce the good ole days whenever you want?
[/sidetrack]
[quote][sidetrack]…Usually a scratched CD, or an RW in a drive that doesn’t support them, or a DVD in a CD-RW drive, is enough to knock out everything from your start menu to MSIE (which will even stop repainting!) for a minute or two. I’ve seen this on everything up to XP - and it only happens with MS apps.
[/quote]
It’s for many apps actually… whenever under Win2000 I convert an CD image to another format or do similar filesystem heavy tasks, the Windows PC virtually renders unusable for that time… I see this regularly on different hardware with IDE drives.