This is the mail archive of the 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 wrote:
> In article <>,
> (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                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

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