Subject: Re: problems with ahc vs. format command
To: None <email@example.com, firstname.lastname@example.org>
From: None <email@example.com>
Date: 06/12/2001 17:13:15
On Tue, Jun 12, 2001 at 12:45:02PM -0400, Todd Vierling wrote:
> On Tue, 12 Jun 2001, Manuel Bouyer wrote:
> : > callout_reset(&scb->xs->xs_callout,
> : > (newtimeout > 3*1000*1000 ?
> : > ((newtimeout / 1000 + 1) * hz) : (newtimeout * hz) / 1000),
> : > ahc_timeout, scb);
> : The question is whenever the test is really less expansive than the
> : 64bit computation. I think on some platforms it may be more expensive.
> Only on LP64 platforms, really (sparc64, alpha) -- and those could be
> conditionally compiled to use solely 64-bit arithmetic.
> The flip side is that a 64-bit "/ 1000" is a *lot* slower than its 32-bit
> equivalent on ILP32 platforms, particularly those for which even integer
> divide is a library function (sparc v7).
Hum, yes I was only thinking about multiplication, no divide.
Since multiply and divide are often implemented to render 2-4 bits/cycle,
64-bit multiply/divide is often more expensive on 64-bit platforms too.
Do we have a macro that could be tested to know whenever we're on a 32 or
64bit platform ?
There has been a lot of argument aboout this but as yet no specific
macro has been decide upon.
Having said that, the comparison of an integer to a constant is fast,
predictable and can be done early. And since timeouts that overflow
32-bits are rare, it would be a good idea to have two code paths, one
that does 32-bit arithmetic and one that uses explicit 64-bit math.