Native compilation article

Thu Jan 31 14:20:00 GMT 2002

I have no idea. But it seems to me (assuming the Prime.java in Martyn
Honeyford's article) that if you inline isPrime, and do any sort of range
analysis (presumably mostly to eliminate subscript checks), you can quite
plausibly deduce that 0 <= i <= 49999, and hence 2 <= test <= 49998. That
in turn suggests that the long % operation can be implemented with a 32 by
16 bit unsigned divide on X86.
I'd be impressed if this is really what's going on. But it would also
suggest that this benchmark should probably be replaced.
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Thursday, January 31, 2002 1:46 PM
> To: Tom Tromey
> Cc: Anthony Green; shudo@computer.org; java@gcc.gnu.org
> 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?
>> Jeff
>