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: martin at v dot loewis dot de (Martin v. Löwis)
- To: rittle at labs dot mot dot com
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, joel dot sherrill at OARcorp dot com
- Date: 04 May 2003 11:27:23 +0200
- Subject: Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h
- References: <200304292202.h3TM2i96031935@latour.rsch.comm.mot.com>
Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> I'd be interested to know what the speed up is versus a different
> mutex library (I guess glibc) and the situation on SMP. Although I've
> been cranky, I'd still want to do anything additional to improve RTEMS
> situation, if still required. Given the minimal slowdown for what I
> consider very heav-duty threaded test cases, my recommendation is to
> remove the i486 implementation entirely for the 3.3 release, if that
> help linkage ABI issues...
I don't think this is desirable. AFAIK, g++ 3.3 will "mostly" maintain
binary compatibility with g++ 3.2.
Now, with that patch accepted, there is an ABI change for i386. IMO,
this has little impact in real life, since there are relatively few
i386-configured 3.2 installations out there (specifically, all Linux
distributions released with gcc 3.2 apparently have configured their
compilers for i486+ (*)).
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.
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.
Regards,
Martin
(*) I don't know how the BSDs have configured their compilers, but I
think cross-version compatibility doesn't matter that much since you
won't have different distributions of, say, FreeBSD which use
different compilers and still want to exchange binaries.