Slashdot Mirror

Still in time : ADW Modula2 ( Stony Brook Modula2 ) is now freeware in Win32 and Win64 versions
http://www.modula2.org/adwm2/

Also freeware are the XDS Modula2/Oberon2 compiler, including their optional C generator backend
http://www.excelsior-usa.com/x...

Finally you can find in sourceforge for OberonF/ComponentPascal and XDS sourcecode
http://oberonrevival.sourcefor...

Fair points, but I still think it was an awful decision to release Android using an interpreter for its recommended software stack.

I'm not suggesting just taking HotSpot and dumping it on a phone, and you're right that the JVM has its drawbacks, but they could have, say, adopted a system comparable to Mac's "universal binaries": apps ship with both Dalvik bytecode, and an ahead-of-time-compiled ARM-specific binary. In the future, when Android has a decent JIT compiler and may or may not still be running primarily on ARM, the shipped ARM binary could be ignored, and the Dalvik code used instead.

Or run an ahead-of-time compiler at app-installation time. Platform independence is preserved, performance will be good, but you'll have a lengthier installation process. C# does this I believe, and of course Unix has been shipping programs in source form forever.

Neither of my suggestions require starting from scratch with the compiler, as they don't depend on the Dalvik IR. Java->native code compilation can be done; Google could easily kick GCJ back into life, or something similar using LLVM.

You'll probably get furious then if you'd see this or this. Those bastards are even worse than Google - they compile our pretty and portable .jars to completely non-crossplatform machine code! How dare they.

Java programming language != Java platform. There's no "contract" that any jar will run on any platform using Java programming language - go try running Java EE application on a Java-enabled phone or Bluray's BD-J applet on your PC.

And yes, MS was bitchslapped because they claimed to implement standard, compatible Java SE implementation while introducing incompatiblities. Google claims to implement NOT any of Snoracle's Java platforms, but a new runtime using Java programming language.

You can now proceed to remove your foot from your mouth.

Converting a jar to an exe is difficult. I wish I could do it reliably on Linux, but I can't (gcj doesn't really work)

If you really-really need it, and need it so badly you can give away the distaste for commercial software, see here

To start, fully type safe.

I presume this is a dig at Java generics? But they are type safe unless explicit casts are used. And when casts are there, all bets are off - after all, Ada also allows you to explicitly do non-type-safe (and non-memory-safe!) pointer casts.

Though I'll give you that, in Ada, it is very distinct from normal, safe casts.

Generics are implemented as an integral part of the language, not as a bolt on that creates lots of issues.

I agree that Java generics are quite a mess, but they still have some nice features. E.g. I don't recall seeing wildcards and "super"-bounds in Ada, and those can be very handy to express certain things in a typesafe way.

It is a native binary, not byte code.

It's not clear whether this is an advantage in this case (or in general). In practice, JVMs heavily rely on JIT compilation, and you could even make one which would compile everything on class load, making it essentially the same as a native compiler except for loading times (and even that can be improved with caching). You can do full AOT compilation even, though that goes beyond the boundaries of what JVM specs cover.

On the other hand, you can, of course, compile Ada to bytecode (though not specifically to JVM bytecode, which isn't expressive enough). E.g. there was a port of Ada to .NET.

All arrays are checked for overflow during run-time - no buffer overflows.

This is true of Java as well, of course. And any other memory-safe language.

Let's write some nVidia drivers in Java!

They'd probably run faster or better. I can't count the number of engines that have trouble with nVidia multi-threaded rendering. (Source, for example) Java would chug memory, but at least it's reliable.

You'd probably need to static compile it, though.

http://www.excelsior-usa.com/jetinternals.html

WHY THE FUCK CANT YOU COMPILE JAVA INTO AN EXE?

Probably because you haven't installed the compiler. Google for "Java native code compiler" or try Excelsior JET.

You're assuming, for no good reason, that Java applications run in a VM. I disagree with your benchmark anyway - one glaring flaw is that you timed the whole application load and execution instead of the actual loop, and you're deliberately using the extremely rare case of unrollable floating point loop indicies to discriminate between static and dynamic compliation. But in any case it's perfectly possible for Java to exceed the speed of C++ virtually all the time by using a native complier such as the excellent Excelsior JET).

...and it is not a native programming language...

Actually there are native compilers available for Java: Gcj, J2exe,
Excelsior JET and Manta.

There are downsides to using native compilers though, including a) the need to maintain separate platform versions of your app, and b) the loss of the ability to decompile back to Java source. But some developers don't mind a), and the more proprietary ones positively love b). :)

Kaffe, on the other hand, isn't a native compiler in the sense that the compilers above actually cough up an executable for you at the command line. But it has a just-in-time (JIT) compilation system which translates the bytecode to native machine code on a method-by-method basis as the application is executed. This really boosts Java app performance a lot.

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

The original article generated an exceptional collection of interesting and helpful of responses. In this section, I'll run down the important points people made.

Note: This is a duplicate of a new section I added to the review; I'm posting it here for posterity.

An overwhelming number of people suggested that I include results for IBM JDKs -- and I have. In fact, I've added results for Sun JDK 1.3.1_06, IBM JDK 1.4.0, and IBM 1.3.1 RC3. Adding these JVMs made a significant difference in the results, cutting runtimes in half. On the other hand, almabench runs as an infinite loop with Sun's 1.3.1 JVM (it starts, but never finishes). Note that I recompiled almabench with the corresponding javac for each JDK, so the JVMs were executing code generated by their corresponding compiler.

