Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Michael Ash <email@hidden>
- Date: Fri, 16 Jan 2009 23:21:33 -0500
On Fri, Jan 16, 2009 at 8:03 PM, Justin Carlson
<email@hidden> wrote:
> Of course. Benchmarks were provided, which only cover a portion of the
> subject. Furthermore, vtables are not mandatory in all cases/calls. A good
> optimizer (or properly written class) can overcome such dependencies in
> several cases - optimization is far easier to accomplish outside the
> constraints of the ObjC runtime. So you get faster messaging, and more
> optimization control from C++ objects.
Note that dispatch is not mandatory in ObjC either. It is possible
(you get little help from the compiler, but it's not hard) to use
either a vtable approach or a straight function call for method
invocation, as long as you don't mind the loss in functionality that
this implies.
> The point I am making is: If you know you're working with performance
> critical code, C interfaces or C++ objects/messaging will be slower only in
> exceptional cases (assuming well written objects wrt the language/messaging
> in use), objc objects will only complicate opportunities for optimization
> (from several perspectives). Don't get me wrong, objc a great oo language,
> but writing a standard oo interface with it will either make your
> (performance critical) program either comparably very slow or comparably
> slow and unnecessarily messy/bloated/complex - In short, it is the wrong
> tool for the job. That is my experience and my opinion. So my suggestion is
> that performance critical objects should avoid the objc interface/language
> from the start. I have invested much time in this, and proven it in multiple
> real world cases (not small projects, but complex real programs that
> required much time to change), and provided average real world results in my
> previous messages. I believe everyone involved agrees/knows that the speed
> difference is more than messaging.
I must object to this on two points.
First of all, the speed difference is only in messaging and in object
allocation (ObjC not having stack objects means more reliance on the
heap allocator). There is absolutely nothing else to it. If you are
finding differences in speeds for similar operations it's almost
certainly because of differences in the implementations of the
libraries. For example, you'll find that std::string blows the pants
off NSString. It's not because NSString is hobbled by Objective-C,
it's because NSString is vastly more complex and capable. As another
example, a std::vector<int> will blow the pants off an NSMutableArray
of NSNumber. Nothing to do with messaging (or allocation), and
everything to do with the fact that the C++ version is working with
primitives while the ObjC version is not.
Second, I disagree that C/C++ will be slower only in exceptional
circumstances. Each language has its strengths and weaknesses, and
ObjC's strength is having a wicked fast general dispatcher.
(Considering the decisions going on behind the scenes to figure out
what to invoke, the ~12 CPU cycles spent on each dispatch is a
ridiculously small number.) If your problem happens to map to dispatch
well, then ObjC will be faster for you.
Now, I'm certainly not going to argue that you want to involve ObjC
dispatch in intensive numerical code or anything of the sort. C or C++
clearly win there.
But at the same time, I believe that a lot of the problems in a
typical GUI application map better to "dispatch" than to anything
provided in C or C++. I'm sure you're familiar with Greenspun's Tenth
Rule which states, "Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp." Well I'd like to propose a
parallel rule: "Any sufficiently complicated C or C++ GUI application
contains an ad-hoc, informally-specified, bug-ridden, slow
implementation of a more generalized OO dispatcher."
Note that I don't mean to criticize C or C++ over this. It's simply
that they're not good at it, which is fine, they're not supposed to
be. But GUI apps tend to need a lot of dispatch, and at ~12 cycles
each, it's a bargain in ObjC. When I've seen C/C++ code try to
replicate this kind of decision-making, it tends to involve a lot of C
strings, tons of linear searches, binary searches, or maybe a nice
hash table, and you're lucky to get within a couple orders of
magnitude of objc_msgSend.
I've written a lot of performance-critical code over the years, both
in ObjC and in other languages, and I have never once found
objc_msgSend to be a critical path in anything. Certainly it *can* be
with a sufficiently perverse or specialized design, but it's rare.
It's not even that a good programmer will avoid it when he gets down
to a certain level, but rather the opposite: you really have to *work*
at using enough messages to make their impact significant.
And one final note, I want to reinforce the fact that this discussion
is 100% unrelated to the original post, which claimed not only that
ObjC was "slow" but that it was slow to the point that a single ObjC
message was glitching his video playback, a statement which simply
does not have any basis in reality no matter how slow the language
might actually be for your purposes.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden