Re: At the edge of LNUM patch

[askok@...]

Thanks for the clarification.

The reason for LNUM slowing modern x86 is maybe just that 
integer calculations (s.a. simple increment) need to be 
range checked to find out potential falling to FP realm. 
For a FP, any operation can just be done, without checks. 
I'll look for a neato way to bypass this, so x86 
double+int32 users won't be hit by the patch (if it gets 
in some day).

-asko


On Thu, 27 Mar 2008 10:34:54 +0100
 David Kastrup <dak@gnu.org> wrote:
> Asko Kauppi <askok@dnainternet.net> writes:
>
> > In my view, Mike's results are in line with the Core Duo 
> > results I had
> > measured.
> >
> > What cannot be done is treat x86 as a single 
> > optimization target. It
> > is not.
> >
> > Then again, modern x86's are utterly fast on FP, which 
> > they calculate
> > as fast as integers.
>
> No, they don't.  Integer arithmetic can be parallelized 
> much more
> thoroughly.  But when we are working with a byte-code 
> interpreter, the
> parallelization will speed up the byte code interpreter 
> itself, but
> hardly the arithmetic fed into it: the interpreter will 
> not issue
> arithmetic fast enough to make a difference.
>
> --
> David Kastrup