Hacker News Reader

Comment by verstaen | Hacker News Reader

There's a lot of caching involved. And it brings a lot of benefits.

There's no inline caching is there though? And so no 'mother of all optimisations' inlining. Or is my understanding of how Objective C works mistaken?

You wouldn't dream of implementing a dynamic language these days designed for performance without basic polymorphic inline caching. But Objective C seems to get by fine without it. Maybe it's not as essential as we think.

There’s no inlining, because determining whether inlining wpuld be safe is probably Turing-complete. However, IMP cacheing is a thing and that’s enough for most cases. For the rest there is C and (Objective-)C++.

Your comment was killed very quickly, strangely, but I though it had valid content so I revived it. The actual issue against inlining is that anybody can intercept method calls, even from places that the compiler cannot know about such as bundles loaded at runtime. So this isn’t even an issue with Turing-completeness; it’s an impossible problem to solve at compile time.

> at compile time

That's the key thing - other languages which solve this solve it dynamically.

Yeah, that’s what a JIT does. Unfortunately that’s not something that Apple really wants to open the door to on their platforms, especially for native code.

I don’t think that comes into play here. Objective-C is C, and although you could JIT any language, C isn’t made for it, both philosophically (one of its main claims to fame is ‘close to the metal’) and technically (a source file cold be compiled multiple times with different macro definitions or with a different set of #included files)

C isn't made for JIT because it's static; that's why inclining exists. Objective-C has room to improve because it has dynamic function calls.

C can also benefit from inline caching - function pointers!

Did you mean to say "NP-Complete" where you said "Turing-complete"?

There’s no inlining for Objective-C methods, if that’s what you’re alluding to, because the language dictates that every method call must be observable. objc_msgSend is generally really fast, though; it’s usually as fast as or faster than a virtual function call.

I wonder if /u/mikeash can still comment on this thread!

My recent experience has been that indeed inlining is essential for true "zero-cost abstraction"—say an array of integers with index set/get methods—but that once your abstraction is weighty enough that a method is performing more than a few dozen "interesting" instructions, inlining doesn't win much over how well the modern CPU can already optimize across calls.

EDIT: I should add I'm talking about static inlining. I'm sure your typical alien-technology JIT can identify the exact 800 instruction trace in your inner loop and pull it all together into a perfectly machine-sympathetic sequence that runs 50% faster than anything you could construct statically in the absence of profile-driven feedback.

Do any statically compiled languages have inline caches? This would be a huge loss for ObjC, since it would greatly increase memory pressure by dirtying every text page.

ObjC has per-class out-of-line caches keyed by the selector (intern'd string).

It's true that there's no hope of inlining across a message send, but ObjC's C and C++ compatibility mitigates a lot of this expense. Apps routinely use C and C++ for perf critical sections.

Also some of Apple's APIs are inline C functions (NSMakeRect, etc) and others are designed to minimize dynamic dispatch. Iterating an NSArray typically requires only one message send (see the NSFastEnumeration protocol).

There's also more exotic techniques like IMP caching.

AFAIK objc_msgSend is always called, but it's very heavily optimized and written in assembly language. Mike Ash had a great post: https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti...

Reply on news.ycombinator.com