This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]