Re: apple's objc runtime on linux?

[Dietmar Planitzer]

On Friday, November 7, 2003, at 11:06  PM, Benhur Stein wrote:

> On 2003-11-07 12:57:06 -0200 Markus Hitter <mah@jump-ing.de> wrote:
>
> > How about installing Darwin and do the comparison there? GNU runtime 
> > should compile out of the box there.
> Well, it passed my mind, but I thought it would be too much work.
>
> In fact, it is a curiosity I have, which runtime is faster, and why 
> there always comes
> the idea of unifying runtimes in favor of the apple one. Is it really 
> better, and in which
> aspect? One thing I heard (but it was a long time ago, when I got to 
> know objc, maybe
> it is not like this anymore), was that one great advantage of gnu's 
> runtime is that it is
> thread-safe without the need of locks, while next's behaved 
> differently on multi-threaded
> and single-threaded programs.

NeXT's runtime indeed required a lock in the messenger when support for 
multi-threading was originally added. However, things have changed 
since that. First of all, Apple's current runtime always operates in 
multi-threading mode (objc_setMultithreaded() is a NOP). Secondly, and 
more importantly, it also no longer takes any lock.

Apple's runtime achieves lock free multi-threading support by tacking 
advantage of some Mach APIs and by implementing a simple GC strategy. 
Namely, whenever a new entry is added to a class cache, the class cache 
is copied and the new entry is only added to the copy. The old cache is 
then atomically replaced with the copy (simple pointer replacement) and 
the old class cache is put on a garbage list. From time to time, the 
runtime checks whether some thread is still accessing one of the class 
caches on the garbage list. If so, its left intact. Otherwise the 
memory occupied by the class cache is freed up.

> I took a rapid look at the message sending code of both runtimes and I 
> really doubt that
> apple's can be faster than gnu's.

Well, I really, if not extremely, doubt that GNU's runtime could be 
faster than Apple's on the _same_ hardware and OS. First and foremost, 
because Apple's messenger is written in hand optimized assembler.

Yes, I know that people say that modern compilers produce better code 
than a human being could. Now, reality is a harsh beast and I have yet 
to find a compiler for a RISC CPU which produces really good code. It 
doesn't take much to write assembler code which far outperforms i.e. C 
code compiled with gcc on PPC with optimization level O4. Its even much 
easier for C++...

Further, Apple has invested a lot of time and energy over the past 
years in order to profile the messenger code and to optimize it further 
and further. Today the messenger requires just 21 PPC instructions 
overall. The cache lookup loop code is just 8 instructions which fit 
exactly in a single cache line of the G3/G4 first level cache. Compare 
those 21 instructions to the 9 (PIC to PIC) instructions which are 
needed just to implement a Mach-O style function call stub and you 
should see that you'll have a very hard time achieving the same low 
number of instructions if the messenger would be written in C and the 
code would be produced by a compiler.

Another advantage of the handwritten assembler code is that it makes it 
easy to implement a daisy chain call sequence, where the method 
implementation is called with a simple bctr (jump) instruction. This 
makes it unnecessary to execute two full subroutine calls.

> Some simple measurements I've made on gnu's runtime (time to do 1e9 
> calls
> to an empty method/function):
>
> 19.5 normal method call
>  6.8 indirect pointer (IMP)
>  5.1 direct call to 2-arg function
>  4.2 direct call to void function
>  0.5 empty loop

I think its _very_ important to keep a few things in mind when 
comparing the GNU and Apple runtimes, in order to get meaningful 
results:

I) First and foremost, remember that Apple's messenger is de facto only 
optimized for PPC. This is the platform which is currently relevant to 
Apple. The x86 messenger has not seen as many optimizations over the 
past years.

II) Compare both runtimes on the same hardware platform and OS, only. 
I.e. comparing the GNU runtime running on Linux PPC to the Apple 
runtime on Darwin PPC is probably quite misleading, because Darwin uses 
Mach-O as its binary format and ABI while Linux uses ELF. Different 
ABIs lead to different function call performance.

III) Keep in mind that gcc's code generation quality on PPC is, well, 
limited. Although, it has been noticeably getting better in recent 
versions.

Anyway, regarding a merge of the Apple and GNU runtimes: I'm personally 
not a very big fan of this idea. One reason being that I don't really 
see what the gain would be for the Apple and the GNUstep community. 
Both the GNU and Apple runtime have already been developed and have, 
functionality-wise, not been changing that much over the past years. A 
merge would not necessarily result in any noticeable reduction of the 
maintenance burden for either side. However, there is the real danger 
of making things worse for at least one side. Be it a reduction in 
performance (which would absolutely not be acceptable for me and I 
assume anyone else) or the introduction of legal uncertainty.
There is also the tendency that both sides are effectively moving in 
different directions and have seemingly different priorities. I.e. GC 
support in the GNU runtime vs. exceptions and synchronization support 
in the Apple runtime. A merged runtime would either try to be 
everything to everyone with the implied complexity and possible 
performance degradation, or one side would have to give up something.

I think that the more rewarding thing to do would be to unify the 
(core-) runtime APIs.

Regarding porting Apple's runtime to Linux: Apple's runtime currently 
depends on three Mac OS X specific APIs: CoreFoundation, Mach and dyld. 
The first problem can be solved by trying to get CF to compile on 
Linux. The latter two are, well, a problem :)


Regards,

Dietmar Planitzer