Slashdot Mirror

The JVM spec is open:

"Open" means that you can implement the spec as you like, and the JVM spec is not open (and neither are the language or the libraries): read the license linked to at the bottom of the spec that you yourself point to. Also read Stallman's take on this if you don't believe me.

Yes, I agree, they don't have a big "ECMA" or "ISO" badge, but well... since when were those worth a penny.

They guarantee that Microsoft can't play the kinds of legal games that Sun has been playing with the Java specification.

C++ has been ISO certified for years or decades,

Yes, and that has achieved exactly what it should: creating a choice of a large variety of compilers from many different vendors.

OK... let's say this: I like Javas design, you like C# design; it's futile to discuss taste issues, so I won't.

That's like saying that the difference betwee a dump truck and a school bus is a question of "taste". In fact, it's a difference in functionality, and a well-understood one at that. See here for a more extensive technical discussion of what Java is lacking if you don't believe me (the people there seem to have pretty much given up on Sun and Java, too).

Value classes, unsafe modules, pointer arithmetic, call-by-reference, templates (implemented differently from Java), multidimensional arrays, operator overloading, to name some.

Javagrande.org

He complains about the Java compilers complete lack of optimisation flags (duh... making optimisations to platform independant byte code is pretty useless, and generally counter productive... it's all done by the JRE, which actually has a number of flags for tweaking things, and there are many JRE's to choose from). He talks about how the JIT doesn't perform processor specific optimisations (it does in fact perform many processor specific optimisations, unfortunately his benchmark is written in such a way that none of them will get used). He talks about there being no interest in high-performance Java (the Java Grande group would beg to differ). Best of all, he keeps calling Java an interpretted language... even though he used gcj as part of his own benchmarks... Sigh.

Worst of all he uses gcj without trying out TowerJ, which is a much more established Java-binary compiler. Sigh.

Yes, but with people, you have some expectation that there are some that you can trust. With companies, there is no basis ever to have such an expectation.

Were such promises ever made? Not doubting you, but I do not remember them being made.

In 1996, when people like myself were deciding whether to get our companies to support Java big time, yes. Sun definitely told people that they wanted Java to become an open standard, that they wanted to encourage multiple implementations, that they wanted to open source it (but perhaps not under the GPL/LGPL), etc. None of that has really happened.

Can you provide URLs about these things? I am not familiar with them.

Look around JavaGrande.org, and also take a look at pointers to Java Grande from Sun's site (via Google). Gosling and others were talking about these kinds of features even before the founding of Java Grande in 1998. The only thing that has gotten addressed is some floating point issues.

In any case, the overall point remains: C# delivers all the major points that Sun has promised but not delivered: standardization, full open source implementations (no thanks to Microsoft, however), and decent support for numerical programs (operators, subscripting, iteration, value classes). Furthermore, we know that the core of C#/CLR is not covered by Microsoft patents, while the core of Java/JVM is covered by some Sun patents. I think if openness and features are primary issues, the choice is clear.

I still use Java instead of C# for now, but only because we have a lot of Java legacy code and because the Mono implementation isn't quite up to snuff. In a year or so, I see nothing keeping me with Java.

There are quite a few people working on polishing up Java for numerical work.

A couple of links would be IBM's NINJA, the Java Numerics page and Java Grande.

There are papers (albiet old) on the IBM site which show they were able to come within 10% of FORTRAN performance using Java code and a massaged JVM.

IBM's matrix routines (downloadable somewhere) are friggin' fast.

The runtime optimisation also lets you tweak and prune to a greater extent than C/C++ code, although FORTRAN still rules in the code optimisation department. I believe this is because it's a simpler language (and most papers I've read come to this conclusion... C/C++ lose because the compiler can't be as brutal in its optimisation).

For a while there were large advances in C/C++ compilers, but I don't see as much of that any more... not that it would be on my radar necessarily, because I haven't kept up on the reading.

Anyway... Java... eventually. I think it'll get there. Of course I meet with huge resistance from the FORTRAN purists whenever I say that, but that's life. Whatever works for you, I guess. I'd rather write stuff in Java that FORTRAN; FORTRAN drives me up the wall.

That being said, I do most of my stuff in MATLAB these days. That program rocks.

MJC

I vote for high-performance Java, personally (with further extensions for better performance like lightweight objects [no inheritance but very little overhead for things like complex numbers], immortal [static] objects and a good generics implementation). I'd also like to see a very flexible and extensible operator overloading functionality, as well as the ability to use Unicode in Java source as an optional extension, for both variables and operators.

Also don't forget that gcc 3.x now includes a Java front end...perfect for extending into numerical Java. It's especially appropriate since it is a traditional "ahead of time" compiler permitting full optimization.

IBM has already provided matrix libraries written in Java with about 80% of the performance of fully optimized FORTRAN. Another interesting library is the Colt Library. It is also possible, using JNI and DirectIO, to use legacy libraries efficiently from Java where appropriate.

