Slashdot Mirror
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.
Sorry, I have no time to download 23M of compressed sources to compile it. But if it crashes for you, you probably have to.
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
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!
It all goes downhill from first post
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:
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
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.
:) of one senior engineer for a month.
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
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