Speed?

[iago]

http://www.scottsarra.org/timer/timerMain.html
http://www.javaperformancetuning.com/news/qotm028.shtml

It seems like Java actually runs faster for some purposes than C - very interesting

[drivehappy]

I hardly see how the second link can produce the fact that Java is faster than compared compilers. Although I don't know ASM and cannot reverse it; does Java just skip the for loop code altogether? I guess it could be tested with a variable inside the for-loop being assigned an arbitrary value.

[K]

The article is more of a commentary of the advancement of the compiler.  the compiler, like some C/C++ and other compilers, will detect that the code snippet posted doesn't alter the program state in anyway (ie, "do anything") and simply ignore it.  If you compile his code without optimizations, it will take forever to execute just like any other non-optimized implementation.

While I doubt that our current JIT and bytecode languages will ever exceed the speed of natively compiled code, it has been shown that in some cases a very intelligent VM can perform optimizations at run time (path prediction, preallocating memory, etc) that COULD beat out the speed of equivalent native code.

[Tuberload]

If you sit down and think about what the JVM really is, it is quite possible that someday Java could be as fast or faster that C/C++.

The JVM is a replacement for a Java Processor. The bytecode produced by the java compiler, is just a set of machine instructions (just like the machine instructions on a Pentium, etc...) that is interpreted by a Java processor (just like the machine code for a Pentium is interpreted by the Pentium processor). The JVM emulates the Java processor, and allows for Java machine code (bytecode) to be run on any computer that has a JVM built for it.

I hope that makes sense.

[MyndFyre]

While I doubt that our current JIT and bytecode languages will ever exceed the speed of natively compiled code, it has been shown that in some cases a very intelligent VM can perform optimizations at run time (path prediction, preallocating memory, etc) that COULD beat out the speed of equivalent native code.

Perhaps not, but they could probably catch up to be equivalent.  An interesting note about the .NET JITting, which would be nice to see in Java, is the fact that code is compiled from IL to native code, and is then cached, so already-compiled native methods are not JITted again.  Optimizations such as inlining and others are implemented at JIT-time.

If you sit down and think about what the JVM really is, it is quite possible that someday Java could be as fast or faster that C/C++.

The JVM is a replacement for a Java Processor. The bytecode produced by the java compiler, is just a set of machine instructions (just like the machine instructions on a Pentium, etc...) that is interpreted by a Java processor (just like the machine code for a Pentium is interpreted by the Pentium processor). The JVM emulates the Java processor, and allows for Java machine code (bytecode) to be run on any computer that has a JVM built for it.

You're correct in your analysis of the JVM's architecture, but wrong on the point that Java could be faster than C/C++.  Why are emulators so slow?  Because they have to translate instructions.  If there was a pure Java processor (is there?), it could perform Java execution just as fast as an Intel processor could perform C++ (or perhaps faster).  However, consider this hypothetical.

We know the ASM version of variable assignment (mov <loc>, <value>).  Let's say we had a Java disassembler equivalent, and the instruction for Java was put <loc>, <value>.

Code Select Expand


// C
i = 5;
// Java
i = 5;
// Intel ASM
mov   eax, 5
// JASM (don't confuse with JISM)
put    eax, 5


If you're running a JVM, you have to not only translate the code from JASM to IASM, but then execute it.  The easiest way would probably be a literal instruction table using the Java code bytes as an offset into an instruction table, but put it this way:

Code Select Expand


// JVM hits instruction
put    eax, 5

// we look into the table and find the appropriate translation
// then we execute the appropriate translated code
mov   bi, 48h ; we'll say that 48h is the location of "put eax, (const)"
mov   ebx, long ptr command_map[bi] ; I really hope I remember my assembler correctly!
jmp    ebx ; I know you can't jump based on the value of the ebx register, huh?  :-/


Anyway, all that just to find the correct code offset -- which is a pointer to a segment containing the mov instruction and then possibly jumping back to the main program execution.

Well anyway, that's why I say JVM can't be as fast as a pure processor. :)

[iago]

A virtual machine can be faster IF it does optimizations while it's running that aren't possible beforehand.  At least, it would make sense that it could be.  

[MyndFyre]

A virtual machine can be faster IF it does optimizations while it's running that aren't possible beforehand.  At least, it would make sense that it could be.  

