bhlangonijr wrote:The JVM itself is written in C++ how could it be faster?
The JVM is a compiler, it could even be written in BASIC and the compiled Java code might be faster than anything.
Of course, we all know that in general Java is definitely not faster than C or C++.
There is an argument going around that Java could potentially be faster than C because of run-time optimizations, and the fact that it knows what machine it is running on and memory locality of garbage collection.
I am of the camp that it will never be faster and agree with most of the points in this article:
That language "D" by digital mars is designed to support better optimization that C. This may be true but it's not the case yet that it is faster the C - perhaps it could be if as much effort went into the complier as has been the case with C compilers.
A good programmer might be able to avoid some of the issues that lead to slow binaries for a particular language.
bhlangonijr wrote:The JVM itself is written in C++ how could it be faster?
The JVM is a compiler, it could even be written in BASIC and the compiled Java code might be faster than anything.
Of course, we all know that in general Java is definitely not faster than C or C++.
Where did you get that the JVM is a compiler? The JVM is the Java Virtual Machine and is responsible for running the Java bytecode (the compiled artifact). The compiler is present in the JDK which is not required for executing the Java binaries.
bhlangonijr wrote:The JVM itself is written in C++ how could it be faster?
The JVM is a compiler, it could even be written in BASIC and the compiled Java code might be faster than anything.
Of course, we all know that in general Java is definitely not faster than C or C++.
Where did you get that the JVM is a compiler? The JVM is the Java Virtual Machine and is responsible for running the Java bytecode (the compiled artifact). The compiler is present in the JDK which is not required for executing the Java binaries.
Regards,
I believe that most important JVM's compile the compiled bytecode into actual machine code for the architecture being used.
Some JVMs may not do this, but the ones for the most popular architectures / OSs certainly do. If bytecode emulation was always used, Java programs would run MUCH slower on those computationally intensive benchmarks instead of two times slower and similar.
bhlangonijr wrote:The JVM itself is written in C++ how could it be faster?
The JVM is a compiler, it could even be written in BASIC and the compiled Java code might be faster than anything.
Of course, we all know that in general Java is definitely not faster than C or C++.
There is an argument going around that Java could potentially be faster than C because of run-time optimizations, and the fact that it knows what machine it is running on and memory locality of garbage collection.
I am of the camp that it will never be faster and agree with most of the points in this article:
That language "D" by digital mars is designed to support better optimization that C. This may be true but it's not the case yet that it is faster the C - perhaps it could be if as much effort went into the complier as has been the case with C compilers.
A good programmer might be able to avoid some of the issues that lead to slow binaries for a particular language.
I believe as you do, but as a counter point this article may also be interesting:
bhlangonijr wrote:The JVM itself is written in C++ how could it be faster?
The JVM is a compiler, it could even be written in BASIC and the compiled Java code might be faster than anything.
Of course, we all know that in general Java is definitely not faster than C or C++.
Where did you get that the JVM is a compiler? The JVM is the Java Virtual Machine and is responsible for running the Java bytecode (the compiled artifact). The compiler is present in the JDK which is not required for executing the Java binaries.
Regards,
I believe that most important JVM's compile the compiled bytecode into actual machine code for the architecture being used.
Some JVMs may not do this, but the ones for the most popular architectures / OSs certainly do. If bytecode emulation was always used, Java programs would run MUCH slower on those computationally intensive benchmarks instead of two times slower and similar.
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.
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..
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).
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.
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.