Re: c++
Re: c++
- Subject: Re: c++
- From: William Stewart <email@hidden>
- Date: Wed, 11 Feb 2009 18:45:31 -0800
I don't want a full-blown discussion here, but from everything we've
seen (including the guts of obj_message send) ObjC is completely
inappropriate for time-constrained, hard deadline driven programming.
The addition of garbage collection makes this more so.
I have no idea how you can assert that C++ is inappropriate for real-
time. Let me put it this way
- You can drive a ferrari off a cliff; doesn't mean that the ferrari
is a bad car.
Bill
ps - I reserve last word in this discussion, so moving on - flames can
be directed to me privately if you want :)
On Feb 11, 2009, at 12:02 PM, Jens Alfke wrote:
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
_______________________________________________
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
| References: | |
| | >c++ (From: Joel Reymont <email@hidden>) |
| | >Re: c++ (From: Jens Alfke <email@hidden>) |
| | >Re: c++ (From: Brian Willoughby <email@hidden>) |
| | >Re: c++ (From: Jens Alfke <email@hidden>) |