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.
No way...its too good to be true. something faster and more open but with the same functionality of java? awesomeness.
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$ :)
Beware the Whyte Wolf.
With a gun barrel between your teeth, you speak only in vowels...
"Our vision is to bring the Internet Virtual Machine to the Internet completely, enabling video games, interactive entertainment, and applications to be operated from the Internet on your browser or television"
I wonder how secure they expect this to be? I know I wouldn't want to run an Accounting program (or anything similar) via the internet. Does anyone have any experience with the code to share info?
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
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 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.
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.
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
Help fight continental drift.
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?
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?
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
That would be open sores.
Visit me online.
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).
Helping with organizational effectiveness is our job.
Here is a list of many application frameworks, many of which are cross-platform, and many of which are free software.
My favorite is ZooLib, a multithreaded C++ framework.
Read about the importance of cross-platform application development.
-- Could you use my software consulting serv
Does this imply a MOSX version will be forthcoming? Am I reading into this? (Wishfully?)
Anyone know? Or better yet point me to more FM? I'm glad to read - align my eyeballs as needed! ;-)
---
Information wants...you to shut your pie hole.
At present it only runs on Windows X86 and
Linux X86, thats doesn't sound very portable
to me.
The OpenGL support is nice, and might even
make it useable for 3D games.
The Virtual machine doesn't support JIT
compilation, so i can't see how this can ever be
better than advanced JVMs like Suns Hotspot. They claim there CISC VM is so fast it doesn't need a JIT, i find this very unlikely, benchmarks please.
Threading and SMP support was not mentioned can
IVM handle these yet?
A C/C++ compiler is not available, only Java
and Objective C (both missing libraries), i've never
tried Objective C (what are its pros and cons), so can't comment on it, but if your programming
in Java you might as well use the Java virtual
machine instead of this one.
All in an interesting project, that might become
a useful programming tool, but not for another
couple of years.
Unfortunately, although the GL demos look nice, they don't really reveal much in terms of performance speed. In particular, demos like "gears" do very little CPU work.
:)
Although the idea may be sound, also, I suspect they're going to have a great deal of difficulty achieving the necessary momentum to attract developers, particularly without a solid GUI framework, and such sketchy documentation.
(Besides, everyone and their dog has written a PlayStation emulator by now - if you just want browser games based on a common development platform, why not use those
Personaly, what I would like better then C++ in a VM is something with Java-like syntax which runs natively. What if we had I langauge ( I'd call it 'Z' ) that was as fast as native C++, yet had the easy syntax and object-orientedness of Java? Of course, it would have to be open to be really perfect. And it would be able to access C++ APIs, so that we could use it with OSs and libraries for which no one has yet writen 'Z' API headers..
I have used Java and Objective-C professionally in a very extensive manner, and a little bit of C++. I think they are all great, but I feel more friendly to Objective-C :-) It is great to see that the IVM people have bothered with it.
It would be really fantastic if they made it so that you could inline any language inside any other. The big difficulty with this is that the three languages (C++, Java, Objective-C) have fundamentally different ways of "implementing" objects, particularly method calls, but other aspects as well. Objective-C provides more flexible run-time typing and meta-class objects. Java has decent security, exception and threading built in (decent, not great). C++ has operater overloading, friends, etc.
Check out my Courselet: Architectures with XML Documents
Helping with organizational effectiveness is our job.
Although Java might be a little slower than C/C++ for the majority of applications the speed is fine. Computers are fast enough now to make up for its slight inefficiencies.
I think the main benefit to Java is that it's great for developers. The language basically forces programmers to use good coding techniques which in turn makes modifying the code afterwords very easy.
Besides, how is this new virtual machine an alternative to java?? Isn't it just an alternative to the java virtual machine? Since this new VM can use java.
Where's the source, Luke?
I, for one, don't want to download and run a binary from an unknown site.
I'm a C++ novice... I dabble in VB... I'm trying to teach myself Java... And then here comes yet another language for me to never really fully learn.
Sheesh! Will you people leave me alone?!
'Life is like a spoonful of Drain-O, it feels good on the way down but leaves you feeling hollow inside'
Arent they trying to implement a portable version of the Common Language Runtime library?
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
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!
demos work ok on win98, but in win2k, the ivm prog does nothing.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
Where does it say that this is faster than Java? -- yes, I have read the site.
One of the best things about Java is its libraries -- any open source alternative (and that would be a Good Thing) will have to replicate them before it can be compared to Java -- no matter how fast it is.
Tom
I have discovered a wonderful
I know people like to bag on Perl around here, but it has better portability than Java and is faster for many applications.
Is there any word on support by any big players? The success of a new language such as this will depend entirely on how well it is adopted by the big guys. Without that support this language will likely fail (like many others). Kudo's for /. tooting its horn, this may get adoption of the language faster.
-Sean
Absolute bullshit
"For numerical computation it rivals C/C++ and can be faster in some cases."
The fact is, Java is NEVER used in serious numerical compution. Fortran and C are used to a greater extent, with some advocating C++, but nobody, absolutely nobody even considers Java.
1) Java is far too slow.
2) All the math libs are already written in Fortran and C, and nobody wants to port.
2) Most scientists are not fancy programers and don't care too much about OO, garbage collection, and other frills.
You go to your Physics department and tell them that you want to do 10,000 body Molecular Dynamics in Java and they will laugh your fucking, dumb ass off campus.
Now I can get segmentation fault (core dumped), GPFs, and BSODs without having to port a single line of code!
A choice of masters is not freedom
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
What IVM really is: a simple virtual machine and a gcc target for this virtual machine. If the virtual machine is simple and efficient (4 internal registers almost guarantees using the eax-edx intel registers), then gcc does all the hard work. It does the optimization, it handles multiple front-end languages. Furthermore, since you can run this VM on any architecture or OS, the code is portable. Nice idea, but let's not get all worked up over it... it's not magic.
Black holes are where the Matrix raised SIGFPE
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."
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.
i would agree speed is trivial in this case, but I had written a program )(in java) that parses an ISO9660 filesystem, this program ran relativly slow (relativly compared to what a C prog would take...no i dont ahve times presently) most of the time taken was due to the lack of the ability to cast a set bytes to a class. In java i was required to read in each individual variable (and yes..there are ALOT of them)
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
Do you realize what you're doing when you type:
System.out.println("" + x);
Probably not, so I'll tell you.
First of all, you instantiate a StringBuffer class, which is used to concatenate the "" and the x. Then the StringBuffer is used to create a String object. Then you rinse and repeat to the tune of ten million. That's a LOT of allocating.
As anyone who does Java knows, object allocations are DEATH in java. Avoid them if at all possible.
I bet if you change just the "" + x to just x, you'll shave off those extra 4 seconds.
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?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
"I'm sure a lot of people would be interested in a language as portable as Java but speedier."
yeah! let's name it C!
oh, wait....
". But for every "terror network" that is rooted out, another will emerge"
this is why the head of the snake 'fanatic Islamic leaders' should be eliminated together with the fangs of the snake 'Bin Laden'
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.
Am I missing something ? How can a language 'support' another language (I assume this means relatively full support), support other languages, and yet still be faster than *any* of the languages ? The only thing I can imagine is that their compilers are better, but somehow I doubt that's the answer.
The printing isn't in the scope of the for block.
Yowch. I'm mostly in agreement with your post, but I'm wondering a bit about your execution times. Running the two programs at home (on a moderately fast Athlon) gives:
:) If it's under load from other users, you may not be getting the world's most accurate benchmarks (although it's a pretty close ratio in this case).
15969064845312.000000
0.22user 0.00system 0:00.20elapsed 110%CPU (0avgtext+0avgdata 0maxresident)k
for C and
1.59690648E13
0.01user 0.01system 0:00.32elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
for Java. Or roughly 25-30 times as fast as your times. I'm wondering if your 'large Solaris box' is large because it's using vacuum tubes or large because you've got a whole bunch of people banging on it
Learn some history.
Munich-like: refers to PM Chamberlain's 1938 meeting with Hitler, giving him the Sudetenland (and the rest of Czechoslovakia), in order to appease Hitler. Needless to say, it didn't work, and today, Munich and Chamberlain are often used to describe tactics seen as weak, ineffective and pacifist.
Churchill, Chamberlain's successor, took a more, ahem, proactive approach: declaring war on Germany following the Polish invasion.
And unfortunately, this is what is going to make Java. CPUs are getting so fast that the difference between C and Java isn't going to matter anymore. :\
As a language, Java is a step backward from lisp and C++, but you write in what the rest of the world uses, or sit on the street corner. James Gosling has won, and I have to live with it, I guess.
My biggest complaint isn't Java the language itself, but the people who write in Java. There are some real dumbasses out there who wouldn't last a minute writing C, but they can write workable code in Java. Granted, it's still stupid code, but it runs. I don't think that's a Good Thing.
I'd rather hire someone who has C++ on his resume, and let him learn Java than do the reverse.
wheres the *bsd support? :)
thats more important than win* support.
other notes: first post ever. meow
(FreeBSD Devil) *stabs* (Tux, The Linux Turkey)
Shame on me...
"Java is almost as fast as C." I agree, with evidence.
BS
"Java is almost as fast as C." I DISagree, with evidence.
It all goes downhill from first post
Sorry my bad. Same thing
War is necrophilia.
Yikes! Without a "dumbass" at the end of that sentence I had to check whether I was actually at Slashdot.
Celeron 400, 396mb, cygwin under win2k, gcc -O3, jdk 1.3. I multiplied the counter<10000000 part by ten to get better looking results on my computer; otherwise, times were around 1 second.
/cygdrive/c/temp
./test && time java Test && time java Test2
./test is the c program, Test is the original Java program, Test2 has the System.out.println changed as per your suggestions.
Sat Sep 15, 05:13pm.
$ time
562949953421312.000000
real 0m11.036s
user 0m10.895s
sys m0.040s
5.6294995E14
real 0m8.522s
user 0m0.010s
sys m0.030s
5.6294995E14
real 0m8.523s
user 0m0.010s
sys m0.030s
Just seems like common sense to me.
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.
./icvm bounce
Inconsistency detected by ld.so: dl-version.c: 218: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
stuff
Karma whorin' since 1999
unless you are talking about gui stuff...
I have never seen java go slow unless poorly designed. Gui's and applets will always be slow because of the download time of classes.
Server side stuff can go almost as fast as C++ in some cases with the right runtime environment. It is always faster than VB in server environments.
flame me if I am wrong.
l8,
ac
In java i was required to read in each individual variable (and yes..there are ALOT of them)
That is indeed very slow if you dont use buffered streams. If you don't, try something like this:
FileInputStream file = new FileInputStream(filename);
BufferedInputStream bis = new BufferedInputStream(file);
data = new DataInputStream(bis);
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:
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
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.
Ahh, I can tell that you know a language other than JAVA, because people who only know one language seem to want to defend that language to the death. I am so sick of listening to programmers who only know one language, call themselves programmers, and will fight to the death explaining why that language is better than all others without a good grasp on theory to do so.
:-P
I don't see why this should be any quicker though
>I bet if you change just the "" + x to just x, you'll shave off those extra 4 seconds.
// added for emphasis
// added for emphasis
// println is not in the loop
You lose that bet, because the println is only executed once. Read the code again. I added some
extra braces for emphasis:
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);
}
...
> the answer to your prayers is finally here.
Funny, lately my prayers have been about something different..
Does not sound very cross-platform to me. :)
Why bother.
How do you propose we fight the injustice and inequality that exists in the Middle East? Oh, you were referring to us? Fuck off pal, we're not the ones who are injust.
Yours is an asinine argument. The real injustice and inequality is how the militant Islamic leaders treat their citizens. In Afghanistan, the Taliban government will lop your hand off for stealing. It has stoned to death women who have exposed their ankles.
Jesus Christ, man, wake up! Perhaps we Americans are hated like a criminal hates "The Man", but that shouldn't stop us from doing the Right Thing.
The problem with arguing about java is that it is two things.
:P
1. A language.
2. A virtual machine.
There is no need for a virtual machine. Simply a language with a full and developing library which is cross platform. Any language which is defined and left alone is going to become out of date very quickly.
VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time.
HZ.
ps I'm a Lazy Bastard, not an Anonymous Coward
Has anyone tried building the GNUStep-Base library on this?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak, a wonderful smalltalk implementation. It's great. I've been playing with it quite a bit myself, and have been very pleased with it.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
The following modification makes this code much faster:
int main(void)
{
float x = 0;
int counter;
for(counter = 0; counter 100000000; counter++)
x += (counter * (1 / 3.14159265359));
printf("%f\n", x);
return 0;
}
This works in C and Java! Lazy programming can kill the performance of every language...
Someone else has pointed out that using ""+x where String.valueOf (x) or Integer.toString (x) would be more appropriate is plain bad programming, and it seems your knowledge is a little lacking if you think that Vector is usually implemented with a linked list - take a look at the source for Sun's implementation some time. Vector is a perfectly reasonable data structure to use, and has a great deal of convenience over a bare array, with very little performance cost on good VMs. (If you use ArrayList, of course, you get slightly better performance in most cases, due to it not being synchronized).
There are places where Java performs well, and there are places where Java performs badly. Your tests show neither, particularly.
Jon
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.
There's another difference too, however. If you declare a constant as static, you only take up that memory once. Why would you want constants not to be static?
Jon
I can't see from the web-site how it supports Java, unless you count cross-compilation as "support". On top of that, there aren't libraries for that cross-compilation, making it nigh on useless. It's fine (-ish) to cross-compile the standard Java library Java sources, but what about the native stuff which will rely on JNI bits and pieces? Is JNI itself supported?
Either I've missed something, or this offers very little indeed to Java developers. Anyone care to fill me in?
Jon
PS The fact that their white paper introduction says that 4 years ago Java wasn't adequate for their 3D game doesn't say an awful lot. Java has come on by leaps and bounds since then...
Why would anyone jump ship to this paradigm when the authors show that they don't have the ability to honestly evaluate all the languages they claim need improvement, especially when they go on to tout their product as great because it let's me use all the lanuages just berated?
Why wouldn't I just use CORBA (Common Object Request Brokerage Architecture) if I want a mature standard that does all this already and has things like early and late binding, object persitence, run time type discovery, and anything else you would want from an Object Request Broker.
Don't give me the 'proprietary' argument, because there are GPLed ORBs out there.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
nt
Your benchmark is both trivial and does not take into account the time it takes for the VM to load, thus making it worthless as an argument.
"How about we concentrate on replacing the poor quality non-free software with free alternatives..."
How about we replace to poor-quality *free* software as well. It seems as numerous to me. People seems to think that "As long as it is free (and sometimes GPL:ed) it is good enough no matter what it does". No, it is not.
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.
thanks for posting your numbers.
my only question is what jvm (and version) was used?
Squeak is Smalltalk. That means, among other things:
The is no clear separation between the environment and the program.
There is a confusion between a pointer and the object itself.
There is no finalaization (destruction)
There is a single memory model for instances (heap) versus, for instance, C++es minimum of 4 (heap, stack, static, member-of-another-object)
There is a single model of memory management (garbage collection over ALL objects - lose them and the memory eventually returns - sometimes after a sudden "freeze" of the program). It is automatic and can't be replaced with improved handling of special cases.
There is no strong typing.
The environment is hostile to multi-programmer cooperation.
The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.
Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.
I could go on.
Smalltalk is useful for throwing together a program to run once to get an answer to a question or sometimes to test an idea. It is totally unsuitable for the construction of mission-critical or commercial-grade applications.
Since the problem here is to create an environment for writing code you want to DISTRIBUTE to a large number of people who will use them without being inside their development, it's an amazingly wrong language choice.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
You might check out idel too. It was designed with security in mind from the beginning, and to be easy to compile instead of interpret (so it does have a separation of code and data). OTOH it's not under active development and too underfeatured to be very useful as is -- no C compiler, for example.
But IVM tends to support 3D ambients, its utilisation will remain pitched from mainstream until webmasters -by the way most of them still continue as sons of Java- do include massive reformulation of current proven design projects.
Other hand it's a virtual machine, until it gets refined and providing high level of parallelism, including the alleviation of a big flaw found in Java, that's much of slowness when executing machine operations with intensive use of hardware floating-point.
The games, which are a "recognised" part of fp-intensive family, they hadn't benefit from Java, which speeds up dynamic execution, but they do benefit of C++ -with some hand enhancements-, and originally C it was just designed for the "static-style" software!
It's necessary to know that even using an efficient language as C++ is difficult to extract good 3D performance if the software platform hadn't there specific adaptation for specific hardware.
Combining Java and C qualities and the need of a language capable to supply the end of internet connection as a bottleneck will make IVM really a champ, at least that's my opinion.
Ok, I multiplied counters by 100 to get more reasonable times on Athlon1.1Ghz/143MHz SDRAM and to minimize JVM startup overhead. Results:
/usr/lib/gcc-lib/i386-linux/2.95.4/specs
./c
fantomas:te/> gcc -v
Reading specs from
gcc version 2.95.4 20010827 (Debian prerelease)
fantomas:te/> gcc c.c -o c -O2
fantomas:te/> time
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.
"Man in the Moon and other weird things" - wfmh.org.pl/thorgal/Moon/
Good grief, talk about x86-centric.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Slashdot Trolls, I hereby call you to service to troll slashdot with anti-US, pro-terrorism trolls. Slashdot is just sitting here, ripe for the picking.
So get to work boys and girls. Slashdot needs you in this time of opportunity.
The .NET CLR executes code at about 95% the speed of C, and there is no reason why it can't be ported to any platform you want.
Plus, it has the added benefit of being language independent, and having a massive framework with a really good class library and common type system.
But alas, you will all ignore it because it comes from Microsoft.
VIRTUAL MACHINE - A self-contained operating environment that behaves as if it is a separate computer. For example, Java applets run in a Java virtual machine (VM) that has no access to the host operating system. This design has two advantages:
The second advantage, however, has a downside. Because programs running in a VM are separate from the operating system, they cannot take advantage of special operating system features.
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.
This document is quite old, so some of it has been addresed by successive VMs/APIs.
...to parse his paragraph. Anway, as the creator of Java I'd like you to show more respect for the language.
Sincerely, Mike Bouma
Nice try:
....
.... )
[... C program deleted]
[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)
And here:
[java program deleted]
date && java Compute && date
Fri Sep 14 23:29:53 EDT 2001
1.59690648E13
Fri Sep 14 23:30:02 EDT 2001
(9 seconds)
Seems you are not even able to write a solid benchmar, but you allow your self to spread the informations you based on it?
What did your c program test measure,
date && compute && date?
Basicly:
1)loading a static compiled and (startic or dynamic?) linked c program
2) and executing it.
OTOH:
What did your java program test measure,
date && java Compute && date?
1) Loading a jvm
2) Loading a java class
3) dynamic loading of referenced classes (java.lang.System, well allready laoded together 4) veryfying static safty of the program (illegal opcodes, illegal access to private data, checking about sandbox, etc.)
with jvm)
5) dynamic linking of the laoded referenced class
6) jit compiling the now veryfied and linked bytecode
7) executing the main routine
Well, 6) happends during 7)
So: either you make the calls to date/current-time inside of your programs just before and after your loop, to avoid os and linking overhead to falsify your measurement, or just wrap both loops by an additional loop to execute the inner loop 1000 times.
Or, the clean way: make an empty C program, just printing: "done" and make an empty java program just printing "done".
Substract the running time of the empty programs from the programs you are measuring.
Botom line: in your example teh java program is at elast 2 times faster than the C program, test it by trying the proposed, more exact measurments above.
Regards,
angel'o'sphere
(For the reason why the java program is faster, hint: check what float means in C and what float means in JAVA and how it is compiled to the underlying machine
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
"Really? We're operating on giga- and tera- size datasets, with complex floating-point calculations"
This is totally bullshit. Here at NASA we tried to use java, and guess what, is pure crap. Java is limited to 64Kb databases and it's floating point performance is really bad, mainly because it's based on old Sinclair ZX Spectrum ROM code (from 1982). Sun took the z80 code away, a crap C++ ripoff and sold it like the best thing since sliced bread. You'll get much better performance with modern languages like COBOL or PL/1.
Yours sincerely, Mike Bouma (NASA Engineer)
There's a ton of generated code in there from what appears to be a grammar file but there is no grammar file, nor a code generator. As I said 6 months ago when this was first aired on Slashdot - this is completely useless non-open code.
This is true in general. It is rare to see a project open source or proprietary that is really innovative and different. That's because it's easy to copy existing ideas than to think up and implement new ones.
But remember that the Web (http, server, browser) were started as open source projects and today Apache is still one of the best web servers there is.
If you look around there are number really cool open source projects that are way ahead of anything the propriatary world is doing. Here are two I like:
Jazz - a Zooming user interface, as discussed in Jef Raskin's book The Humane Interface.
Squeak - a ground up implementation of Smalltalk-80 which is being used in all kinds of explorations. One of the leaders of this project is Alan Kay (you've heard of him, haven't you?).
Innovation can come from unexpected places. If more people get to play with the code, then it's more likely that someone will think of something really cool...
...richie - It is a good day to code.
There's no new language being released here, just a new VM.
I can already program in C/C++/Obj-C for just about any hardware platform and many OSes using a little gem known as gcc. Far more platforms and OSes I dare say than this VM. Now, if I could only invoke gcc to compile my down-loaded source code, then we really would have something. Something like RPM or dpkg, say.
-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.
The fact is, Java is NEVER used in serious numerical compution.
It is still a young language, but its use seems to be growing all the time. The Java Grande Forum is an active and vocal group of scientists and numeric programmers who certainly seem to think Java has tremendous potential in those areas. A quote from the site:
Java has potential to be a better environment for Grande application development than any previous languages such as Fortran and C++.
2) Most scientists are not fancy programers and don't care too much about OO, garbage collection, and other frills.
Most scientists who do a lot of programming (in my experience, and I work with several PhD physicists) are extremely interested in new techniques and technologies that'll make them more productive and result in robust, predictable programs. Java does a good job in both areas, and performance is very good with modern VMs.
In short, as far as I can tell, you are clueless. :-)
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I'm resigned to the fact that commercial software usually "requires" RedHat, but I find it more than a little offputting that a Free Software project would do so.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
>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.
Ever heard of STL? A programmer who know STL well beats any Java programmer in productivity. The
problem is that most people don't. And STL is inherent part of C++.
As you said most Java programmers (or should i say most of all programmers) have no ideas about data
structures and don't know how to use em. STL advantages compared to Java:
1) easier to use. YES.
2) shorter code to write. YES. And readable.
3) type safe. No Object-s.
4) faster. Native code.
The first time I used Java data structure classes I had a feeling this was some-sort of screwed up
and minimized copy of STL.
The problem I see with C++ is that it has no one big entity promoting and advancing it. So there
is no one huge unified API. But I largely think that C++ is underestimated. Wake
up people, C++ has evolved during last years, and will do so. It's no VB, it's rocket science
compared to that. And I'm a rocket scientist. Muahahahaha!
Regards,
dedicated C++ fan.
PS: your benchamark doesn't show much
PPS: you should try IBM's JDK, it's really fast with loops
PPSS: In java the bytecode is precompiled during runtime. So to get REAL performance numbers
you should place the code in main into a separate function and call that function multiple times.
Now you just have the runtime compilation time in the 9 seconds.. Or don't tell me. You're the kind
of programmer who's all programs look like that.
What the hell is up with moderating the above post as a troll? There is absolutely nothing in there that any reasonable person could object to.
The issue with companies shying away from the GPL is a fact. I don't mess around with GPLed code for that exact reason. I'm really hoping I manage to get that moderator in metamod *rubs hands gleefully*...
ZFS: because love is never having to say fsck
I've been living in a cave for 5 years praying for exactly this. I like java, the problem is it's so slow it wouldn't even run benchmarks. What's more, without being able to see the source code, how can you be sure Sun isn't using it to spy on you. The other thing I love about free software is how it is always well designed and bug free. Those guys at Sun and IBM think spending billions on R&D will somehow result in better software. It amazes how stupid they are: they just don't get it.
Even the old 1.1 java could do math just as fast as C/C++. But, once you start allocating and freeing objects, C++ could be 20-50 times faster.
If it's 20, that's almost ok, cause 90% of programs don't suffer much from being 20 times slower than they need to be. But when it's 50, it really is often an imposition on the patience of the user and their nerves to make them wait for a response every time they scratch.
Java's second-biggest problem is that it seems to have been designed to run on a virtual machine (or a piece of custom hardware), rather than being translated to native code. This is what made it inefficient for so long. IBM has done a great job of working around this problem, but if it wasn't a problem in the first place, IBM could have spent the time making Java even faster than it s now.
The largest problem I can see with Java, though, it that you're tied to the Java language. This is basically assuming that the Java language fits all for anything that needs to be cross-platform.
My preference right now is the Amiga DE. It's a translated (rather than interpreted) version of assembly language, which means GCC could (at least in theory) have an amigade target. My beef with the Amiga DE is the fact that it's a proprietary standard, which may have been fine 10 years ago, but it certainly doesn't fit into today's reality of open standards.
IVM looks promising in that it seems to address all the problems I've stated above. I hope it does well.
(Please excuse me bad English. It's not my primary language in the morning.)
Thing is, you program will give different results then the other program. Thanks to the inconsistancies of floating point.
this is too big for anal and too small for oral, you moron.
The post was correctly marked as "troll" since Java is proprietary software of Sun Microsystems. You live in a dreamland of make-believe if you say otherwise.
So is there any quantitative way to measure the speed difference? Or is everyone just gonna argue back and forth with "My language seems faster than yours!"?
He obviously doesn't know shit about Java OR benchmarking.
The problem with what you (and others) suggest about using the HotSpot JVM is that it's not standard.
If we're talking "pure" Java, I think a fair comparison should use the default JDK's javac, and the default JDK's java. Of course, we could compare times based on optimized JVMs -- but we wouldn't really compare "real" Java. Instead, we'd compare an imlementation of it.
I agree that optimized JVMs are much more efficient that "pure java", but they convert much of your code to native code. That's a good thing, but drifts from "pure java." At that point, the line becomes fuzzy -- are we comparing "native vs Java" or "native vs (68% native and 32% bytecode)"?
Also, I'd take the "JVM Initialization" argument with a grain of salt. If a program is slow, users simply say "this sucks. It's too slow." I have enormous amounts of respect for Java, its classloader, and portability -- but those still detract from its performance.
Performance considerations included, though, Java is still my favourite and most used language.
It all goes downhill from first post
They've all become incredibly stupid and dull.
Female Prison Rape in NY
Female Prison Rape in NY
Slashdot keeps posting articles about "Java killers" even when they are forced to rehash year-old products, articles and so-called benchmarks, that everybody have already seen (and dismissed) one year ago. Other recent example is Curl (which is new and will probably not succeed, but this will not stop Slashdot from posting dozens of "Curl kicks Java" articles in the following couple years until Curl fades into oblivion).
When it comes to performance, I will not mention the obvious all over again (Java not being slow today etc) but rather point that you can produce an impressive gfx demo even with GW-BASIC, if you have a good interface to OpenGL (or other native, hi-perf graphics library) simply because it's the native code (and better: dedicated HW) that will be doing virtually all the hard work. These demos are worth nothing, unless you can see that the demo app is doing a significant amount of work before piping data to the native engine. But if you are a believer, just fetch JDK1.4.0-beta2 and the JCanyon demo from JavaOne which totally humiliates the tiny "spinning teapot" demos of all "Java killers" I can find.
"I'd rather hire someone who has C++ on his resume, and let him learn Java than do the reverse."
We do exactly that where I work. We used to advertise job openings for "Java Developers" but we didn't get a single applicant who could write a function to reverse a linked list (in any amount of time and memory, much less in the optimal O(n)/O(1)).
Now we advertise positions for people with "multiple object oriented language experience" and we've had MUCH better luck. It usually takes us about 5 days to get a C++ programmer up to speed on Java, since Java is almost a strict subset of C++.
I'm sure someone mentioned this, but I don't see it. The real benefit of Java (duh) is client-server development. RMI is freaking beautiful and simple. Jini is pretty nice, too. There's no other language where client-server or peer-peer development is as easy as Java.
A secondary benefit which I did see mentioned is ease of support/development. You go ahead and write your code in C/C++ - we'll see how quickly you can turn out your product and how easily you can extend and bugfix it.
What an incredible piece of BS. Java, as Microsoft has learned the hard way, is the MOST CLOSED language there is. Simply adding a language extension (say, new keyword) might get you sued by Sun. I do not know of ANY other language with similar level of proprietary control.
"Open source" is something you can actually use in other projects. If your goal is simply to look at the code, almost any company (even Microsoft) will let you do it under some restrictive agreement.
I looked at the Sun's Java license and I see no principal difference between this license and MS NDA. Once you've seen the code, you are tainted in legal sense and technically unable to work on competing implementations.
JVMs and the JITs like HotSpot are where things with highly abstracted languages are moving, as the runtime optimizations that are impossible otherwise become staggeringly powerful. It's a package deal. Java with HotSpot, gcc with -O 2 or better. :-)
gcc is a shitty optimizing compiler. Try comparing Intel's.
Oh God, you are soo wrong... How come you say "inherent design decisions in the way C programs work inhibit" security? Is not the "security" factor a thing that depends on the virtual machine itself rather than programming language? Do you really think that a badly implemented Java machine isn't a threat to security?
Let's face it, the Java language is ONE thing, the Java virtual machine is ANOTHER thing! The fact that they share the same name is a historical incident. One could very well be programming assebley for the JVM as well as C as long as there is an assembler/C-compiler for this JVM.
You keep talking here about the advantages of Java over C and C++ but you really don't seem to get the point: JVM is NOT a programming language! The IVM is NOT a replacement for Java but for JVM. The aspects of Java virsus C and/or C++ is something different and the so-called "security" issues of Java seem irrelevant for the JVM actually.
Check out the kdebindings module from KDE 2.2!
Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library.
...
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.
Sun is not the good guy. Sun is not responsive. In fact I've never in my (1,2,3,4...) 5 years of programming Java have had a bug I voted for actually fixed. They're all still there and noticeable, even in 1.4. If you mention your corporations name they'll break functionality for you* but if you're Joe Schmoe they don't give a damn. Sure they show you bugs and let you vote but YOU CAN'T FRIGGIN' FIX THEM. Sun is just too damn proud for that - after all, their talented staff of programmers doesn't need any help.We recently hired a guy who left Sun's java dev. team (of his own volition) - he wrote the worst code I ever saw in my life. Seriously, second year CS students wrote better code than him. It pains me to think that he may be rejoining our dev. team in a couple of months. Looking into the depths of Java's code you see that kind of quality. You also see architectural choices which are extremely poor. Sun tends to either make things way too
extensible and their sick version of OO or much too inflexible. Rarely do they hit it right. For instance a JFileChooser could be made to work with things outside of Java's implementation of the file system by simply using an interface (for either a JFile or JFileSystem) and instead they write in backdoor methods only available to those classes and completely unextensible - one of the reasons Sun uses the "protected" modifier to limit access by packages and not by inheritance is to help them write this kind of shitty unextensible API code.
Sun is not the good one, Sun is
another of the mediocre ones. They are barely above microsoft's use of C#. Calling the OP misleading for saying Java isn't open source is misleading in itself. It is nice to see the source but it would also be nice to fscking change and fix the source too. Right now, Java 's version of open source is only good for helping to determine whether or not to use the libraries and for figuring out how to get around bugs in their code. Oh, also the fact that the source is copyrighted and you promise not to redistribute it (no, really, go look at the agreements for which you clicked "OK") sort of effects that whole open source thing, too.
*Everyone knows right click on a tree in a standard GUI environment affects selection state - to have it not should have had to have been the workaround, especially since the functionality was already written in there.
I did your test. The java program was slower than the c version. It took an agonizing 370 milliseconds to complete as opposed to 230 milliseconds. I'd be willing to bet that most of the difference was due to jvm initialization.
C:\>cat foo.c
#include
int main(void)
{
double x = 0;
int counter;
for(counter = 0; counter ntimer foo.exe
15915492717639.054688
ContextSwitches - 350
First level fills = 0
Second level fills = 0
ETime( 0:00:00.230 ) UTime( 0:00:00.230 ) KTime( 0:00:00.010 )
ITime( 0:00:00.000 )
C:\>cat foo.java
public class foo
{
public static void main(String args[])
{
double x = 0;
for(int counter = 0; counter ntimer java foo
1.591549271763905E13
ContextSwitches - 351
First level fills = 0
Second level fills = 0
ETime( 0:00:00.370 ) UTime( 0:00:00.300 ) KTime( 0:00:00.030 )
ITime( 0:00:00.000 )
I've finally found the off by one erro
What about AmigaDE?
:-/
It's already got "Write Once" run (almost) anywhere functionality. True, it costs money, but Amiga Inc. isn't aiming for tiny little BS apps with this thing, they're aiming for full scale commercial games and applications. They're trying more to compete with DirectX than they are Java virtual machines, though AmigaDE does Java, too... so it's all win-win.
Sorry, someone had to say it.
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
Portability is BS.. for both this and Java.
What you're talking about is emulation. Gameboy games are more portable than java! (Yes, there are more platforms that have a gameboy emulator than a java interpreter)
You know what a JVM is? It's a Java Bytecode emulator. So enough with "java is portable" crap. Anything can be as portable as java if you take the time to write an emulator for it.
wouldn't Integer.toString(x) convert the float to an int and then parse that int to a string?
And wouldn't that not only be MUCH slower, but also yeld a different result ?
Hrmm... a benchmark you say? If you've read Sun's Java licence, you'll have noticed that several things are forbidden; Use in medical equipment, nuclear power generation, aircraft control systems & publication of Java benchmarks.
my sig's at the bottom of the page.
If you use Objective C you eliminate the code & data separation problem, and have an object model nearly identical to Java. OTOH all of the other disadvantages still exist. The security problem isn't a big deal in a generic sense, anymore than any other program running on any computer; unless, you're planning on making this an engine for applets and servlets, like Java. In this case it would IMHO be a requirement.
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
As promised, some tests with the timing rolled into the runtime environment. I did a couple of things:
:-)
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/sp ecs
/usr/local/sun/jdk1.2.2/bin/java -version
/usr/local/ibm/IBMJava2-13/bin/java -version
:-)
1. Tried to get more accurate timing resolution - for this I used System.currentTimeMillis() in Java, which is a wallclock time, and clock() in C which is CPU time, but since this is an approximate, compute intensive test I didn't feel it was a big issue. In 15 mins of man page archaeology I couldn't find a C or POSIX system call which gave sub-second resolution on wallclock, making part of my my point about C
2. Move the timing inside the programs, so it was only timing the loop (see speedtest.c and Compute.java below)
3. Tried a couple of different versions of the Java VM - Sun's 1.2 JDK with no JIT, and IBM's 1.3 JDK with JIT, to see the difference there - this is not just JIT but also VM general improvements from version to version.
4. Did a test of bundling the loop off into a subroutine so it would get the full benefit of the JIT; to trigger this I call it twice and measure the second pass.
A further baseline observation: your "school's big Sun box" is clearly quite heavily loaded, because I tested using a cheesy old 500MHz P3 and it ran rings around those times. I know the Sun should be faster. This is another problem with benchmarking - what exactly are you measuring? The generally accepted rule is that wallclock on an otherwise idle system is the true measure, but if you're using a shared system, then **for this kind of test** CPU time is a fair proxy.
I tested on the following platform:
Intel Pentium 3, 500MHz, 100MHz FSB, 384Mb RAM
Linux 2.2.12 (Red Hat 6.1)
Running multi-user system, but largely idle
I used the following compilers / JDK's:
[glenfarg:dave]speedtest: gcc -v
Reading specs from
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
[glenfarg:dave]speedtest:
java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)
[glenfarg:dave]speedtest:
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled: jitc))
[glenfarg:dave]speedtest:
One interesting point - when I first tried Compute2.java, it was 10% slower than Compute.java on the Sun JDK, and about a wash on the IBM JDK. The default setting of Java VM's is to start with a modest heap size and dynamically increase it; I found that with the Compute2.java program, increasing the starting heap size with "-ms32M" improved performance in both cases, and those numbers are quoted below. You might argue that this makes Java seem very memory hungry, but that heap includes a lot of stuff besides your 10 lines of code - it doesn't mean it takes a 128M heap to efficiently run 40 line programs
The average quoted times over 10 runs each by the code, using the built in measurement, were as follows:
C version-----------------: 0.78 sec
Compute.java, Sun 1.2 JDK-: 3.39 sec
Compute2.java, Sun 1.2 JDK: 3.51 sec
Compute.java, IBM 1.3 JDK-: 1.24 sec
Compute2.java, IBM 1.3 JDK: 1.09 sec
As you can see, the performance once the JIT gets up to speed is not a million miles away from the compiled C - the latter shows about 28% saving in run time; making both use wallclock timing to get a like for like comparison might bring it one or two points closer.
One might be amused to note that using "gcc -O2" instead of the default option made the C version about 6% SLOWER.
As ever, a benchmark is only a benchmark - if you want a real test, use real code in a real scenario. YMWV.
Enjoy
Dave
Horse output.
What's non-standard about HotSpot? It implements the bytecode perfectly. It may not be the most common JVM, but it's certainly standard.
That's like saying you have to do all performance tests of C++ using MS-Visual Studio on an Intel P3 running Windows 98, because it is the most common platform for compiled C++ code.
I once found something kind of similar in a non-trivial case, which demostrates a more realistic scenario.
A company I used to work for had an object data model stored in an RDBMS, with its own abstraction layer and tools to automatically generate the persister code, demand loading, etc. There were two implementations - one in Microsoft COM, the other in Java. This abstraction layer requires dynamic linkage of the kind not easily possible in plain C++, so it used COM objects for that in the C++/Windows version, and weak references and so forth in Java.
One of the apps had a batch mode "engine" which ran overnight to do number crunching on the data; this was only avalable in a C++/COM version, hence only for NT (this predates COM porting tools). One large customer found Windows NT Server not to be man enough for the job (in those days, a quad Xeon 300MHz was your limit for Microsoft) and wanted the engine ported to their IBM SP/2,; as an experiment, rather than trying to port all the infrastrcture from COM to plain C++, one of the developers quickly recoded the engine in Java over a weekend (note the development time advantage).
Well, as you've guessed, the Java version on the SP/2 was much faster and the customer was happy. This was in the days of JDK 1.1.7 when Java performance was not what it is today, but we expected that result with using hardware that was so much more powerful.
More interestingly the Java 1.1 version was also faster than the C++/COM version on Windows NT - further testing revealed that the cost of the COM dynamic linkage over Java's much more elegant linkage model outweighed the then significant difference in computation performance of the plain compiled C++ vs Java bytecode.
Clearly this can only have moved further in Java's favour with advances in the garbage collector and things like HotSpot - I don't think COM has advanced much in the last 3-4 years, at least not in performance.
The royalties aren't for the language, it is for the patents associated with the language. The ECMA doesn't require MS to disclose its patents until two weeks before it goes to a final vote.
Just because MS submitted it to the ECMA doesn't mean that they won't withdraw their submission (Sun did it twice with Java). Even if MS doesn't withdraw the submission, the ECMA could still reject it.
The ECMA is completely irrelavent unless and until they accept C# as a standard and the world knows about all the related patents.
well,
more to the point, hotspot will do very little for this example. Hotspot is a VM implementation in the style of SELF, and does a very bad job at compiling code the first time around; maybe even interpreting it directly. Then, when enough profiling data has been collected, it goes back and recompiles the code agressively, using the full profiling info to specialise code to be fast for the dynamic common case.
Thus, hotspot is great for servers that have uptimes measured in weeks and programs with long common paths. You aren't going to see much speed in a small program, as your time will be dominiated by profiling costs, rather than payoffs.
As for the classloading delay, people seem to accept an initial delay when starting an application (which can be augmented by quickly slapping up a splash screen), so this isn't really a real world issue.
I once saw an ad for a Java-to-machine-code compiler. (I think it was for Windows.) A free compiler like this would be really useful--imagine if you could bust out 99% of your program in Java, and do the time-critical portions in C. I don't currently do Java, but if something like this came along, I might seriously consider it.
Java is NOT open source, and any familiarity with the open source definition would tell you so.
Yes, open source has a definition, and Java doesn't fit it, any more than PGP or qmail fit it.
Think that it's "practically open source"? Tell you what - why don't you create an installation of java for some linux distribution your company has just created, and then try to convince your company's lawyers that you can distribute the binaries made by your automatic nightly compilation scripts. The Sun license forbids that. (One of the reasons java2 hasn't made it into Debian)
Yes, you can (if you sign or click yes on the appropriate license) see the source, and yes that has its distinct advantages, and yes, the advantages of "visible source" (can we agree on that name for things like java, PGP, qmail and pine?) are some of the same ones touted by loud open source advocates, but it's still not open source. For example, you cannot even distribute the jdk to people not in your own organization; only the jre can be redistributed, and that only if you include enough of it.
Note that I am grateful to Sun for being as open as they have been, and often look at the source myself when the javadoc api fails to answer a question about how a given class really behaves. However, it's not open source and we shouldn't pollute the definition by saying that it is. It's not the traditional "you'll see our source code over our dead bodies" attitude either, but something in-between.
Of course, in this case no conversion is needed at all, as println can cope with a float perfectly well.
(I suspect it wouldn't actually be slower than using String concatenation, but being wrong is definitely more of an issue.)
Jon
This is bottom up thinking here.
Problem:
No language will be widely used if it is not standardized with some open ended license so that Sun, IBM, Microsoft, etc can extend it.
Sun blew it when they litigated for several years with Microsoft over java extensions. End result, Microsoft said that 'open source' with a restrictive license means you don't have 'freedom' to 'innovate' with your own extensions.
Java's great, beats C++, and should have replaced C++ for development now. We'd still have platform differences, but they would be an order of magnititude smaller than windows vs unix.
If Sun had let microsoft 'extend' java, we would have had 1000s of java literate programmers who could much much more easily move to java on unix programming.
The end result here is that Microsoft will continue to push visual basic and visual c++ instead of pushing visual j++ (Java) and visual basic.
I really do hope that Microsoft beats sun at sun's own game by fully releasing c# and allowing anyone to extend it without fear of litigation. I'd think we would see a unix port in short order.
Sun was/is stupid about Java. They passed on XX billions of dollars spent doing java development by many win32 programmers.
Apart from that I cannot be very happy with the tone of your answer. I can understand your frustration, and I am sorry I am not as aware about the subj as you would expect, but every man/woman has to choose his/her areas of interest. My supposition that classes are abstract high level entities is based on my knowledge of computer architecture wich is not as scarce as my knowledge of the SPECIFIC architecture named JVM. I never said that I don't know anything about JVM, I just said that my knowledge does not excel in this particular area. I never had the opportunity (and admittedly neither the inclination) to study any specs or docs about Java (the machine).
Further on, may I point out my finings resulting from the reading of these specifications.
I have specifically looked for security mechanisms within the specifications and I have found the following:
[Introduction]
For the sake of security, the Java Virtual Machine imposes strong format and structural constraints on the code in a class file.
More precisely:
[Java Concepts]
The class RuntimeException is a subclass of class Exception. The subclasses of RuntimeException are unchecked exception classes. Package java.lang defines the following standard unchecked runtime exceptions:
[Structure of the Java Virtual Machine]
These restrictions on operand stack manipulation are enforced, in the Sun implementation, by the class file verifier
May I point that these seem to be the only references to security mechanisms within the specifications (which I take to be the official ones) for the JVM.
Now, as I understand,
The class file verifier -- now this is something more abstract and I find it difficult to understand the verifier's place in the whole mechanism. We know the verifier is run during the loading process. Code loding for any physical machine is done via internal code specific to that machine. For any virtual machine the loading code can be external -- specific to the host machine/enviroment -- or internal as well. Whatever the case -- it seems to me that the verifier is not part of the Java architecture but part of the enviroment, be it the one specific to the machine or to the host. One could easily imagine OSes fitted with various sorts of code verifiers in their code loaders -- similar to what I have deducted Java is doing.
Now, I restate that my knowledge of Java is only scarce and these are first hand observations of a spec I have just encountered these days. Thx for the observation anonymous has kindly provided, but please understand that I am not trying to be cynical rather I am trying to see the bits I am missing from the whole picture.
Oh for crimminy sake, how many times must an article go up on /. where "Crossplatform" equals "Windows *and* Linux"? Not only is this danged IVM not Java (as http://slashdot.org/comments.pl?sid=21648&cid=2302 283 ably points out), it doesn't run on 5% of the world's computers out of the gate.
There's no alternative to Java. As others have pointed out, match your tool to your task and you'll be happy campers. If you want Java, use Java, not some generic knock-off. (If you want Java, but love Bill, use C#, etc.) If you want C, use C. Far as I care, it's already crossplatform -- even Classic Mac compiles C. (yes, that was tongue in cheek)
Ruffin "Wait until the story's cold to get KEEN mod points" Bailey
It's all 0s and 1s. Or it's not.
What? The java version took nearly twice as long! I think it's evident that as the complexity of the equation increases, java's computional speed decreases. :-P