This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2.0] Use saturated arithmetic for overflow detection.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 01 Nov 2013 13:44:17 -0700
- Subject: Re: [PATCH v2.0] Use saturated arithmetic for overflow detection.
- Authentication-results: sourceware.org; auth=none
- References: <20131030174502 dot GA18107 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1310301749400 dot 22878 at digraph dot polyomino dot org dot uk> <20131030183318 dot GA18706 at domone dot podge> <20131101133126 dot GA2546 at domone dot podge> <5273E29D dot 90000 at cs dot ucla dot edu> <20131101175802 dot GA5471 at domone dot podge>
On 11/01/2013 10:58 AM, OndÅej BÃlka wrote:
> I got similar slowdown on core2, nehalem and fx10 machines.
Conversely, I saw a 2x speedup on my platform, an AMD
Deneb (Phenom II X4 910e):
$ gcc -O2 assembly.c && time ./a.out
real 0m2.096s
user 0m2.095s
sys 0m0.001s
$ gcc -O2 branchfree.c && time ./a.out
real 0m1.057s
user 0m1.054s
sys 0m0.002s
> As code size is concerned my assembly has 8 extra bytes
> (jump 2, xor 3, neg 3). When I use sbb trick from article
> I could decrease that to 5.
5 bytes more than what we're doing now,
or 5 bytes more than the branchfree version?
I'm worried about code bloat compared to
what we're doing now.