The problem with Java's performance is not my code or my lack of Java skills -- what real problem is that Java 1.4 is slow. Both the Sun and IBM JVMs lost significant performance in the move from 1.3.1 to 1.4, whether due to a new language requirement or other factors. My faith in Java is severely shaken when applications lose significant performance by upgrading to the current release of Java.

Java 1.4 added many new features to the language and packages; however, changing from version 1.3 to 1.4 should not double run-times! Nor am I comforted by the problems of Sun's 1.3.1 server JVM.

Given the nature of the problem, my conclusions about Java stand (albeit slightly softened). By Sun's own definition, JDK 1.3.1 is obsolete; the fact that it performs better than the most current JDK is indicative of a serious problem with Sun's improvements to their language. Since Java 1.4.1 is what Sun is promoting, so that is what I base my conclusion on. I can say that IBM's product is superior, and have already set it is my default JDK. It's no wonder Sun is upset about IBM usurping Java -- IBM is producing better tools.

Some people asked if my Java results were biased by the amount of time it takes to load the JVM. I've tested several empty and near-empty applications; a Hello, world program, for example loads and runs in less than 2/10ths of a second -- hardly significant. The start-up time increases with the number of imports -- but almabench.java imports only one small class package, java.math.*, which (in my tests) does not impose measurable overhead.

I did not include any commercial Java compilers. Most, like the oft-cited Excelsior JET, are Windows-only; this article is about Linux. I don't benchmark Visual C++ or C# for the same reason (although I will look at Mono and C# some time in the future). The free version of Borland C++ does not include a complete optimizer, so I don't think it fits in this review.

How do I know that the programs are producing the correct output? Each program includes code to display results; I run the programs with I/O to ensure that all calculations are being performed, then I comment out any header inclusions, imports, and print statements for actual testing.

How am I timing the results? With the Linux time command. Table 3 reports the real value reported by time (the elapsed time of execution.) Embedding timers in the actual code is fraught with problems; for example, each language implements different time scales and abilities. I'm sure someone will tell me that time is full of problems too, but it works for me and is consistent across all programming languages.

Amid the barrage of Java-related comments, a few people actually noticed the Fortran code. I am looking at other Fortran compilers for future updates. As for GNU g77 -- I wrote the code in Fortran 95 because I find Fortran 77 to be annoying. I wrote piles of Fortran 77 back in my CDC and VAX days, but these days I'm writing for environments where Fortran 95 is more appropriate. Believe it or not, Fortran 95 is a very clean, orderly language that eliminates many Fortran 77 idiosyncrasies while adding features important for high-performance coding.

.NET platforms will win over from java because .NET compilers to .EXE and .DLL files which look and seem to work just like the ones you are used to.

I'm sorry, but this is a load of bull. Download and run the windows version of this application and tell me how you would figure out (unless you're a Java developer) that the application is in Java. And no, it's not even compiled to native windows code (something you can easily do with Excelsior's JET compiler) OR requires you to install or configure anything except the application.

Another thing you are missing is that client side is not everything, and in fact, Java is currently more popular on the server side, where it doesn't matter whether you run "java HelloWorld", or "HelloWorld.exe" (actually, it'd be more like "./helloworld" on most servers :-) )

Where was SWT in this discussion for instance?

See also the full list of third party apps, libs and APIs we've tested JET with - there are JET project files you may download.

To address this problem, a native compiler's runtime can include a JVM (like in TowerJ) or a JIT compiler (like in Excelsior JET). JET in fact has a Caching JIT - the DLL created from a dynamically loaded class shall be re-used when exactly the same class is loaded again. Somebody mentioned here that Java on AS/400 has a similar feature.

Osvaldo Pinali Doederlein.
The Java Performance Report - Part IV: Static Compilers, and More. August, 2001

The Java Performance Report is an independent study of Java performance, where both virtual machines and static compilers are evaluated. Part IV compares Excelsior JET and two other static compilers with Sun's HotSpot Server VM.

Volano, LLC.
The Volano Report. Dec 26, 2001

The Volano Report covers VolanoMark(tm) - a widely recognized pure Java server benchmark characterized by long-lasting network connections and high thread counts. This report includes Excelsior JET a native compiler.

Excelsior JET Benchmarks

From Caffeine and SPECJVM through XML Transformations to Java2Demo and VolanoMark.

Download here

Our Excelsior JET and Instantiation's JOVE are two native compilers that support whole program optimization, though in JOVE it is the only compilation mode available. Execution profile may as well be used by an AOT (ahead-of-time) compiler, though I am not aware of the availability of such implementations.

Excelsior JET implements all Java checking. Some chekcs may be turned off, but they are on by default. The benchmarks which results are published on our Web site were compiled with all checks enabled. You may download the respective build/run scripts and an evaluation copy of JET and compare on your system.

There are native compilers that only support so called close-world programs (i.e. all classes are known at compile-time) - JOVE is an example.

There are indeed native compilers that included a JVM in runtime for interpretation of classes not known at compile time (RMI Distributed Class Model and Dynamic Proxy API are two common sources of such classes) - TowerJ is an example.

There is however one native compiler that addresses this problem through providing a caching JIT compiler that produces native code DLLs. The DLLs may be cached, so if next time the app loads the same class, the respective DLL shall be loaded from the cache. Of course there are consistency checks.

The compiler is called Excelsior JET

Besides, the Personal Edition is free, though it does not have that Caching JIT stuff.

Excelsior JET, Professional Edition is a native compiler that fully supports AWT/Swing, reflection, dynamic class loading, etc.

Want proof? Download their fully functional evaluation package.