[chrisseaton]

I don't have any numbers, but I think it's generally possible to write very high performance code in Objective C... by not using the dynamic language features of it such as message sends.

Objective C I believe does a globally cached method lookup for every message send (!) and so can't inline through message sends (!), and since inlining is the mother of all optimisations I would imagine this would severely limit performance if you tried to use a lot of message sends in your inner loops. We should actually think about doing that experiment to see what the cost would be.

In a language like Ruby almost all operators, even basic arithmetic, are dynamic method calls, so you can't avoid using message sends anywhere. I think if you tried to do that in Objective C things might grind to a halt.

Objective C also lacks many dynamic language features which are the ones solved through speculative optimisation, such as integer overflow, access to frames as objects, and so on.

I'm not an expert on Object C though so happy to be corrected.

[mpweiher]

> I don't have any numbers

I do :-) Wrote about a book about it, in fact.

> but I think it's generally possible to write very high performance code in Objective C... by not using the dynamic language features of it such as message sends.

Yes, that's a common misconception...with a grain of truth. In my experience, you get the best performance by judiciously mixing dynamic and static features. And yes, that means eschewing some dynamic features in some inner loops (The 97:3 rule applies). However, you can also often gain significant performance by hiding behind a polymorphic dispatch.

For example, I reimplemented Apple's binary plist parsers+generators in Objective-C (from C) for a significant speed boost: the polymorphic implementation allowed me to put in override points for things such as lazy loading, and interface-based (de-)serialization removes the need for a generic intermediate representation. Compared to those advantages, the cost of message-sends is negligible (and optimizable if it becomes a problem).

> Objective C I believe does a globally cached method lookup for every message send(!)

Yes. It's quite fast and despite what people fret about rarely a problem.

> and so can't inline through message sends (!),

If it does become a problem (measure, measure, measure!), there are techniques to avoid the lookup: IMP-cache, convert to C function call, convert to inline function, convert to Macro.

> since inlining is the mother of all optimisations

Hmm...the mother of all optimizations is measuring and removing unnecessary code. Then comes eliminating/reducing and "sequentializing" memory access.

Very few of these can be automated.

Inlining is nice, too.

[chrisseaton]

Thanks for that extra info.

How do you think Objective C would perform if every operator was a dynamic method call as it is in Ruby? Surely then you'd start to get frustrated with the overhead? That's why languages like Ruby need the speculative optimisations.

[mpweiher]

> How do you think Objective C would perform if every operator was a dynamic method call as it is in Ruby?

Depends very much on what you mean with "every": the 97:3 rule applies, and is almost certainly even more highly skewed today[1]. So for the vast majority of code, it wouldn't matter. Correction: doesn't matter. For example, Apple's Swift language produces code that is incredibly slow when non-optimized, loops and the like can easily be 1000x (a thousand times!) slower than optimized, and yet Xcode's debug builds default to non-optimized and people don't report that their debug builds are unusable.

Another example: I implemented the central re-pagination loop in my BookLightning imposition app[2] in my Objective-Smalltalk language[3], which currently has just about the slowest implementation imaginable (an AST-walker inefficiently implemented in Objective-C), at least an order of magnitude slower than Ruby. Despite that, BookLightning is at least an order of magnitude faster than the OS-X print system, which is largely written in C. Why? It computes by page (which is sufficient for this task), rather than by individual PDF graphical element. That difference is so great that the steering code controlling the computation just doesn't matter.

> Surely then you'd start to get frustrated with the overhead?

As long as Objective-C were still a hybrid language: probably not, because I could always eliminate the overhead in the (very) few places that mattered, and could do so reliably/predictably [4]. In fact, for Objective-Smalltalk I am very much leaning towards that approach (Smalltalk-ish by default, optimizations optional), and so far things are looking good.

> That's why languages like Ruby need the speculative optimisations.

Or C libraries, which is what I believe high performance Ruby code does.

p.s.: I think Truffle and Graal are awesome, and as a researcher I wish I'd come up with them. When doing actual practical performance work, I prefer simpler and more predictable tech.

[1] "The Death of Optimizing Compilers" http://cr.yp.to/talks/2015%2E04%2E16/slides-djb-20150416-a4....

[2] http://www.metaobject.com/Products/

[3] http://objective.st/

[4] http://blog.metaobject.com/2015/10/jitterdammerung.html

[chrisseaton]

But going back to the original argument that was being made - you say that you don't need speculative optimisations to make something like Objective C fast. But you say to do that you don't use the dynamic features where you need performance - use macros and C functions instead.

So yes you don't need speculative optimisations... as long as you apply similar optimisations manually in the source code yourself. I'm not convinced therefore :)

[mpweiher]

> you don't need speculative optimisations to make something like Objective C fast.

There is a difference between "make X fast" and "write fast code in X", a distinction that is hugely important in practice.

So no, I don't need speculative optimization to write fast code in Objectice-C, but I would need speculative optimization to make Objective-C code fast [without touching the Objective-C source code].

> But you say to do that you don't use the dynamic features where you need performance

No, I did not say that at all. I said I mix dynamic features and non-dynamic features where necessary, and that I need both to make things fast. And (more importantly), that the most important optimizations have nothing to do with either (which counters the assertion that inlining is "the mother of all optimizations").

> So yes you don't need speculative optimisations... as long as you apply similar optimisations manually in the source code yourself.

The point being that (a) those optimizations are such a small part of the overall optimization process, which in turn is applied to such a tiny part of the overall code-base, that automation is not needed. Which invalidates the assertion that these optimizations are "necessary". Nice to have? Yes. Necessary? No.

The other point (b) is that optimizations by the compiler/JIT aren't as good as those applied manually for many reasons, one being that the compiler/JIT has to make the transformations indistinguishable at a fairly low-level, whereas the author has a higher-level overview and can adjust the semantics to fit. So doing it manually is also worth it.

The third point is that I cannot rely on the compiler/JIT making those optimizations, there is no guarantee that they will be applied. And with today's performance landscape being what it is, reliability is paramount, meaning that being able to guarantee even a slightly higher bound is more important than meeting a lower bound some of the time or even on average.

> I'm not convinced therefore :)

As long as I am capable of applying those optimizations manually, I have made my original point which is that having these optimizations done automatically is not necessary for performance, but at best "nice to have". Which doesn't mean that more compiler support wouldn't be nice, the process in Objective-C is too ad-hoc.