Java on OS X

[Viro]

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?

[princec]

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

[Viro]

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.

Games published by our own members! Check 'em out!

[swpalmer]

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.

[princec]

A few years behind? I'm sorry, I don't quite understand that.

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

[swpalmer]

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

[princec]

At this stage it'll all be down to the quality of the generated code, which I bet has room to improve.

Cas

[Jeff]

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.

[Viro]

Thanks for all the replies.

[Mark Thornton]

OSX is a heck of a lot better at threading, being a Unix, then Winblows is.

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.

Games published by our own members! Check 'em out!

[rreyelts]

It isn't appropriate to tarnish all Windows variants with the deficiencies of one version.

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

[Mark Thornton]

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.

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

[rreyelts]

Most of the complaints I can find amount to Windows Threading != pthreads.

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

[Mark Thornton]

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

[rreyelts]

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

[Jeff]

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.

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

[blahblahblahh]

It isnt appropriate to tarnish real *nixs with Linux.
...
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.

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.

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

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!).

[Mark Thornton]

It isnt appropriate to tarnish real *nixs with Linux.

Sorry, that was just bait  

Example:  I have yet to have ANY version on Win32 on my desktop that didnt lock my GUI at times during secondary storage IO.)

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.

[blahblahblahh]

[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). . Who needs nostalgia when you can repdroduce the good ole days whenever you want?
[/sidetrack]

[Bombadil]

[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'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.

[cfmdobbie]

Heh - the thing that's currently annoying me is how both Mozilla and FireBird/Fox will lock completely when you visit a page with a Java applet on it.  The browser freezes while the JVM starts, so several times a day I think "It's crashed!" followed five seconds later by "Oh, no, it's just Java starting."  It's not giving me a very good impression of Java, so god only knows what most users think.

My FireBird runs with the Click-to-play Flash movie extension, which is a godsend.  Now I want Click-to-play applet support!

[swpalmer]

FYI:  Java 1.4.2 Update 1 Developer Preview is available for OS X 10.3.1 and above from the Apple Developer Connection.
Apple looks to be doing a much better job of keeping up with Sun since they did the initial 1.4 port.  Cool.

[andyl]

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?

A bit late now to reply (maybe) but I think you will find the PPC architecture is better suited (more registers for example).

The problem you are seeing is probably the lack of a server VM for MacOSX. That puts it about 3x slower than it could have been. It annoys the hell out of me, all I can suggest is you lobby Apple about it (the guys at Sun/Java gaming group don't seem overly bothered, but then it's not their platform underneath). It's a crying shame, as I suspect (with proper instruction scheduling) a G5 based server VM might be one of the fastest Java based number crunching platforms out there!

Andy.

EDIT : When I get my own G5 (soon) instead of borrowing one, I will have to try some C# or J# using mono to see what the Mac platform can really do. That'll put the cat amoung the pigeons around these parts  (yes I'm trolling)

[vredungmand]

I tried dotGnu on my macosx machine and it was a great deal slower than the Java VM.

[andyl]

I tried dotGnu on my macosx machine and it was a great deal slower than the Java VM.

That would be because dotGNU is interpreted (eventually), whereas Java eventually compiles to native code, as does mono.

[Viro]

Heh - the thing that's currently annoying me is how both Mozilla and FireBird/Fox will lock completely when you visit a page with a Java applet on it.  The browser freezes while the JVM starts, so several times a day I think "It's crashed!" followed five seconds later by "Oh, no, it's just Java starting."  It's not giving me a very good impression of Java, so god only knows what most users think.

My FireBird runs with the Click-to-play Flash movie extension, which is a godsend.  Now I want Click-to-play applet support!

That seems to be an inherent problem with Mozilla/Firebird's plug-ins. I get the same problem with Adobe Acrobat files, MS Word files, etc. And this is on an Athlon 64 with gigs of RAM so the machine ain't the issue.

[Viro]

That would be because dotGNU is interpreted (eventually), whereas Java eventually compiles to native code, as does mono.

I've tried mono on Linux a few weeks back. Running Scimark on Mono is a joke. It provides performance about equal to the client VM(1.4.2_04) on my machine. Needless to say, the server VM mopped the floor with it.

And yes, I did enable the JIT, and passed all sorts of other optimization parameters. Not much diff.

[swpalmer]

In case anyone didn't notice Java 1.4.2 Update 1 Developer Preview 2 is now available for Mac OS X  10.3.3 and above.  

[ribot]

and just as an additional note: when downloading the OS X Developer Java Updates - select to download from the US based servers rather than the European as they are ten times as fast.

[erikd]

I've tried mono on Linux a few weeks back. Running Scimark on Mono is a joke. It provides performance about equal to the client VM(1.4.2_04) on my machine. Needless to say, the server VM mopped the floor with it.

And yes, I did enable the JIT, and passed all sorts of other optimization parameters. Not much diff.

That's actually quite impressive. So on the Mac, mono is as fast as java. This illustrates the need of a server VM on the Mac. Or better yet, a merged VM everywhere.