[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sync.m
From: |
David Chisnall |
Subject: |
Re: sync.m |
Date: |
Wed, 3 Mar 2010 19:34:12 +0000 |
On 3 Mar 2010, at 19:20, Riccardo Mottola wrote:
> Hi,
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
>>
>> In NSObject, we have a lot of code for doing atomic operations, to support
>> old compilers, and we still don't have (for example) fast paths for SPARC,
>> ARM, or MIPS unless you use GCC 4.2 or newer. We only have fast paths on
>> PowerPC and M68K because I wrote the former and worked with Riccardo to
>> implement the latter.
>>
> wow, so except the m68k thing that was done more for fun a weekend but is
> perhaps not of such big interest (or does somebody runs gnustep on an
> embedded platform?) Sparc, ARM and MIPS would be of wider use.
>
> I can look and test Sparc and MIPS (LE). Maybe we can do that on another
> rainy weekend, David? An excuse to dig out the sparc-asm.
> Actually, I think I did implement it for the Kaffe Java-VM, I should look
> there.
If you're using Clang or GCC >= 4.2 then you get the fast path on these
platforms with the compiler intrinsics. It's only if you're using an older GCC
that you have problems. I'm not sure what your little MIPS machine uses, but
I'd imagine it's a sufficiently recent GCC for this not to be an issue. I
think you said OpenBSD on SPARC32 is still using an ancient GCC, but it is
supported by clang, so it would be worth switching on that platform.
ARM gets a lot of attention from Apple at the moment (apparently they ship some
things with ARM chips in them), so it has good support in clang and quite good
support in recent GCC for EABI platforms, but not so much for OABI ones. I
think there might be some code in MySTEP for the atomic ops though, as I seem
to recall Nikolaus using GCC 2.95 for a long time and performance on a 200MHz
ARM chip using an objc_mutex for protecting reference counts would have been
painful (unless he just didn't support multiple threads, in which case he could
have used nonatomic ops).
Actually, I wonder what kind of performance difference we'd see if we replaced
-retain and -release with nonatomic versions and swizzled the methods to use
the atomic versions when the will become multithreaded notification is posted.
I might have a go at implementing that, if anyone has some good benchmarking
code for testing it...
David
-- Sent from my IBM 1620
- Re: sync.m, Richard Frith-Macdonald, 2010/03/01
- Re: sync.m, David Chisnall, 2010/03/01
- Re: sync.m, Gregory Casamento, 2010/03/01
- Re: sync.m, Nicola Pero, 2010/03/01
- Re: sync.m, Richard Frith-Macdonald, 2010/03/03
- Re: sync.m, David Chisnall, 2010/03/03
- Re: sync.m, Riccardo Mottola, 2010/03/03
- Re: sync.m,
David Chisnall <=
- Re: sync.m, Markus Hitter, 2010/03/05