> -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED] > 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
