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

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

Re:Faster?

[X]

Some things you got wrong:

1. All Java data that is not a local primitive variable must be dynamically allocated.
2. Dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks.
3. Most dynamic "objects" end up consuming about 1000 bytes.

1. I presume by this you actually mean stack allocated, as opposed to dynamically allocated (it's certainly possible to define statically allocated objects). While on one hand objects are meant to appear to be allocated on the heap, IBM has done a great deal of research on using linear analysis to allocate linear objects onto the stack. Works great.
2. Allocations in the HotSpot VM can take only a few instructions, much like stack allocation. Unlike C++ you don't have a heap that you are constantly trying to keep balanced and unfragmented.
3. Objects in Java are quite small. Indeed they have to be smaller than the 1K that you claim they need. Try allocating a million objects in a system with less than 1GB of memory. You'll find it works just fine. Again, with a compacting garbage collector, you don't have to worry about all the overhead associated with heap management which causes objects to be bigger than they need to be.

It seems to me your programming prejudices are tied to experiences with C++. If you learn the Java paradigm better, you'll discover that a lot of the performance trade-offs you learned in the C++ world don't play out the same way in the Java world.

Re:Faster?

[mj6798]

However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away.

What you are complaining about there is that a particular coding style you are used to from C++ doesn't carry over to Java. However, there are reasonable, alternative ways of expressing the same kind of code in Java. They aren't ideal (and Java isn't perfect), but they are workable.

(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.)

That may be a good rule for C++ (whose storage allocators generally have high overhead), but in a language like Java, a good implementation should have about one word of overhead for a large object and no overhead for small objects, and it should take about as much time as one store on average per word of storage allocated. The current JDK is a bit worse, but it still seems to beat most C++ allocators.

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

Four 32-bit integer registers?

[idiot900]

Looking at the description of the VM, I see only 4 general-purpose 32-bit integer registers - which seems like a rather shortsighted limitation to me. Seems like this VM is designed to be easily dynamically-translatable to x86 code - but there are plenty of other (better designed) architectures with more registers that IVM could target...seems like a waste to me.

This is a neat idea - but isn't this essentially a clone of what Amiga's been doing with their universal VM?

Re:Four 32-bit integer registers?

[b0rken]

That's right -- the "internet virtual machine" seems designed to map well onto a single CPU, the x86.

The standard library seems designed to map well onto a single OS, Unix.

You can run it on your big fancy RISC machine (well, if they've gotten around to writing a stable back-end), but it'll still approximate the performance of a register-emasculated ia32 processor.

It's a bit more portable than an Linux ELF binary, but not much. And about as revolutionary, given that a Linux runtime also exists on the modern BSDs (for example)

Re:Four 32-bit integer registers?

[Russ Steffen]

Why even bother with registers at all? Hardware CPU's use registers as because they are bits of faster memory, but that isn't necessary in a pure virtual machine. Unless you're trying to model a real CPU, why screw up the acrchitecture with unnecessary registers. Just have it do everything on the stack. In an all software VM, regsiters buy you nothing but unneeded compiler complexity.

C++ vs. Java all over again.

[under_score]

Okay - this is a "religious" issue. Building and promoting for C++ works up to a point. But the fact is that C++ and Java are both industrial strength languages (especially if you consider their libraries and tool support). It seems that the IVM does C++ "natively" but requires an extra step for Java etc. Why? Can't it just figure it out from the context? The file extension? The syntax? This IVM seems to be a pretty cool idea. Not new, but cool (IBM's UVM). I like the fact that they bothered with Objective-C (although that might just be because I believe the GNU GCC supports it).

Cross platform?

[bay43270]

I know Java isn't very popular here, but I have to say this... (I guess I wasn't going to be able to spend the karma on Christmas presents anyway) I think this is a bit insulting to the people at Sun to say IVM is cross platform. Cross platform means a lot more than just being able to run on more than one OS. Think about internationalization support. Does the ability to swap out text in the GUI constitute internationalization? No. Currency, calendars, colors and many other issues make up internationalization. The same principal applies to cross platform support. Sun spent a lot of work grappling with issues such as how to provide the programmer with an operating system independent environment. They deal with memory management, threads and display capabilities in ways that work consistently from a kiosk to a cluster of Alphas. They spent a lot of time dealing with j2ee, making sure the application server environment was swappable. They spent a lot of time working on platform independence in general, and I think its insulting to Sun to say that slapping a virtual machine under a compiled language is any more than a small part of the platform independence offered by Java.

It Will Never See Widespread Acceptance

[istartedi]

It Will Never See Widespread Acceptance. Why? It's GPL'd. So, until Linux conquers the desktop, or Netscape recaptures the browser market it's irrelevant.

PNG and JPEG are in IE because of the license. If they were GPL, all the MS browsers would be supporting GIF and some other alternative for lossy.

I didn't download IVM, but I decided to take a look at the instruction set. I gave up because it was taking too long to download! It looks like it has thousands of instructions. The JVM has less than 256. Something tells me IVM won't be targeting the embedded market. :)

