Fast, Open Alternative to Java

DrInequality writes: "For those of you out there who admire the portability of Java but want something faster or open source, the answer to your prayers is finally here. The Internet Virtual Machine is open source, fast and supports C, C++, Java and ObjectiveC. There are some cool demos for Linux (requires Redhat 6.0 or above, and OpenGL 1.2 or Mesa 3.41) here (1.5MB) and for Windows (requires glut32.dll, here) here (1.5MB)." We mentioned this last year; perhaps it has improved. I'm sure a lot of people would be interested in a language as portable as Java but speedier.

Comments

It crashes on RedHat Linux 7.1

[BlowCat]

I downloaded the binary and it crashed on RedHat Linux 7.1 with all updates and kernel 2.4.9-ac10. It looks like that it's the library loader that crashes, because even ldd icvm dumps the core.

Sorry, I have no time to download 23M of compressed sources to compile it. But if it crashes for you, you probably have to.

Faster?

[silicon_synapse]

Java is already comparable to C/C++ in speed. It has made a lot of improvements over time. I think the key to better speed now lies more in better code than in a better virtual machine. I can't see this gaining a significant acceptance. It'll probably do it's job well, but there needs to be some pretty compelling reason to move away from java.

Re:Faster?

[Waffle Iron]

Java is already comparable to C/C++ in speed.

Well, the actual situation depends very much on the abstraction level of the program being implemented.

JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.

As an example, one concept that is on the border between mid-level and high-level abstraction is strings:

If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.

(Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't.

The upshot: it all depends.

Re:Faster?

[MarkusQ]

...if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster...

There is a general principle at work here: you can quite often go one or two orders of magnitude faster if you are willing to give up safety. It applies to everything from sex to ice hockey, and (viewed at the right level of abstraction) the results are always pretty much the same.

-- MarkusQ

DotGNU

[bstadil]

The DOTGNU guys has already looked at it. From Carsten Kuckuk via the MAilinglist

Quote

I printed out the spec last night and read it on the commuter train back
home. The IVM team essentially created a specification for a Motorola 68000
like 32 bit processor, assigned 16 bit opcodes to instructions and
implemented an interpreter for it as well as an adoption of the gcc
compiler.

Advantages:
+ Portable
+ It works
+ Very fast

Disadvantages:
- No separation of data and code
- Interface to the underlying operating system is POSIX
- No built-in security, not even a sandbox

My assessment:
o Good piece of Engineering: It's there, it works, it solves a problem, it's
GPLed, it's tested.
o In order to be used as one of the VMs for DotGnu, security needs to be
added. As one of the rules in secure programming is that you can never add
security to a system, but that it needs to be designed into it, I don't know
if that is possible.
o For my personal taste it's too close to real untyped assembly language.

Carsten Kuckuk

Unquote

Java *is* open source

[magic]

The original post was misleading.

Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library. IBM's Jikes is one of the best Java compilers available (it is more reliable and faster than javac), and is available with full source.

Open source doesn't just mean the GPL! The GPL trouble more often than not because most companies won't get within miles of it for fear of legally contaminating their sources. The important thing is getting provided source code to be seen as a standard, not a wierd alternative. With Java, the source is provided and is really useful.

I wouldn't put Java and C# in the same boat as far as "proprietary". You can't fork the Java code base directly, but Sun is really responsive to the community. Most new libraries are incorporated from user built packages, and all new features go through a community review. The bug database is open to the public. Sun provides open source repositories like jxta.org to help the community. Sun is the good guy... C# is Java Microsoftified and is evil (although a decent language) because it won't have this kind of community interaction and open source.

-m

Re:Faster -- with evidence

[Leeji]

Okay.. Here's a few things. First, about the original statement, "Java is almost as fast as C." I agree, with evidence.

In terms of raw computation, let's dump some equivalent C and Java. I tested these on my schools large Solaris box.

int main(void)
{
float x = 0;
int counter;

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

printf("%f\n", x);

return 0;
}

[11:29pm || 24](~)> date && compute && date
Fri Sep 14 23:29:06 EDT 2001
15969064845312.000000
Fri Sep 14 23:29:11 EDT 2001
(5 seconds)

public class Compute
{
public static void main(String args[])
{
float x = 0;
int counter = 0;

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

System.out.println("" + x);
}
}

[11:29pm || 26](~)> date && java Compute && date
Fri Sep 14 23:29:53 EDT 2001
1.59690648E13
Fri Sep 14 23:30:02 EDT 2001
(9 seconds)

I did this a few times, and the general trend continues.

What also kills Java performance is lazy programming. People tend to use vectors (high-maintenance linked lists) when native arrays will do. Or they'll store a load of information in a Vector, then repeatedly search through it (in O(n) time). If they had any mind for performance, they'd use a native O(logn) data-structure like a Treeset. People use Treesets (a sorted, tree-like data structure) and then re-sort them. Or worse, if they can't find a sort() method for their specific object-type, they'll hack together a bubble or shell sort.

The only place that Java beats other languages is the API. Large enterprises have a Java fetish *not because it's portable*, but because their almighty productivity numbers go through the roof. Where a C++ programmer has to code (or buy) linked lists, b-trees, hashtables, sockets, etc, Java wraps it neatly into the language core.

Second, answers to your peeves :)
1) Typedef = class!
2) Constants only require "final int foo". The public keyword only makes your constant visible to other classes. You don't need this if you define the constant in the class you're using it. The static keyword simply lets you use the variable without having to instantiate the class. Again, you don't need this if you define the constant in the class you're using it.
3) You only have to use parseInt() to take an int from a string. I'd say the equivalent atoi(...) in C is just about the same!

