On Fri, Jan 16, 2009 at 8:03 PM, Justin Carlson <carrierandopera...@yahoo.co.uk> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
