[gui-dev] Re: Faster SHA1 and Tiger MessageDigestSPI's (version1.11)

[Zlatin Balevsky]

There is a good chance an optimization for an intel cpu will be a hinderance for an amd cpu or vice versa. We should be careful not to bias towards either of these markets since we don't really know their relative share.

Btw please keep us updated as to the progress on the memmapped ByteBuffers. The probability of us going to java 1.4 has been increasing as of lately, although its too early to say anything definitive. AFAIK the win32 platform is optimized for manipulating memory mapped files, so this might end up being very useful.

Zlatin

---------- Original Message ----------------------------------
From: Roger Kapsi <***@kapsi.de>
Reply-To: ***@gui.limewire.org
Date: Wed, 30 Jun 2004 13:50:51 +0200

[Roger Kapsi]

Post by Zlatin Balevsky
There is a good chance an optimization for an intel cpu will be a
hinderance for an amd cpu or vice versa. We should be careful not to
bias towards either of these markets since we don't really know their
relative share.

Note (just to ensure that nobody gets it wrong): this isn't a
optimization at all (call it a de-optimization). :) I just needed a
useful toy to play with and as gcc complained about "unexpected
behavior" and thus I had to change the spots and was surprised to see
the boost on the G5.

Post by Zlatin Balevsky
Btw please keep us updated as to the progress on the memmapped
ByteBuffers. The probability of us going to java 1.4 has been
increasing as of lately, although its too early to say anything
definitive.

Cool! :DDDD

cu
Roger

[Roger Kapsi]

"unexpected behavior"

to be correct:

operation on `x' may be undefined

Roger

[Philippe VERDY]

Can you give details about what is reported by the GNU Java compiler as an "undefined" operation on some value?
For me, the Java language spec is extremely precise and fully defines the evaluation order of expressions, by the compiler to byte code, and the JVM spec also clearly and fully decomposes the execution order of the bytecode into lower-level basic operations (load, use, ...), whose behavior is mandatory and limits very strictly how a JIT compiler could translate these operations into native code.

The fact that a JIT compiler will compile this decomposed sequence with operations on CPU registers, or on stack-based local variables in memory, and how these values can be cached and reused later is not in the VM spec, but the value-depency or data-flow is strict and accepts no variation (meaning that there's little place to allow JIT moving some code around, notably when reducing common sub-expressions in loops, or when computing references).
It's very strange that Apple's JIT has a so unpredictable behavior.

Your performance results are suspect on your G5, and due to the other bugs we have seen in the past, it's clear that something wrong on the G5 with the Apple VM. It would be interesting to know if you get the same "suprising" results with a prior version of Java on your G5. I really suspect that the results you get are wrong, even if they seem computed "faster" with a de-optimized source code (and a larger bytecode size, which adds more loads and stores in the bytecode and at run-time).

Message du 30/06/04 18:32
De : "Roger Kapsi"
Objet : Re: [gui-dev] Re: Faster SHA1 and Tiger MessageDigestSPI's (version1.11)

"unexpected behavior"

operation on `x' may be undefined
Roger
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Roger Kapsi]

Post by Philippe VERDY
Can you give details about what is reported by the GNU Java compiler
as an "undefined" operation on some value?

Uh no, not the GNU Java compiler (gcj). I'm talking about gcc...

d += ((e << 5) | (e >>> 27)) + 0x5a827999 // K16
+ ((a & ((b = (b << 30) | (b >>> 2)) ^ c)) ^ c) // Ch(a,b,c)
+ (i00 = ((i00 ^= i02 ^ i08 ^ i13) << 1) | (i00 >>> 31)); // W16

operation on `b' may be undefined
operation on `i00' may be undefined

and so on.

Post by Philippe VERDY
It would be interesting to know if you get the same "suprising"
results with a prior version of Java on your G5.

Java 1.3.1
before: 74.3605 MB/s
after: 78.3699 MB/s

Cheers
Roger

[Philippe VERDY]

Message du 01/07/04 22:10

Post by Philippe VERDY
Can you give details about what is reported by the GNU Java compiler
as an "undefined" operation on some value?

Uh no, not the GNU Java compiler (gcj). I'm talking about gcc...
d += ((e << 5) | (e >>> 27)) + 0x5a827999 // K16
+ ((a & ((b = (b << 30) | (b >>> 2)) ^ c)) ^ c) // Ch(a,b,c)
+ (i00 = ((i00 ^= i02 ^ i08 ^ i13) << 1) | (i00 >>> 31)); // W16
operation on `b' may be undefined
operation on `i00' may be undefined

Thanks for correcting me, I thought you were speaking about the GNU compiler for Java.
Yes I know that in C and C++ the evaluation order is defined as much as precisely as in Java, so it's true that any subexpression that has a side effect on one of its variables is not guaranteed to be compiled and executed in the same order. For example the following C/C++ expressions has an undefined value for c:

int data[] = {1,2,3,4};
int *p = data;
int c = ((*p++)<<24) | ((*p++) <<16) | ((*p++)<<8) | (*p++);

because the side-effect of the incrementation of p is not guaranteed to be executed before the next indirection of p is executed...

So it's true that in C/C++, you need to decompose these expressions with side-effects which are only correct in Java, as documented and guaranteed in the Java specification.