This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/3] sysdeps/arm/bits/atomic.h: Use relaxed atomics for catomic_*
- From: Torvald Riegel <triegel at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 06 Oct 2014 15:43:32 +0200
- Subject: Re: [PATCH 3/3] sysdeps/arm/bits/atomic.h: Use relaxed atomics for catomic_*
- Authentication-results: sourceware.org; auth=none
- References: <1412349086-11473-1-git-send-email-will dot newton at linaro dot org> <1412349086-11473-4-git-send-email-will dot newton at linaro dot org>
On Fri, 2014-10-03 at 16:11 +0100, Will Newton wrote:
> Using the relaxed memory model for atomics when single-threaded allows
> a reduction in the number of barriers (dmb) executed and an improvement in
> single thread performance on the malloc benchtest:
I'm aware that we do have catomic* functions and they are being used.
However, I'm wondering whether they are the right tool for what we want
to achieve.
They simply allow to avoid some of the overhead of atomics (but not
necessarily all). Wouldn't it be better to change the calling code to
contain optimized paths for single-threaded execution?
Also, calling code could either be reentrant or not. For the former,
you could even avoid actual atomic accesses instead of just avoiding the
barriers. Also, the compiler could perhaps generate more efficient code
if it doesn't have to deal with (relaxed) atomics.
> Before: 259.073
> After: 246.749
What is the performance number for a program that does have several
threads but runs with your patch (i.e., has conditional execution but
can't avoid the barriers)?
Do you have numbers for a hacked malloc that uses no atomics?