Sam Pullara of BEA got into a friendly bet on the speed of Java versus Objective-C. His hypothesis was that Java should actually be pretty damn fast due to the amount of work put into the runtime (JIT). He reused a String benchmark that is used to compare JRockit and HotSpot, and Java did very well.

Of course the usual disclaimer: benchmarks are flawed. This is just ONE minor test.

Sam also created an ANSI C version, which Java still managed to beat (even with optimizations turned on).

Read Sam in Looks like Apple should "switch"

Following this logic, BEA should switch to C or assembly then.

This kind of benchmark is helpful in improving VM/language implementation, however nobody switch platform or language based on a single benchmark.

Following this logic, BEA should switch to C or assembly then.This kind of benchmark is helpful in improving VM/language implementation, however nobody switch platform or language based on a single benchmark.

He is saying the speed argument can't be used against
switching to java. He is not saying switch to java
because it is faster.

Following this logic, BEA should switch to C or assembly then.This kind of benchmark is helpful in improving VM/language implementation, however nobody switch platform or language based on a single benchmark.

[Trying this again]

I think you should RTFB. When advocating greater support of Java by Apple, he was pegged by people who said that Java would slow down the system compared to ObjC. The benchmark was just a way of showing that the current JVMs are definitely no slouch compared to ObjC.

God bless,
-Toby Reyelts

Java is a second-class solution on OS X because Java calls have to pass over the Java->Cocoa bridge to get to the UI layer. The only thing you could do to remove the bridge would be to rewrite the Cocoa layer in Java. Which would be the very definition of switching platforms.

The other problem with Java/Cocoa is Java's static typing: the dynamically typed languages that bridge over to Cocoa (PyObjC, RubyCocoa) can bring in Objective-C objects without any prior knowledge of their classes, allowing them to make use of any API that Objective-C programmers can use. RubyCocoa's, for example, just has one object to represent all Objective-C objects, which implements the "method_missing" method to redirect all method-calls to the C layer. In Java, on the other hand, everything needs a concrete type with defined methods, so the ObjC objects need to be translated into the appropriate Java type by the bridge, which is why there's a lag of support for certain APIs.

The reason Cocoa is Objective-C based is that it was inherited from NextStep. The advantage of evolving Cocoa from NextStep was that Apple got a mature, proven set of APIs that are really, really good for GUI development. (I'm a complete novice with Objective-C, but even then I'm far more productive in Cocoa+ObjC than I am in Java+Swing) The disadvantage was that it bound them to a language that while quite elegant, isn't used by anyone else.

The disadvantage was that it bound them to a language that while quite elegant, isn't used by anyone else.

VisualBasic[.NET] comes to mind (except for the elegant part)

The only thing you could do to remove the bridge would be to rewrite the Cocoa layer in Java. Which would be the very definition of switching platforms.

While researching a ServerSide discussion on Eclipse/SWT on the Mac (and in particular why they used Carbon APIs not Cocoa ones), I found the following piece of advocacy:

http://www.osnews.com/story.php?news_id=6054

This puts a strong case for Apple to port its Cocoa application framework to Java. Cocoa is powerful (apps written in it make all other seem to suck - IMHO) and mature.

Critics will say "Oh no, not a third set of UI classes", but Swing is still overweight and has an excessive learning curve (140 classes and interfaces for the swing.text packages alone - horrible), and critics of SWT continually point to its immaturity on some platforms.

(FX: Dons flameproof jacket.)

So, why not? Why shouldn't we persuade Apple to take a tried, tested, and very successful UI framework and use it for Java? After all ancestors of Cocoa (OpenStep) ran on Windows...

/david

The only thing you could do to remove the bridge would be to rewrite the Cocoa layer in Java. Which would be the very definition of switching platforms.

While researching a ServerSide discussion on Eclipse/SWT on the Mac (and in particular why they used Carbon APIs not Cocoa ones), I found the following piece of advocacy:http://www.osnews.com/story.php?news_id=6054This puts a strong case for Apple to port its Cocoa application framework to Java. Cocoa is powerful (apps written in it make all other seem to suck - IMHO) and mature.

there already is Cocoa Java. just not many use it since ObjC is so much nicer. (and erm, cocoa like :)

Do you imagine Apple tying their GUI framework to a proprietary (though free) License, that could be changed at any point by its COMPETITOR in the computer hardware industry?

Get real!

One does not switch between programming languages because one micro-benchmark is faster.

