This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] ARM: Add optimized ARMv7 strcmp implementation
- From: Matt Turner <mattst88 at gmail dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Will Newton <will dot newton at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 25 Apr 2014 12:30:33 -0700
- Subject: Re: [PATCH] ARM: Add optimized ARMv7 strcmp implementation
- Authentication-results: sourceware.org; auth=none
- References: <1398256338-24784-1-git-send-email-will dot newton at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1404241437500 dot 6535 at digraph dot polyomino dot org dot uk> <535A42E8 dot 906 at arm dot com>
On Fri, Apr 25, 2014 at 4:11 AM, Richard Earnshaw <firstname.lastname@example.org> wrote:
> These are the improvements for a production board with cortex-a15. For
> very short strings there's a fair amount of noise in the measurements,
> but the regressions are generally very small, while the improvements can
> be significant. Yes, there are cases where the new code is more than
> three times faster.
> Length 1024 alignment 0/0: 238.38%
> Length 1024 alignment 0/0: 239.21%
> Length 1024 alignment 0/0: 247.45%
While for these cases it's clear from the surrounding context what
these numbers mean, I recommend not using percentages to describe
performance improvements. I'd be nice for glibc to adopt this policy
for sake of consistency and clarity.
If I saw in isolation
> Length 16 alignment 0/0: 105.97%
I wouldn't know whether this was measured relative to the original
performance (and was 5% faster) or as a speed up over the original
performance (and was a bit more than twice as fast).
This could be unambiguously written as
> Length 16 alignment 0/0: 2.0597x