Re:[insert scary music here]

[jilles]

It's just C compiled to bytecode. It doesn't have most of the features that made Java popular (e.g. security, dynamicity, reflectiveness because inherent design decisions in the way C programs work inhibit this). In other words it is no replacement.

Don't understand me wrong, maybe integrating such a thing with e.g. the gnu compiler would be useful. It would be great to create a single set of binaries and distribute them to the hubndreds of unix versions and other operating systems. But it has to be clear that this thing is orthogonal to java rather than the same.

In any case, I'm not impressed and even bored. Java is a relatively simple language. Most of the language concepts are easy to grasp, even for novice programmers. Yet people keep comparing it to more primitive languages such as C and suggesting alternatives which are basically C++ improved rather than Java improved. After years of being confronted with a rapidly growing java community, even some C++ programmers begin to appreciate things like garbage collection (after having dismissed it for years based on performance concerns). However, beyond garbage collection they are still largely missing the point (i.e. C is not so cool after all).

What I would like to see from the open source community (perhaps as a proof of concept) is a more ambitious effort, not just a (partial) duplication of features inspired by ignorance rather than innovation. Java has room for lots of improvement, lets set it as a baseline rather than a design goal. Duplicating all of Java's useful features should be a minimum requirement and not the ultimate design goal.

This post is rather harsh, I know. However, I think this is a fundamental problem with open source in general and linux in particular: it's mass production of commodity software components (kernels, compilers, IDEs, word processors), not creation of new ones. If cutting edge technology is your thing, the propietary world is still the source of it (speech recognition, cool 3d technology, AI related improvements to user interfaces, compiler technology, languages, ...). It is very rare to see an open source project that does not just duplicate features but instead introduces radically new features and paradigms. There are some research projects that use open source to distribute their stuff but these generally play only a marginal role in the open source community. The big open source projects are all about duplicating and imitating the bigger/better (in most cases) propietary counterparts.

In short I find the open source community boring & backwards. Its contributions are very useful and I use them on a daily basis. However, as a researcher I don't want to wait for thirty years to see things like OO being grudgingly accepted; I hate it when linux is advocated as a windows alternative when the people doing so largely fail to even realize why windows got popular in the first place. The same applies to Java and Visual Basic (yes, from the *evil empire* you understand me correctly). The features that made those things popular have yet to be duplicated. Effords like the one advocated in this article are just so backwards they only make me angry. Go do something useful! Don't waste your time figuring out how to reinvent the wheel, I already have half a dozen.

Re:Faster -- with evidence

