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 not considered slow anymore.
For numerical computation it rivals C/C++ and can be faster in some cases.
JDK 1.4 (now in beta) addresses scaleable I/O.
The graphics pathways to the video card are not as optimized as could be but it is improving in JDK 1.4.
GUI apps are generally OK on (what is now) low-end hardware. However, becoming an effective GUI/Swing programmer is more involved than most people would like to think. However, writing high-performance and bug-free GTK/C code is no easier.
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
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.
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
Yindo
1. download size - 350K and shrinking
2. portable, cross-platform design
3. based on a simple, elegant, dynamic oo language
4. core vm is open source
5. supports cross-platform open standard api's
6. multimedia oriented
7. write once, run anywhere code
8. runs in browsers and as a local app
check it out if you have the time. it's still in beta, but is getting there.
-- "The best way to predict the future is to invent it."
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.
Objects that are used only in the function in which they are created can be allocated on the stack if no references to this object are returned/passed as arguments. In fact recent VMs (Sun 1.3.1, IBM 1.3) do exactly that.
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++.
Well that is what the StringBuffer class in Java is for. StringBuffers are very fast for this kind of thing. While I have to admit that Java immutable Strings make it easier for the developer too generate code which performs poorly it is well possible to produce (text processing) code which performs really well.
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.)
Your numbers are just wrong at least for recent Java implementations. Object allocation is very fast in languages using a generational garbage collector because allocating an object just consists of increasing a pointer by the size of the newly generated object. On the other hand the time needed for object deallocation has to be considered. The cost for deallocation is highly dependant on the number of live objects and the way objects are created. If the way objects are created is "compatible" with the generational GC (i.e. most newly created objects are short-lived) deallocation is very fast as well. Example: Object creation takes about 60 CPU cycles (JDK 1.3.1) on my Athlon 1200 if the objects are discarded directly after creating.
I don't know where you got the "1000 bytes per dynamically allocated object" number from. In JDK 1.3.1 each object has an overhead of 16 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
With this I have to agree.
-- kryps
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.
-It supports many processors.
-It is based on TAO's Intent.
-There are currently STABLE "runtimes" for Linux and Windows, with more in development.
-It's faster than Java.
-Most programs run faster through the runtime than they would if coded in C for a native OS.
-It has already been adopted by Sharp.
It's called AmigaDE.
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