bhlangonijr wrote:The HotSpot VM does that. IMO it is more like a "feature" present in most VM's to improve performance. Although it doesn't make the JVM a "compiler" itself.
It would have been more precise if I had said "many JVMs include a JIT compiler".
bhlangonijr wrote:
The point I was trying to make is that there is a middleman between the Java code and the machine code and it was actually written in the language C++. So how could we expect Java to be faster than C++? English is not my forte but hopefully you will get me this time..
I still don't get you. The middleman doesn't matter, if the middleman is running mostly for a short while before the actual Java program is running as machine code (as is the case in the JVMs that matter most).
Even a "pure" interpreter eventually executes the code as machine code.
Java is not technically a compiler as it REQUIRES a virtual machine or Java runtime in order to work and the source code is "compiled" to something that does not look like native machine code.
Yes, it's true that bits and pieces of it are compiled on the fly and even that this native code is run much of the time for some programs, but that's an implementation detail of the particular java virtual machine and does make the JVM a native code compiler, you are just being silly.
There exists native code compilers for Java - I sometimes use one myself called GCJ and it works very well. THAT really is a native code compiler.
Exactly. Besides I'd expect for a VM doing something more than just compiling code. That would be somewhat pointless.
My point is that running the code through a VM will always have some overhead here or there. It couldn't be faster...
bhlangonijr wrote:The HotSpot VM does that. IMO it is more like a "feature" present in most VM's to improve performance. Although it doesn't make the JVM a "compiler" itself.
It would have been more precise if I had said "many JVMs include a JIT compiler".
bhlangonijr wrote:
The point I was trying to make is that there is a middleman between the Java code and the machine code and it was actually written in the language C++. So how could we expect Java to be faster than C++? English is not my forte but hopefully you will get me this time..
I still don't get you. The middleman doesn't matter, if the middleman is running mostly for a short while before the actual Java program is running as machine code (as is the case in the JVMs that matter most).
The compiler inside the HotSpot not necessarily compile the whole bytecode to machine code as a native compiler does. Sometimes the VM has to wait for some method to be compiled to run it. There is some "instrumentation" in the process.
That compilation only has to happen once for each method, from then on the compiled code can be kept in cache.
The same thing that a normal compiler does, a JIT compiler can do. Yes, the VM may be involved in some operations (for example garbage collection), but that doesn't help your case that the Java program must run slower than code written in another language just because of the way the JVM was written. That would be the same as saying that Assembly can never be faster than C if you sometimes call a C function from the Assembly code. It's just plain false and doesn't make sense. What matters for performance is where most of the CPU time is spent.
I don't know how many more ways I can put it, the point is that JIT compilation renders your argument false in general. If Java is usually slower than other languages in the case of simple benchmarks that can be wholly JIT compiled, that's either due to shortcomings in the language or in the compilers / JVMs.
bhlangonijr wrote:The HotSpot VM does that. IMO it is more like a "feature" present in most VM's to improve performance. Although it doesn't make the JVM a "compiler" itself.
It would have been more precise if I had said "many JVMs include a JIT compiler".
bhlangonijr wrote:
The point I was trying to make is that there is a middleman between the Java code and the machine code and it was actually written in the language C++. So how could we expect Java to be faster than C++? English is not my forte but hopefully you will get me this time..
I still don't get you. The middleman doesn't matter, if the middleman is running mostly for a short while before the actual Java program is running as machine code (as is the case in the JVMs that matter most).
Even a "pure" interpreter eventually executes the code as machine code.
Java is not technically a compiler as it REQUIRES a virtual machine or Java runtime in order to work and the source code is "compiled" to something that does not look like native machine code.
Yes, it's true that bits and pieces of it are compiled on the fly and even that this native code is run much of the time for some programs, but that's an implementation detail of the particular java virtual machine and does make the JVM a native code compiler, you are just being silly.
There exists native code compilers for Java - I sometimes use one myself called GCJ and it works very well. THAT really is a native code compiler.
You are nitpicking. GCJ compiles to native code, a JIT compiler does the same thing. The only difference is that with GCJ the programmer and GCJ do the job, and with a JIT compiler the user and the JVM do it while the user runs a Java program.
As for the part that the JVM is still required, see my previous reply...
rbarreira wrote:
The same thing that a normal compiler does, a JIT compiler can do. Yes, the VM may be involved in some operations (for example garbage collection), but that doesn't help your case that the Java program must run slower than code written in another language just because of the way the JVM was written. That would be the same as saying that Assembly can never be faster than C if you sometimes call a C function from the Assembly code. It's just plain false and doesn't make sense. What matters for performance is where most of the CPU time is spent.
I don't know how many more ways I can put it, the point is that JIT compilation renders your argument false in general. If Java is usually slower than other languages in the case of simple benchmarks that can be wholly JIT compiled, that's either due to shortcomings in the language or in the compilers / JVMs.
I never said "Java must run slower...". Please refer to all my previous posts, my argument was: " How could it be faster?". Can you see the difference?
I understood your point that code executed by JVM can be virtually as fast as the native ones - with JIT compilers. But even then it isn't true for actual JVMs due to the fact it has to deal with a lot of things like storage, GC, etc. Also JIT compilers are less efective optimizing code than traditional compilers for C/C++.
rbarreira wrote:
The same thing that a normal compiler does, a JIT compiler can do. Yes, the VM may be involved in some operations (for example garbage collection), but that doesn't help your case that the Java program must run slower than code written in another language just because of the way the JVM was written. That would be the same as saying that Assembly can never be faster than C if you sometimes call a C function from the Assembly code. It's just plain false and doesn't make sense. What matters for performance is where most of the CPU time is spent.
I don't know how many more ways I can put it, the point is that JIT compilation renders your argument false in general. If Java is usually slower than other languages in the case of simple benchmarks that can be wholly JIT compiled, that's either due to shortcomings in the language or in the compilers / JVMs.
I never said "Java must run slower...". Please refer to all my previous posts, my argument was: " How could it be faster?". Can you see the difference?
I understood your point that code executed by JVM can be virtually as fast as the native ones - with JIT compilers. But even then it isn't true for actual JVMs due to the fact it has to deal with a lot of things like storage, GC, etc. Also JIT compilers are less efective optimizing code than traditional compilers for C/C++.
The answer to the question "how could it be faster" is, "it could be faster for certain programs if the JIT compiler was superior to whatever C/C++ compiler you're comparing to". I already hinted in that direction when I talked about shortcomings in the compilers.
Things like storage, GC, etc. aren't relevant for all programs. For example, I imagine that for a well made Java chess engine they would be pretty irrelevant, as frequent memory allocation is not really needed for a chess engine. In this case the quality of the JIT compiler and the appropriateness of the language to express the core algorithms efficiently would be the only factors in determining the performance.
rbarreira wrote:
The same thing that a normal compiler does, a JIT compiler can do. Yes, the VM may be involved in some operations (for example garbage collection), but that doesn't help your case that the Java program must run slower than code written in another language just because of the way the JVM was written. That would be the same as saying that Assembly can never be faster than C if you sometimes call a C function from the Assembly code. It's just plain false and doesn't make sense. What matters for performance is where most of the CPU time is spent.
I don't know how many more ways I can put it, the point is that JIT compilation renders your argument false in general. If Java is usually slower than other languages in the case of simple benchmarks that can be wholly JIT compiled, that's either due to shortcomings in the language or in the compilers / JVMs.
I never said "Java must run slower...". Please refer to all my previous posts, my argument was: " How could it be faster?". Can you see the difference?
I understood your point that code executed by JVM can be virtually as fast as the native ones - with JIT compilers. But even then it isn't true for actual JVMs due to the fact it has to deal with a lot of things like storage, GC, etc. Also JIT compilers are less efective optimizing code than traditional compilers for C/C++.
The answer to the question "how could it be faster" is, "it could be faster for certain programs if the JIT compiler was superior to whatever C/C++ compiler you're comparing to". I already hinted in that direction when I talked about shortcomings in the compilers.
Things like storage, GC, etc. aren't relevant for all programs. For example, I imagine that for a well made Java chess engine they would be pretty irrelevant, as frequent memory allocation is not really needed for a chess engine. In this case the quality of the JIT compiler and the appropriateness of the language to express the core algorithms efficiently would be the only factors in determining the performance.
Who are nitpicking now? You are just speculating with a very rare hypothesis. You certainly will find exceptions for everything. Stick to the most likely case: HotSpot(Sun or OpenJDK) VM and GCC/ICC compilers.
bhlangonijr wrote:The HotSpot VM does that. IMO it is more like a "feature" present in most VM's to improve performance. Although it doesn't make the JVM a "compiler" itself.
It would have been more precise if I had said "many JVMs include a JIT compiler".
bhlangonijr wrote:
The point I was trying to make is that there is a middleman between the Java code and the machine code and it was actually written in the language C++. So how could we expect Java to be faster than C++? English is not my forte but hopefully you will get me this time..
I still don't get you. The middleman doesn't matter, if the middleman is running mostly for a short while before the actual Java program is running as machine code (as is the case in the JVMs that matter most).
Even a "pure" interpreter eventually executes the code as machine code.
Java is not technically a compiler as it REQUIRES a virtual machine or Java runtime in order to work and the source code is "compiled" to something that does not look like native machine code.
Yes, it's true that bits and pieces of it are compiled on the fly and even that this native code is run much of the time for some programs, but that's an implementation detail of the particular java virtual machine and does make the JVM a native code compiler, you are just being silly.
There exists native code compilers for Java - I sometimes use one myself called GCJ and it works very well. THAT really is a native code compiler.
You are nitpicking. GCJ compiles to native code, a JIT compiler does the same thing. The only difference is that with GCJ the programmer and GCJ do the job, and with a JIT compiler the user and the JVM do it while the user runs a Java program.
As for the part that the JVM is still required, see my previous reply...
This is getting to be a stupid discussion. Java is at heart an interpreter with all the problems associated with this, such as slow startup times, massive run-time, etc. The "hot spot" aspect is an optimization, compiling bits and pieces of the code on the fly. It's a great concept and works very well, but it does not make java a native code compiled language. It cannot be run without this massive interpreter infrastructure which sucks resources of it's own.
If it could produce a native code binary, THEN it's a compiler, but that is not what happens. Some people call things compilers if they produce some kind of intermediate code, saying it is "compiling" source to a virtual machine format, but that is not a compiler either.
The discussion is getting stupid because we are all arguing about what to call it and yet we all agree on what is happening under the covers. But only an idiot calls JVM a native code compiled language - if you want argue about this you are wrong so let's just go with what we agree on - we have no argument there.
bhlangonijr wrote:
Who are nitpicking now? You are just speculating with a very rare hypothesis. You certainly will find exceptions for everything. Stick to the most likely case: HotSpot(Sun or OpenJDK) VM and GCC/ICC compilers.
Regards,
I am saying that your original statement was ridiculous and that's not nitpicking. This one to be precise:
About the "hype" saying Java is faster than C++: I doubt Sun nor any serious person would claim such nonsense. The JVM itself is written in C++ how could it be faster?
There was no point at all in pointing out the language that the JVM was made in as if it mattered much for Java performance, for the reasons I have been pointing out. If you want to keep defending this ridiculous claim go ahead but I'm not arguing that anymore.
Don wrote:
This is getting to be a stupid discussion. Java is at heart an interpreter
You can say that as many times as you want but that doesn't make it true. Java is much more often a JIT-compiled language than an interpreted one. If you can't see the difference after all that I've said, then you don't know much about Java and don't want to learn.
The JVM sucks some resources but for computationally intensive programs like a chess engine that's not the real source of Java's slowness.
rbarreira wrote:
There was no point at all in pointing out the language that the JVM was made in as if it mattered much for Java performance, for the reasons I have been pointing out. If you want to keep defending this ridiculous claim go ahead but I'm not arguing that anymore.
I wouldn' t go that far to state what I've said is ridiculous. Some points that support my reasoning:
1) If you are running Java code by a strict JVM specification ( i.e. emulating the JVM instruction set by interpreting the bytecodes) the execution speed of the code will be bounded to the speed of the program that are interpreting/executing it - in that case the JVM is written in C++. In other words, you can have the execution speed of the Java code as fast as the C++ program which is interpreting it - in the best case. Therefore it cannot be faster.
2) Even if you are relying on JIT to execute the code there are a lot of issues which will prevent your code to be as optimized as a native C++ compiled code. I'll quote some of them (you can find it in the specs):
The Java language is dynamically safe, meaning that it ensures that programs do not violate the language semantics or directly access unstructured memory. This means dynamic type-tests must frequently be performed (when casting, and when storing into object arrays).
The Java language allocates all objects on the heap, in contrast to C++, where many objects are stack allocated. This means that object allocation rates are much higher for the Java language than for C++. In addition, because the Java language is garbage collected, it has very different types of memory allocation overhead (including potentially scavenging and write-barrier overhead) than C++.
In the Java language, most method invocations are virtual (potentially polymorphic), and are more frequently used than in C++. This means not only that method invocation performance is more dominant, but also that static compiler optimizations (especially global optimizations such as inlining) are much harder to perform for method invocations. Many traditional optimizations are most effective between calls, and the decreased distance between calls in the Java language can significantly reduce the effectiveness of such optimizations, since they have smaller sections of code to work with.
Java technology-based programs can change on the fly due to a powerful ability to perform dynamic loading of classes. This makes it far more difficult to perform many types of global optimizations. The compiler must not only be able to detect when these optimizations become invalid due to dynamic loading, but also be able to undo or redo those optimizations during program execution, even if they involve active methods on the stack. This must be done without compromising or impacting Java technology-based program execution semantics in any way.
I agree that the design of Java has some performance problems, I think I actually made that clear earlier (even though at least one of the paragraphs in that quote seems to be outdated, the one that says all objects are heap-allocated).
