[itistoday]

I heard somewhere that the JVM on OS X is slower than its windows and linux counterparts because it has to flip bytes in the background because of the different byte order (or something like that). Is this true? I do notice that java apps seem to run faster on Windows.

[larkost]

Java does take care of byteorder for you but since Java's native platform is Solaris, and Solaris's primary processor is the Sparc, and that is big-endian just like the PowerPC series, I think you have the wrong end of the stick.

If you actually benchmark processor-intensive Java apps you will find that Apple's implementation is one of the best. However, Apple decided to use a completely java based UI, rather than bridging everything into C for display like is done on the windows port. So when it comes time to draw the user interface Window's Java UI is buggier, but faster.

Personally, I would rather that Apple go in and do like the Windows version, but if it is going to be time spent working on that, or on working on the Cocoa-Java (or other) Frameworks, I think the developer time is better spent away from that project.

[itistoday]

Ah. Thanks for that Very informative.

[ideasculptor]

Originally posted by itistoday:
Ah. Thanks for that Very informative.

It is also not true. I don't know if for sure that the slowness is a byte ordering issue, but there is no question that java on the mac is MUCH slower than on an x86 platform in windows, linux, or BSD. I write server apps in java (no interface whatsoever), and the consistently run at 80-85% (at best) of the speed they run on an x86 CPU of equivalent clockspeed. Given that the G5 is supposed to be faster, clockcycle for clock cycle, than x86, it implies that the JVM is running at less than 80% the speed it runs on x86, on equivalent hardware.

Our tests have been with equal RAM and similar disk, so it isn't an issue with other aspects of the hardware. The JVM from apple just plain runs SLOW. And just because the G5 uses the same byte order as a sparc doesn't mean that Sun made the native byte order of Java big-endian. Given the prevalence of litt-endian processors in the world, they would have been smart to make the native byte order of Java little endian. That would certainly explain the terrible performance of java on OS X.

--sam

[itistoday]

I guess the truth hurts?
Whatever the case may be, I hope Tiger brings a better version of java to OS X.

[smitty825]

Actually, Sun's Sparc chip supports operating in both big & little endian mode. (http://developers.sun.com/solaris/articles/sparcv9.pdf -- see page xix) (IIRC, Solaris is run as Big Endian) All PowerPC chips (with the exception of the G5) can also run in big or little endian mode.

Also, for Java, all data is stored in big-endian format. In Java 1.4, a class called ByteOrder, which can be used to read and write binary files in either format...

[__^^__]

Originally posted by smitty825:
Actually, Sun's Sparc chip supports operating in both big & little endian mode.

As does the PPC family.

[Chuckit]

Which smitty pointed out when he said, "All PowerPC chips (with the exception of the G5) can also run in big or little endian mode."

[itistoday]

Originally posted by Chuckit:
Which smitty pointed out when he said, "All PowerPC chips (with the exception of the G5) can also run in big or little endian mode."

I don't understand. How can the G5 not support little-endian? There are a lot of files that use that specific format (videos, images, etc).

[Thinine]

All he means is that the G5 doesn't have the pseudo-little endian mode that the G4 and G3 have. That's why VirtualPC had to be overhauled to support the G5, since it relied on the pseudo-little endian mode to process x86 instructions. This is just processor level support and all instructions issued by Mac OS X to the processor will be PPC, which is big endian. Except when pseudo-little endian mode is envoked on the G3 or G4. Not a great explanation but that's all I got for now.