Native compilation article

[Tuomas Leikola]

----- Original Message -----
From: "Jeff Sturm" <jsturm@one-point.com>
To: "Tom Tromey" <tromey@redhat.com>
Cc: "Anthony Green" <green@redhat.com>; <shudo@computer.org>;
<java@gcc.gnu.org>
Sent: Thursday, January 31, 2002 11:46 PM
Subject: Re: Native compilation article


> On 28 Jan 2002, Tom Tromey wrote:
> > Runs with `long' were uniformly much slower than `int'.
>
> Interesting...
>
> > 16364 int -O2 -funroll-all-loops
> ...
> > 48362 long -O2
>
> The huge (factor of 3) difference appears to be caused by register
> spillage.  Perhaps the experiemental regalloc would help.  From a quick
> look at the assembly it wasn't obvious to me how it would improve (though
> I'm certainly no expert on x86).
>
> But the same test with primes.java on IBM's JDK shows it runs _faster_
> with long's than int's.  What optimization could they possibly be using?

for one thing, a JIT can detect the exact model of the processor used, and
apply any extended instruction set, like MMX, SSE2, 3DNow, plus processor
"features" like pipeline stalls etc.

depends. i don't know much about this specific case.

JIT can also do closed world analysis on the fly. (like, classloader drops
any compiled methods that assumed a superclass was not extended
when it notices this is no longer true, etc.) still, i think this is not the
case,
but processor-specific optimization. (hopes of memory architechture-specific
optimization are too far fetched..)