Java is slower than C++!

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I suggest you go look at some of the Jet generated code and you will
see why that is not feasible. The code becomes too fragile to
maintain, and VERY complex.

For example a loop may be implemented as several variations on the
same code with switching at the start to decide which one to use.
You have not the patience for that degree of repetition in hand-coded
assembler.

No one has said anything about it being practical to handwrite
large apps in assembler.

But if they were to handwrite a certain piece of code, then they
can always make it at least as fast as the compiler for the
reasons described.

Arne

 

[Boris Stumm]

Stefan Ram wrote:
[...]

So why is the Java program in the following benchmark still
slower than the C++ program? [...]
C++ 6,75 main1/s
Java 4,67 main1/s

Have you tried Java with the -server switch? Reduces runtime
on my PC from ~24ms to ~18ms, using Java 6.

 

[Roedy Green]

No one has said anything about it being practical to handwrite
large apps in assembler.

But if they were to handwrite a certain piece of code, then they
can always make it at least as fast as the compiler for the
reasons described.

I challenge you then look at some Jet compiled code and see if you
would have the patience to use it techniques even for small pieces.
There is also the problem or readabilty and maintainability.

 

[Patricia Shanahan]

I challenge you then look at some Jet compiled code and see if you
would have the patience to use it techniques even for small pieces.
There is also the problem or readabilty and maintainability.

In the 1980's and early 90's I was a hot-shot code tuner, using assembly
language programming and detailed knowledge of the target hardware. I
would monitor the main buses with a logic analyzer so that I could see
what data accesses were happening when. I studied how the memory
accesses interacted with refresh.

I gave up on that activity when optimizers got so good that I could have
worked for weeks to squeeze out a percentage point, and had to produce
totally unmaintainable code to get even that.

Patricia

 

[Roedy Green]

In the 1980's and early 90's I was a hot-shot code tuner, using assembly
language programming and detailed knowledge of the target hardware. I
would monitor the main buses with a logic analyzer so that I could see
what data accesses were happening when. I studied how the memory
accesses interacted with refresh.

I gave up on that activity when optimizers got so good that I could have
worked for weeks to squeeze out a percentage point, and had to produce
totally unmaintainable code to get even that.

I had a similar experience. My magnum opus was a 32 bit forth than
ran twice as fast anyone else's with every cycle tuned to death.

See http://mindprod.com/jgloss/benchmark.html

We were checking out just how various Java implementation were
implementing a signum method. I discovered to my bafflement that Jet
wrote better code than the best assembler I could come up with.
The code was very clever, but hideous. You could never hand write and
hand maintain it.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I challenge you then look at some Jet compiled code and see if you
would have the patience to use it techniques even for small pieces.
There is also the problem or readabilty and maintainability.

You don't seem to get the point.

Any assembler programmer (capable of using a disassembler) can
make his assembler code as fast as the compiler.

Whether there are any benefits from using assembler or not is irrelevant.

Arne

 

[Roedy Green]

Any assembler programmer (capable of using a disassembler) can
make his assembler code as fast as the compiler.

In principle yes, in practice no.