[iapetus]

I'm afraid your code is pretty much useless for testing Java vs C++ performance. If you'd checked out the Sun FAQ on benchmarking Hotspot you'd have seen something like this:

I write a simple loop to time a simple operation and HotSpot looks even slower than Java 2 SDK. What am I doing wrong? Here's my program:

(Program almost identical to yours snipped, since it's setting off the lameness filters ;)

You are writing a microbenchmark.

Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement" and exists in the 1.3/1.4 HotSpot based systems.

Realism - Re:Faster -- with evidence

[RallyDriver]

Your test isn't very comparable, because you are also measuring the startup time of a compiled binary (crt0.o) against the startup time of the JVM and byte-compile. Unless of course part of your point is that Java isn't suitable for writing Unix-style command line data filters and other apps with a short life of only 5-10 secs CPU, which I agree, it isn't.

A better test would be to put the "date" commands into the code in both cases; perhaps I'll re-run them that way and post the results. Don't get me wrong, C will still win, the gap will just be a bit narrower.

Having said that, I wouldn't advocate Java (yet) for something compute intensive, you are right on in that respect; however, you must note this:

- very little software these days has CPU time as its limiting performance factor

- in terms of the total cost of doing computation, CPU performance is getting cheaper and cheaper (Moore's Law) while developer time is getting more and more expensive.

The cost in $$ to develop a straight line block of code of the compelxity of your loop body there is literally trillions of times the cost in $$ to execute it once, so unless it is in a place where it will be run trillions of times and performance matters, an easier to code language wins out over a faster one. There is a reason we aren't still all hand coding machine code in hex, and it's not a yes/no thing, it's a sliding scale moving effort form people to machines.

Assembly -> C -> C++ -> Java -> ???

We use pure Java for our server side web application. It runs with a servlet runner (Apache JServ) and we typically run a single VM ("java" command) for about 3-6 weeks, accumulating a couple of hundred hours CPU.

The thing I find most interesting in your test is the speed ratio - despite the disadvantage that you've given Java, it's less than 2:1 which is better than I suspect most people would expect. This is number cruching, it's not what Java does well, althoguh the gap has closed enough for it not to be a concern. I saw a paper about 18 months ago (can't remember the reference)

Nowadays, very few apps do enough computation to redline the CPU in any useful sense - the limiting factor is I/O.

The real advantage of Java is not so easy to benchmark, and that is indeed developer productivity; the app is not rocket science, but it has some very useful platform layer caching between itself and the database. There is no way we could have gotten as far as we did with this with so few people in this amount of time if we had to build it in C++ and worry about type issues and garbage collection.

This productivity advantage far outweighs the 25 to 50% performance penalty of using Java - the limiting factor in our app is not CPU, depending on the individual screen it's either I/O bandwidth to the browser or I/O speed to disk. Not much we can do about the former for end users (though we make sure customers using our admin tool get a cable modem / DSL) and our caching is making good strides at the latter. I have yet to ask a developer to recode an algorithm for **CPU efficiency**, though I do keep a close eye on database and filesystem I/O load, memory footprint (JVM heap), and HTML page weight.

Assuming we can deliver pages to browsers close to as fast as the users' connections can handle them, the efficiency of the overall system to our business is measured in $$$, and includes the cost of developer time (lots) and the cost of hardware (small) - throwing hardware at it here **is** the right solution.

For appservers, we use rackmount dual Pentium 3 pizza boxes, running two Sun 1.2.2 green threads JVM's on Linux; I picked up **twenty-two** of these, less than a year old, at the deja.com sell off in Feb 2001 for about 10 grand total. That won't even cover the fully loaded cost (salary, taxes, medical and Mountain Dew :) of one senior engineer for a month.

Bear in mind guys, I'm not a suit, I'm a techie - I have a Ph.D not an MBA, and my background curiously enough is in one of the few areas where the CPU performance **does** matter, doing compute intensive stuff, mostly FORTRAN and C and mostly on hardware made by Cray Research. This gives me the perspective to know when and where performance matters, and I chose Java with that in mind.

David Crooke
Chief Technology Officer
Convio