Re: c++
Re: c++
- Subject: Re: c++
- From: Jens Alfke <email@hidden>
- Date: Wed, 11 Feb 2009 12:02:59 -0800
On Feb 11, 2009, at 10:48 AM, Brian Willoughby wrote:
This is not true. It is a myth that the ObjC dispatch is slow.
Apple showed as far back as WWDC 2001 that the call dispatch
measured in ix86 cycles is actually slower than the ObjC method
invocation on ppc. Not sure whether they showed a comparison of x86
C++ to x86 ObjC in those days, since it had been a while since Apple
shipped Mac OS X for Intel. But, believe me, the ObjC run time is
highly optimized and uses caching.
I'm not familiar with the presentation you're referring to, but I
worked at Apple until last year, and participated in a number of
internal discussions of objc_msgsend performance, involving the Obj-C
runtime group as well as people working on highly tuned apps like
Safari. And I have a bit of familiarity with the implementation of
objc_msgsend (I've at least read through the asm code a few times...)
It is a fact that, on any single platform, an objc_msgsend is slower
than a C++ virtual dispatch, since it has to do the same thing (double-
indirect through object pointer, then jump) plus several more
instructions in between to look up the selector in the class's method
cache. On a cache miss, a large number of additional cycles ensue to
look up the method in the class hierarchy. (Misses are rare in a warm
process, but they do happen, and real-time code needs to factor them
in.)
I don't know details of clock cycles, and of course those change all
the time. I remember figures of 8 vs 30 cycles being given at one
point, so the difference is significant.
Another source of overhead is that Objective-C calls cannot be made
nonvirtual, nor can they be inlined, two sources of optimization
[albeit potentially dangerous ones] commonly used in C++. (Again, the
issue is well known and has been discussed endlessly within Apple.)
That said, message-send performance usually isn't a problem. I don't
know if it would be an issue for CoreAudio today. I don't know if it
would have been an issue in 2000 when this was being designed. (The
fact that it worked OK for NeXT isn't relevant, since the latency
goals for CoreAudio are, I believe, well beyond what NeXT had.)
Probably the most significant factor in language choice is that
CoreAudio was written (in the late '90s) by engineers who came from
Apple, not NeXT, and were very familiar with C and C++ but not with
Objective-C. (I wouldn't be surprised if big parts of the code base
were also inherited from the classic OS and the cross-platform
QuickTime Media Layer.)
Anyway, it doesn't make a difference to anyone outside Apple, and it's
not really on-topic for this list.
—Jens _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
- Follow-Ups:
- Re: c++
- From: William Stewart <email@hidden>
| References: | |
| | >c++ (From: Joel Reymont <email@hidden>) |
| | >Re: c++ (From: Jens Alfke <email@hidden>) |
| | >Re: c++ (From: Brian Willoughby <email@hidden>) |