apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emery Berger" <em...@cs.utexas.edu>
Subject RE: [PATCH] example BUSEC patch for benchmarking only
Date Thu, 11 Jul 2002 02:34:13 GMT
> -----Original Message-----
> From: Brian Pane [mailto:brianp@apache.org]
> Sent: Wednesday, July 10, 2002 8:46 PM
> To: APR Development List
> Subject: Re: [PATCH] example BUSEC patch for benchmarking only
> 
> Bill Stoddard wrote:
> 
> >>Humm... looking at this macro which is used all over the place, I
see a
> >>division.
> >>
> >> #define apr_time_sec(time) ((apr_int64_t)((time) /
APR_USEC_PER_SEC))
> >>
> >>Since APR_USEC_PER_SEC is now a binary representation, I assume
> >>the compiler
> >>will do the proper optimization.
> >>
> >>
> >
> >ie, turn the division into a shift, which is much less expensive.
> >
> 
> It's definitely a valid optimization.  I just checked gcc on
> Sparc and it generates a shift rather than a division.  But
> if the busec code becomes part of APR, I'd rather define the
> macro as a shift, just to make sure that people get the benefit
> of the speedup even if their compilers don't do the optimization.
> (My fear is that some 32-bit compilers might immediately generate
> a call to a library function if they see anything that looks like
> a 64-bit division.)

Brian's concern is quite valid.

For 64-bit integers, VC7 (Microsoft's latest Visual C++) does indeed use
a library call when dividing __int64's (on x86). Shifts are of course
compiled to shifts.

-- Emery

--
Emery Berger
Assistant Professor (starting Fall 2002)
Dept. of Computer Science
University of Massachusetts, Amherst
www.cs.utexas.edu/users/emery



Mime
View raw message