This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: rittle at labs dot mot dot com
- Cc: martin at v dot loewis dot de, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 05 May 2003 14:37:37 -0500
- Subject: Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h
- Organization: OAR Corporation
- References: <200304292202.h3TM2i96031935@latour.rsch.comm.mot.com> <m3y91nf4ec.fsf@mira.informatik.hu-berlin.de> <200305051916.h45JGdb4085553@latour.rsch.comm.mot.com>
Loren James Rittle wrote:
>
> In article <m3y91nf4ec.fsf@mira.informatik.hu-berlin.de>,
> martin@v.loewis.de (Martin v. L�wis) writes:
>
> > Now, with that patch accepted, there is an ABI change for i386.
>
> [For the record, the ABI change was actually introduced Nov 2002 to
> fix the usage of a non-i386 instruction in the i386 configuration.]
>
> > If you would drop i486/atomicity.h, you would break binary
> > compatibility with gcc-3.2-configured-for-i486+. If my understanding
> > is correct (i.e. you would offer binary compatibility otherwise), I
> > think i486/atomicity.h should stay.
>
> OK.
>
> > There are also performance considerations. I have timed the i386 and
> > i486 versions on my PIII (performing the same atomic increment in a
> > single thread over and over again), and found that the i386 version is
> > still 50% slower than the i486 version. For i386-proper, this is ok:
> > you can't do better on this processor. For i486, I think the
> > performance drop should be avoided, especially since more and more
> > i386 systems will get replaced with i486+ over time, so many systems
> > would have to pay for compatibility with systems that are rarely used.
>
> Well, OK, thanks for running that test. But, as you know, the use of
> an atomic is typically buried inside of a use-case that does a
> non-trivial amount of work (typically guarding the allocation of a
> memory resource, etc.). I measured 2-4% slowdown when the code path
> is run in context in a test case that was designed to stress the path.
> I think that number is more representative than an artificial use of
> the atomic add. But no matter, you line of argument wins for 3.3
> release. ;-)
Not to beat a dying or already dead horse but what is the final solution
for 3.3?
> Regards,
> Loren
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985