But then you have to make a sacrifice in speed to make those optimizations.  Now, especially with VS 8's planned code path evaluation model for C/C++ optimization, which is intended to squeeze every last cycle of optimized running, you're going to have a hard time beating it with an emulator.

[Tuberload]

If you sit down and think about what the JVM really is, it is quite possible that someday Java could be as fast or faster that C/C++.

I said possibly, I didn't say certainly.

Yes as far as I know Sun has developed Java Processors, and they are also working on a complete Java operating system. I was just comparing what the JVM is compared to an actual processor as proof that Java could someday at least be as fast. Thank you for all the details, they are kind of nice to know.

Addition: In the future computers will be fast enough, and Java will have evolved enough that human users will not be able to tell the difference from a Java program to a C++ program. The main emphasis, in my opinion, will be more on portability. Last time I checked Microsoft wasn't to worry about providing versions of their software on other operating systems. I am by no means an expert, but I would take the portability over speed any day.

An analogy to go with what I am saying: If you are paying a programmer $50 an hour to make you a program that you want able to run on multiple operating systems would you rather have him save a couple of milliseconds and compile it into a native executable causing it to have to be ported to all the operating systems that need to be supported, or sacrifice minuscule amounts of time and just program it once? Besides for those really time critical algorithms, you can just program them specifically to each operating system and call them natively.

[MyndFyre]

If you sit down and think about what the JVM really is, it is quite possible that someday Java could be as fast or faster that C/C++.

I said possibly, I didn't say certainly.

Yes as far as I know Sun has developed Java Processors, and they are also working on a complete Java operating system. I was just comparing what the JVM is compared to an actual processor as proof that Java could someday at least be as fast. Thank you for all the details, they are kind of nice to know.

Addition: In the future computers will be fast enough, and Java will have evolved enough that human users will not be able to tell the difference from a Java program to a C++ program. The main emphasis, in my opinion, will be more on portability. Last time I checked Microsoft wasn't to worry about providing versions of their software on other operating systems. I am by no means an expert, but I would take the portability over speed any day.

An analogy to go with what I am saying: If you are paying a programmer $50 an hour to make you a program that you want able to run on multiple operating systems would you rather have him save a couple of milliseconds and compile it into a native executable causing it to have to be ported to all the operating systems that need to be supported, or sacrifice minuscule amounts of time and just program it once? Besides for those really time critical algorithms, you can just program them specifically to each operating system and call them natively.

That, sir, is what Microsoft's big push to .NET is all about.  

[Tuberload]

Hmmm, I will read more into .NET. I didn't think Microsoft was interested in cross-platform support.

[MyndFyre]

Hmmm, I will read more into .NET. I didn't think Microsoft was interested in cross-platform support.

Microsoft Shared Source CLI

The Mono Project

Quake II .NET

Anyway, here's how .NET works (I know this is on the Java forum, but I'll be brief):

Your code is compiled into IL (analagous to Java's Bytecode), and can be deployed without any assembly registration (remember COM's DLL Hell?) -- basically, copy-paste.

IL is object-aware structured language similar to assembly.

When a method is called in a .NET assembly, the JITter (Just-In-Time Compiler) compiles methods and types into native code on the machine.  This results in a minor hit in load-time, but only once -- it caches the compiled methods and only updates them when the original assembly is updated.  All optimizations, including inlining, are performed by the JITter at execution time.

That leaves the implementation of the JITter up to the platform developer.  It may well be that a Java implementation of the JITter will exist for a Java processor, and (as you see at the Mono project), it already runs on a few flavors of Linux.

Anyway, I know this is off-topic, but just letting Tuberload know about it.  

[Tuberload]

Ahh, thank you very much for the information. I have been trying to get a hold of .NET for awhile now to try it out.

[K]

The C# compiler comes free with the runtime.  Look in %WINDIR%\Microsoft .NET\(version)\  for csc.exe.  If you want an IDE, check out C# Builder Personal or #develop

[MyndFyre]

The C# compiler comes free with the runtime.  Look in %WINDIR%\Microsoft .NET\(version)\  for csc.exe.  If you want an IDE, check out C# Builder Personal or #develop

I've heard #develop (pronounced SharpDevelop) is pretty nice.  I didn't know that the C# compiler came with the runtime, although I know that it is definitely included with the .NET Framework SDK.  You might also try out the ASP.NET Web Matrix tool if you are more interested in webdev.

[Tuberload]

Awsome guys! Thanks for the links.