Author: Eugene Nalimov
Date: 18:36:27 11/15/02
Go up one level in this thread
Here are just 3 examples.
Java FP model caused huge (~3x) slowdown on x86 compared to C/C++, Fortran, etc.
The reason is that Java language specification required range check after each
FP operation, and on x86 the only way to do that was through memory. I.e. if you
have
a = b*c + d*e;
any C/C++ or Fortran compiler will generate something like
fld b
fmul c
fld d
fmul e
fadd
fstp a
and Java JIT compiler had to generate
fld b
fmul c
fstp T0
fld d
fmul e
fstp T1
fld T0
fadd T1
fstp a
Sun recently fixed this problem changing Java language (and making it less
portable in the "fast" mode), but that is good example -- portability conflicted
with efficiency.
Second example: Java has no Fortran "no alias" rule, nor C99 "restrict" keyword.
As a result, the following function
void foo (double *a, double *b, double *c, int N)
{
int i;
for (i=0; i<N; i++)
a[i]=b[i]+c[i];
}
can be significally speed up in C by adding "restrict" qualifier to pointers.
Fortran does not requires even that, parameters are always "restrict". There is
no such thing in Java. Compiler can insert alias checks in the simple cases like
this, and generate 2 versions of loop -- but that causes code bloat. And for
complex cases it's not possible.
3rd example: Java memory model prohibits optimizations in lot of cases where
optimization is legal in C/C++. For example,
x = p->a + y->a;
w = q->a;
z = p->a + y->a;
You cannot evaluate "p->a + y->a" once, and then assign it to x and z. Memory
*read* "q->a" prohibits that, at least according to Java Language Specification.
Of course Sun's own Java HotSpot compiler does the optimization and violates
langage specification for performance reasons -- but that's Sun, not Microsoft,
so their compilers can do that, right? :-)
Thanks,
Eugene
On November 15, 2002 at 04:31:11, Daniel Clausen wrote:
>On November 14, 2002 at 20:15:44, Vincent Diepeveen wrote:
>
>>Also JAVA will *never* be as fast as c(++), no *matter* the implementation.
>
>Care to elaborate on that? What 'feature of Java' or 'language construct'
>doesn't allow Java to be as fast as C++?
>
>The only thing I can see at the moment is the fact that in Java all methods are
>virtual, whereas in C++ you can (I'd say 'have to') define which methods are
>virtual and which are not. But the speed advantage of non-virtual methods is not
>really that big... (basically it's just one more pointer-indirection)
>
>Btw: The speed of Java is not as bad as many believe. But somehow it stays in
>peoples heads forever, no matter what. Similarly to cookies in web-programming,
>which will stay 'dangerous' for all time.
>
>Sargon
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.