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

A fried of Mono?

[Whyte Wolf]

COuld this possibly be useful with Ximian's Mono project, or Gnu.NET? I could imagine using this as a VM for C# could seriously PO M$ :)

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?

[spiro_killglance]

Java is no where NEAR the speed of C, java makes everything High level and must be run through in an interpreter in order to run (which is most of the slow down).

But if the interpreter is a highly advanced on
the fly optimisating JVM like in Hotspot, you
may well find its optimising your code to a native
binary than you C compiler does. Have you tried
Java 2, v 1.4 beta 2 yet?, a lot of Java slowness
was not due to the JVM but due to badly designed
I/O and String classes. Additions to Java 1.4
add a Native Input/Output libraries for much
faster access, and move powerful access such as
mapping a Buffer to a region of a file.

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.

Re:Faster?

[mj6798]

I have experince in all three languages, Java is no where NEAR the speed of C

Sure it is, but it's harder than in C. Basically, in C, it's easy to write code that runs fast, but it's hard to write code that's correct and robust. In Java, it's easy to write code that's correct and robust, but it's hard to write code that runs fast. If you invest enough effort, you can write code that runs fast and is correct in either language. Which language makes the better tradeoff? 20 years ago, the choice was clearly C. On today's hardware, the choice is pretty clearly Java.

[Java] must be run through in an interpreter in order to run (which is most of the slow down)

Sun's JDK and IBM's runtime both are compiled implementations; they run Java at machine speeds, not interpreted.

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

What about C#?

[tshak]

What about C#? Many Java and anti-Java advocates have come to a common ground that C# is a great language. It's fully OO and very easy to code in. MS has submitted the spec to the ECMA, so isn't this possible?

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

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

Some quick thoughts. (No sound, GPLed)

[BrookHarty]

The demos are nice and small, very impressive. Ill need to try this on my linux box in a few moments. (Looks like from the /. posts is crashs on some redhat installs..)

No sound, but its still in beta, so things should be added. The most impressive thing, is IVM is GPLed! No pesky Sun or Microsoft License! Now give me a QNX, Ipaq and Gameboy Advance IVM and im set!

Re:I wonder...

[small_dick]

In the future, there will be middleware.

I don't know how else to put it. The laws, the technology...everything is going to middleware.

Java, C#, this product...a better question is : how will i find apps that don't run off the internet?

Answer: a computer museum. I'm totally serious.

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: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)

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?

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.

More programming languages than programs

[WildBeast]

It's crazy, at this rate we'll have more programming languages than programs, we'll have more OS's than we can think off, etc.. I don't know if you're getting it but at this rate, the value of software will sink. Supply is much bigger than demand, soon enough developpers will not afford to pay for food. Don't say I didn't warn you.

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

this is good but not great

[Anonymous Coward]

Having a VM to make C, C++, Obj-C (and Java) alll portable and still fast is great. Java does reduce the need for this and since the VM isn't portable to my platform of choice (OS X) this certainly isn't the answer for me at the moment. If it grows and moves to other platforms, tremendous.

People here have already started rebutting the need for this as Java is fast, has great libraries and enforces good writing style. In response to that, from a person who makes his living writing Java:

• Java is fast. It runs close to C/C++ in basic algorithm tests from what I've seen, depending on your runtime settings and VM.
  
  
• Java's lack of direct pointer manipulation (e.g. pointer arithmetic) does help people from hurting themselves and that alone leads to better code. The OO nature helps a bit, but really, not much more than taking C++, removing pointer manipulation and removing huge reliance on globals. Obj-C, which I use in my hobbies for OS X, is just as good an OO language, with some minor quibbles about its syntax being more awkward. The lack of memory control in Java loses out big time to the option of manual or automatic memory deallocation in Obj-C. Big Time Loss, even in 1.4.
  
  
• Java's libraries lead to code bloat. People substitute poor use of OO code and APIs for their poor use of pointers in their C work. Sun encourages this poor use by advertising its APIs' functionality and not their many weak points and the fact that its APIs aren't particularly efficient outside of a limited scope.
  Example: People commonly use a Vector when they just want an array of simple types (e.g. int) that will always be "large enough". Vector implements things that have nothing to do with this functionality and Vector doesn't support simple types. Code using the Vector with an Integer rather than an array with an int runs at less than 2/3 the speed and has a much larger memory overhead. Yes, teaching will help people reduce this error but with many classes the poor API coding is two, three or four parent classes above the class you think about using and oftentimes performance of the code is obfuscated - you don't want to have to write replacement code and test yours by theirs in order to determine if you should write replacement code. Java substitutes interfaces and Object-Orientedness (e.g. "Integer" support but not int) as so-called functionality while sacrificing efficiency and usefulness. Whereas efficient programs like to keep good form while remaining close to the bone, java likes to wrap your whole body in saran wrap and then cover that in tupperware and then let you touch the code through those nice OO pieces of plastic surrounding your hands. People teaching Java generally never tell the students the API code sucks, often because they don't really realize it themselves (in academia) or ..? Or if not that I don't know why they don't. I guess the modus operandi for many Java programmers is to rarely research the code beyond the published docs. It came to heart for me after I had to write an editable text component extending from JPanel as everything they offered was wretched for something requiring complex formatting.
  
  
• Java's libraries are very buggy and often poorly written. In final release versions their code still has questions, e.g. "How should this be handled?". They have some bugswhich are 3 or 4 years old, easily noticeable and in a basic part of their API which aren't even fixed as of 1.4. Leading to...
  
  
• Sun doesn't support community fixes to its libraries. This is the worst thing possible given their oft-shit code. If they simply had a "submit bug fix" section in an easily found place that would help so much. This is the major downfall of them not having truly open source code - you can look, but you can't fix and post so no one else will have to fix. This, above all the other reasons, is why Java still has such a poorly implemented API and thus (through its poorly made API) why it is not automatically the language of choice when considering C++, Java or other OO languages. It's really not the language that is so slow, it's the poor implementations in and the misuse of the APIs.
  

So, please, all you fellow Java programmers, realize that Java is far from perfect, and even just among the languages with an OO nature, it is not the best (none of them are). If Sun made it easy to fix its code, and offered more classes with less "functionality" and better performance it would become vastly better. I don't see Sun really making the changes necessary to make Java fast and memory efficient and, well, responsive to programmer's needs. If this VM can become a practical substitute for coding across platforms I would happily make the switch and would certainly hope that my company does the same. Unfortunately for both these paths the promises therein are still well in to the future.

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.

Re:Faster -- with evidence

[Thorgal]

Ok, I multiplied counters by 100 to get more reasonable times on Athlon1.1Ghz/143MHz SDRAM and to minimize JVM startup overhead. Results:

fantomas:te/> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010827 (Debian prerelease)
fantomas:te/> gcc c.c -o c -O2
fantomas:te/> time ./c
9007199254740992.000000

real 0m19.273s
user 0m19.220s
sys 0m0.000s

fantomas:te/> java -version
java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)

fantomas:te/> time java Compute
9.0071993E15

real 0m18.699s
user 0m18.570s
sys 0m0.030s

Well, enough said.

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