Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Bill Stoddard" <bill@wstoddard.com>
To: "APR Development List" <dev@apr.apache.org>
Subject: RE: [PATCH] example BUSEC patch for benchmarking only
Date: Wed, 10 Jul 2002 22:28:26 -0400
Message-ID: <JHEPKCEMGPKFFDHHDDKDAEJPELAA.bill@wstoddard.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3D2CE372.1090105@apache.org>


> 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
>

I've not looked at the generated code, but profiling indicates that an
additional division is happening, adding an extra 231 instructions.
(xlc_r -O2)

Bill