The focal point for numerical Java is Java Grande.

BTW, I was sorry to miss the Java 3 discussion yesterday, but this post summarizes my desires in that area. Quite a bit different from those of the article's author (what a whiner that guy was!).

At any rate, FORTRAN is still alive and kicking, and will be for another hundred years I'm sure... ;-)

I hope new development is mostly being done in Java in the not too distant future, though!

Certainly that is one thing that ahead-of-time compilation achieves, however it is not the only thing. Those "small" executables can of course link with traditional shared libraries (dlls) which would encompass the standard Java libraries plus (potentially) any third party libraries.

In order to achieve that, they sacrifice many of the properties that make Java interesting in the first place.

I don't agree. As I pointed out, gcj supports dynamic class loading in those few cases where it is needed.

If you take a single-process, dynamic-compilation approach, Java really shines: you can combine lots of software components at runtime, and the dynamic compiler will optimize and inline everything at runtime.

I understand that better inlining is one of the benefits of dynamic compilation. However, the just-in-time compiler (JITC) cannot perform extensive optimizations. You are paying a cost in computer time to do both the analysis and compilation every time you run the program. By the way, there is no reason you couldn't write a traditional compiler to accept profiling information and do better optimization based on those.

That's not theoretical, it really works. If you keep a single Java process running (rather than starting things up again and again), javac, jedit, and other substantial Java programs are lightning fast.

If you look at my posting history, you'll see that I've made the point that modern VMs are approaching the speeds necessary for high-performance computing. ;-)

However, wouldn't it be nice if those programs a) loaded lightning fast and b) ran fast even the first time they're used? It's rather annoying to hit an intensive operation for the first time, have it take a minute, then have it run in five seconds the next time. Don't you agree? (BTW, this could be accomplished by "freezing" the program onto disk when it is closed, then "unfreezing" it back into the VM when loaded, preserving the compiled sections. The VM would discard the frozen copy when it detected a .class/.jar file version change.)

I agree that gcj is very worthwhile, and I hope its development will continue. Many people (myself included) still want to write small, stand-alone applications some of the time, and being able to use Java is nice for that.

I think gcj has many other potential uses. First, it is a great approach (given a robust compiler;) for the large applications which are of interest to the Java Grande Forum, or any others that require the absolute best performance (I know this will have to be examined carefully by benchmarks once gcj is far enough along - my guess is that gcj will win, especially given the ability to ignore array bounds checking in tested code. Also with gcj you can deterministically lock out the garbage collector if desired.) If the JDK 1.4 VM doesn't give Java enough performance to be competitive on things like 3D games and flight sims, gcj will have its chance. Finally, gcj should do well in very small embedded environments where an interpreter/VM just doesn't make sense.

Gcj's easy connection with C++ also is a great link to existing codebases.

You're referring to CNI, which is also a very efficient way to link to C/C++. This is also a major strength of gcj.

Nevertheless, for developing a modern desktop, I think the dynamic compilation approach is a much better way to go than ahead-of-time compilation.

It wasn't clear that your comments about gcj were strictly in reference to "developing a modern desktop". In that context, I'd tend to agree with you. However, for monolithic applications (games, productivity tools, compute servers, compilers etc.) there's a lot to be said for traditional compilation.

Its also nice that gcj is open source, and can be forked for new, experimental languages. I'd like to see that done to provide a good operator overloading facility (using different than normal Unicode symbols so that overloading can be identified easily), lightweight types and generics. Some of that can be accomplished using preprocessors with Java, but direct compiler support would be better. :-)

Thanks for the interesting discussion, and sorry it took so long to respond...

299,792,458 m/s...not just a good idea, its the law!

The fact is, Java is NEVER used in serious numerical compution.

It is still a young language, but its use seems to be growing all the time. The Java Grande Forum is an active and vocal group of scientists and numeric programmers who certainly seem to think Java has tremendous potential in those areas. A quote from the site:

Java has potential to be a better environment for Grande application development than any previous languages such as Fortran and C++.

2) Most scientists are not fancy programers and don't care too much about OO, garbage collection, and other frills.

Most scientists who do a lot of programming (in my experience, and I work with several PhD physicists) are extremely interested in new techniques and technologies that'll make them more productive and result in robust, predictable programs. Java does a good job in both areas, and performance is very good with modern VMs.

In short, as far as I can tell, you are clueless. :-)

186,282 mi/s...not just a good idea, its the law!

Java *is* used for numerical computing and the like:
Java Grande, Java Numerics

• SPEC JBB2000
• Volano
• Java Grande Forum - not a benchmark, but these folks work on improving Java for high-performance computing

There is Java Grande. These guys are working on making Java more suitable for number crunching and similar jobs. They've contributed to StrictMath and suggested the strictfp modifier (IIRC)... If they thought number crunching couldn't be done fast enough, they'd never started the project. It seems like the interpretation / just-in-time compilation part of Java doesn't have too much of an influence on performance with these kinds of applications.