Apple would need to factor in existing code (I'd imagine its a non-trivial task to port it over to Java) and existing customers who have invested mindshare into the current setup.

There would need to be a hugely compelling reason to switch to Java. And I just don't see it.

I'm not familiar with cocoa. But if it was something Java developers wanted to work with, why not just improve the Java bindings to it (e.g. via a native library like SWT?)

Editors: This is a pretty minor story to have on the front page (Java benchmarks are commonplace). Is there nothing more significant going on other than a few random blog postings lately? Why not did up some dirt on when Java 1.5 is coming out of beta?

Cheers, Peter
ADV: JBoss and Tomcat Hosting - [rimuhosting.com]

The editors must be on holidays and are updating the site content from somewhere in Carebean.

The editors must be on holidays and are updating the site content from somewhere in Carebean.

No, Vegas.

And trust me, it's nowhere near a vacation for them right now.

--
Cedric

I beleive that potential Java performance problems cannot be detected by microbenchmarks. As author says, modern Java VMs are very, very fast and VMs compilers optimize microbenchmarks' code pretty good. I would be suprised to see that Java falls more then 2x against C/C++ in any microbenchmark (except maybe some benchmarks optimized for i.e. Pentim 4 SSE instructions etc...) and I beleive that in most microbenchmarks Java will be on pair with C/C++, somewhere even faster.

The potential problems with Java performance are not in code execution, but in memory footprint. There are a lot of classes to be loaded, a lot of objects to be instantiated and all Java APIs are object-oriented and interconnected. This is the same problem I alredy saw in Borland Delphi environment (which is also object-oriented with interconnected APIs, with a lot of classes; although Delphi's Object Pascal is native compiled, class library (VCL) is smaller then rt.jar and the memory footprint problem is not so obvious as in Java). And this is also problem with .NET.

Sun recognises this problem (better late then never) and is starting to solve it in J2SE 1.5/1.6

Mileta

Java using Pascal like strings (it's stores length of the string).
_Default_ C implementation use ASCCIZ string. So if string has a different length
Java can tell immediately that strings are unequal. With ASCIIZ string you have to scan whole string to find the length. If you want to compare Apples to Apples or use different String implementation in C or make all strings same length.

To Sam Pullara: Please do your home work next time ... it's a shame to see articles like that.

Also, constant strings are used, so, in this benchmark str2 and str3 will be references to the single object.

Very simple string concatenation test shows 7723.032351 (C++) vs 1746.5784528109434 (Java).

I've just replaced strcmp -> strcpy + strcat; compareTo -> new StringBuffer().append() in Sam's test.

Java is fast enough for most stuff, too slow for other stuff. Everyone must decide for themselves what fast enough is through testing that makes sense in the applicable domains.

For instance, I've been working with low-level graphics engines and emulated some of the stuff on Java. Because Java doesn't have unsigned integral types, extranous bit-tricks slow down the process with at least 40% compared to a C implementation.

Other problems I've seen is abrubt and lengthy GC'ing. Also, string handling is horribly slow, and StringBuffer only helps that much. The worst problem is actually library design. Swing, EJB, etc are academic beasts that can leave even excellent programmers in dispair.

That said, I find Java to be fast enough for most business tasks, given that you think about design and apply proper algorithms.

For instance, I've been working with low-level graphics engines and emulated some of the stuff on Java. Because Java doesn't have unsigned integral types, extranous bit-tricks slow down the process with at least 40% compared to a C implementation.Other problems I've seen is abrubt and lengthy GC'ing.

Seems there is quite a bit of work out there for graphic-specific java api that work at very a very low level. Some of them are gaming apis but graphics is graphics.

They also go into GC issues. There are many ways to set up and tweak the GC so that you have more control over how often and when it is run.

You may want to check out their work.

Not that java should be used for everything but there are strong arguments as to why it would make a good cross-plaftorm gaming language if certain issues were worked out.

While on micro string benchmarks, has anyone compared java strings to .Net strings? The naive Java implementation uses two objects per string, one for the class and one for the array of chars. .Net does some magic and combines the two into one object. I would guess therefor it is twice as fast in allocating/freeing strings, which is generally the most important test.

(Micro benchmarks are limited, biased etc. but still give food for thought.)

(I would not want Java to follow .Net with a one off hack for strings. But a way to bind a class with a single array as one object would have a number of uses. However, a one off hack is better than nothing.)

There is a VERY good reason a Java String is an immutable object containing an offset int, length int and a char array object, it is MUCH faster and more memory efficient to copy a char array reference and use a different offset and length for sub-strings, than to allocate and copy chars into a fresh char array, especially for large sub-strings. This simple technique is not naive, but very smart and makes Java string handling very fast, possibly faster tban the .Net kludge you laughably call 'magic'. The char array object is often shared by several strings, so there is often minimal extra extra garbage collection cost.