Don't get me wrong. There is a market for embedded C or C++ virtual machines. I know because I'm working on one for my own use, and other parties have expressed interest to me. But I don't expect to bring in big bucks with it. MS CLR will probably win on Windows, and the JVM will win every place else. The smart money is on tools and languages that target the installed base. Sound familiar?

Wish it luck, but...

[arQon]

There's a lot to be said of platform-neutral environments. Typically tho, what's said is: "It doesn't f**king work". C++ is standard only as long as you're willing to stay with the language as it was 5 years ago, since we're constantly forced to use (eg) SunCC 4 or MSVC 6 or some other hopelessly broken compiler because of broken legacy code that NEEDS it; and Java has never been anything other than "write once, debug everywhere".
Being language-neutral on top of that is also a great thing for a VM, although it's no shock that the VM is going to be biased towards one language over the others. But let's face it: anyone using Java doesn't need hard-realtime performance anyway, otherwise they wouldn't be using Java in the first place. Same as if they were VB devs. So it makes sense that the bias would be towards C++.
The IVM runs DAMN fast, supports a truly open, pretty well-designed, widely-available graphics library: it's got a lot going for it.
But it'll have to bully its way past Java to get wide acceptance even if it's 10x better; and to truly become a standard it ironically needs to be adopted by, yes, THEM. The people whose browser has 80+% of the market. Of course, since it's GPL'd that's hosed it right there.
Then there are the same security issues that you see with every inet VM: how sure can I be as a user that some site's little applet didn't just funnel a ton of info back to them, that it won't do nasty things to me, etc. THOSE are the sorts of things that always bother me about "active" content: take a look sometime at how trivial it is to totally ruin someone's machine with an ActiveX control.
As an "Internet VM", I have as much use for this as I do for ANY objects-on-Web-pages "solution", which is to say, damn close to none. I have ONE site that I'm willing to run Java from: ESPN for it's baseball applet. Every "enabling" technology that people use for this stuff tends to end up meaning "enabling inept web designers to create gimmicky pages that don't work", especially when they end up using scripting and crapplets to mimic the most *basic* HTML functionality like hyperlinks. (No, I'm not joking. I've seen it happen).
OTOH, for an *intra*net I would definitely consider something like this, and I'd prefer it over Java any day of the week. And for little noddy apps, being able to use my language of choice and still have portability AND much better performance, well, that sounds pretty good to me too.
So I think it's a useful bit of tech: just that it'll never go anywhere in the role they're pushing for it. That's not necessarily a bad thing though. :)

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.

Like small children...

[macpeep]

Sometimes, I cannot believe the silly fights I see here on Slashdot. I'm a software engineer myself and I use both Java and C++, but for different purposes.

At work, we write cross platform C++ code for a large number of platforms in a pretty large scale project. This is amazingly straight forward given a strict set of rules that everyone has to follow, but it also requires that you constantly test on all these platforms. The actual product that we are working on, is C++, like I said, and it would never even occur to us to write it in Java. Even if Java would be 80% as fast as C/C++, we wouldn't use it, because we want all the speed we can get. (yes, some of our inner loops are optimized in assembler - separately for every CPU that we support)

However.. In order to be able to compile and test on all platforms, we needed a tool so that every engineer could just press a button and have the code compile and test on platform X. To enable this, we built a tool in Java, that checks out code from CVS, compiles it, and sends logs to a server where you can view the build logs with a web interface. From the same server, you can also initiate the compilation remotely on any one of the client machines (one per target platform) that are running the tool. This whole system is coded in Java, and just like would never occur to us to code the actual product in C++, it would never occur to us to code this tool in anything other than Java.

It seems like everyone here is trying to prove that one particular language is best for all tasks. Guess what - that's not true. I see C zealots try to prove how slow Java is. Well, it's actually way faster than many believe. I see silly proofs that try to show that Java is slow by using benchmark apps that do string manipulation with String objects. If you write your own strcat, strcmp, strstr etc. in Java and use byte arrays, you'll find that string manipulation is about 70-85% as fast as in plain C - and that's fast enough for just about any purpose you can think of. Of course your productivity advantage is now gone.

Just use whatever you feel comfortable with and whatever works for the application that you need to write. In most cases, you'll find that Java will be very nice forit. In other cases - like graphics and game programming, C++ - used wisely - is your best choice. Some dislike OOP and want to use C instead... Whatever gets the job done for you! I don't see why everyone has to prove that Java is "damn slow" all the time. Obviously, it's fast enough, as evident by the fact that a few millions programmers use it every day for real life tasks.