An Alpha at 150 MHz is roughly equivalent to a PPro/PII at 800 - 1000 MHz, for floating-point intensive programs.
On what do you base this? The fastest PIII has a SPECfp95(base) rating of 32.1 (@800MHz), versus 69.4 for the fastest alpha (@667 MHz). The results are similar on SPECfp2000(base) with a PIII system at 243, versus 514 for the fastest alpha system. Much of this difference is due to the superior memory system of high end alpha systems compared to the much cheaper PC systems.
Partly because the Alpha is just blazingly fast for FP operations, and partly because the x86 FP architecture sucks. When they developed the 8087 originally, they chose a design which is flawed from beginning to end, but they couldn't get it to work any other way... And now we're stuck with it.
The main problems with the FPU on x86 processors is the register stack and the small register file (only 8 registers). The register stack can be avoided by using the "3D" instruction set extensions. Alpha has already lost the performance gap (to x86 processors) on integer code, and it's only a matter of time until the floating point performance gap is gone.
But in Java, even if the compiler finds out that a certain method is never replaced by inheritance (overriden) in any class in the program, the program could load new classes at runtime (using Java's Reflection mechanism), thus turning monomorphic call sites into potentially polymorphic ones.
Assuming that dynamic class loading isn't very common, you can just recompile when it happens.
The JVM is a stack machine. This means that naive implementations on register machines result in slow operations, that simply do not take proper advantage of the native architecture even when compiled to native code.
It would have to be a very naive implementation. The Gosling property of the JVM makes it close to trivial to rename the stack locations to registers.
Thirdly... automatic garbage collection is less efficient than hand coded allocation and deallocation, and dynamic allocation is less efficient than static allocation. There are odd cases where this is false, but they generally hold true, and where they do not, the C version can always use the more efficient method anyway. (and extremely fast calls to "new" can be easily achieved... at roughly 50% memory wastage)
But in a dynamic language like Java, the compiler or runtime system can do these sorts of optimizations for you automatically.
Fourthly: Java locks you into a OOP model which is inherently inefficient (at least as done in Java). All function calls must be dynamically redirected etc.
Using class hierarchy analysis, many of these calls can be converted to static calls or even handled inline.
Also note that since C exposes the memory layout to the user (with pointers), the compiler has to be very careful when doing optimizations. It cannot for example reorder structure fields or split structures into hot and cold parts.
Slashdot Mirror
On what do you base this? The fastest PIII has a SPECfp95(base) rating of 32.1 (@800MHz), versus 69.4 for the fastest alpha (@667 MHz). The results are similar on SPECfp2000(base) with a PIII system at 243, versus 514 for the fastest alpha system. Much of this difference is due to the superior memory system of high end alpha systems compared to the much cheaper PC systems.
Partly because the Alpha is just blazingly fast for FP operations, and partly because the x86 FP architecture sucks. When they developed the 8087 originally, they chose a design which is flawed from beginning to end, but they couldn't get it to work any other way... And now we're stuck with it.
The main problems with the FPU on x86 processors is the register stack and the small register file (only 8 registers). The register stack can be avoided by using the "3D" instruction set extensions. Alpha has already lost the performance gap (to x86 processors) on integer code, and it's only a matter of time until the floating point performance gap is gone.
Assuming that dynamic class loading isn't very common, you can just recompile when it happens.
The JVM is a stack machine. This means that naive implementations on register machines result in slow operations, that simply do not take proper advantage of the native architecture even when compiled to native code.
It would have to be a very naive implementation. The Gosling property of the JVM makes it close to trivial to rename the stack locations to registers.
But in a dynamic language like Java, the compiler or runtime system can do these sorts of optimizations for you automatically.
Fourthly: Java locks you into a OOP model which is inherently inefficient (at least as done in Java). All function calls must be dynamically redirected etc.
Using class hierarchy analysis, many of these calls can be converted to static calls or even handled inline.
Also note that since C exposes the memory layout to the user (with pointers), the compiler has to be very careful when doing optimizations. It cannot for example reorder structure fields or split structures into hot and cold parts.