Re: At the edge of LNUM patch
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: At the edge of LNUM patch
- From: askok@...
- Date: 2008年3月27日 11:49:11 +0200
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 2008年3月27日 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