This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Native compilation article
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Jeff Sturm'" <jsturm at one-point dot com>, Tom Tromey <tromey at redhat dot com>
- Cc: Anthony Green <green at redhat dot com>, shudo at computer dot org, java at gcc dot gnu dot org, "'martynh at uk dot ibm dot com'" <martynh at uk dot ibm dot com>
- Date: Thu, 31 Jan 2002 14:20:42 -0800
- Subject: RE: Native compilation article
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
>