Apple’s A15 chip will ship with an objc_msgSend branch predictor | Hacker News Reader

Apple’s A15 chip will ship with an objc_msgSend branch predictor

twitter.com

71 pointscjv21 comments

Not just branch predictor, but "Software Assisted Branch Prediction". See the source at: https://opensource.apple.com/source/objc4/objc4-824/runtime/...

Comment near start says:

/// Code for setting up the H14 ObjC branch prediction control registers.

Does this mean that the compiler can embed smart hints for branch prediction directly in the bytecode, by way of setting very specific dedicated registers?

Intel used to just have branch hint prefixes but they decided to ignore them on modern (from Pentium 4) models. Perhaps Apple found a corner case where it does help, it could be Intel can do some optimization that Apple cant implement due to patents, or it’s just an experiment that is destined to fail as well.

Although it says Software Assisted Branch Prediction, it's really talking about the indirect jumps used for method dispatch rather than conditional branches used for logic.

The only static indirect jump hints I'm aware of, and Intel uses this, is next instruction. Unless it's in the BTB, the default speculated indirect jump target is the next instruction. This means the programmer should make the most common target follow the indirect jump instruction itself. See Assembly/Compiler Coding Rule 50 in the Intel® 64 and IA-32 Architectures Optimization Reference Manual

Note that there appears to only be only one register.

"see Apple ISA Extensions to ARMv8: version H14, chapter 23". If only it were available outside Apple...

Can someone please ELI5 this for me? What is the significance of speeding up objc_msgSend for Objective C?

It is a codepath that is used a lot, in system frameworks that many apps use. So, speeding it up can yield a systemwide performance improvement for all sorts of apps.

Pretty much every method call, unless it is optimized—will go through `objc_msgSend`. The runtime looks up the code for a particular object using `objc_msgSend.` The function signature varies depending on how many parameters the method has but it always has at least 2 arguments—the instantiated object and the method name. Objc calls this the selector. :)

> Pretty much every method call, unless it is optimized

Do those get optimized now? As far as I know, objc_msgSend was never optimized out (as of a few years ago when I was doing iOS dev) because any method can be swizzled and replaced at runtime.

There is some sort of devirtualization that might bypass it. When they announced, Twitter was going crazy about how it might kill ObjC dynamism.

However, what I was to was that you can store the method in a variable, and call it directly, thus bypassing objcMsgSend.

If you write a message send in Objective-C, like [object doSomething], behind the scenes the compiler translates this to a call to the objc_msgSend function in the Objective-C runtime library. This function looks up what code needs to run, taking into account inheritance and all the other dynamic features and runs it. So this function runs really often and is an important target for optimization.

Does this actually apply only for Objective C or can other programming languages benefit as well?

Anything that calls into ObjC benefits as well, and if you built another programming language that used a very similar mechanism, presumably you could also use it.

The functionality seems to be general-purpose, with the branch target being hinted at by providing the location of the branch and the input registers that can be used to calculate the address. However, based on how this is implemented it looks like there is only one place you can use this and Apple is going to use it for objc_msgSend, although its use in WebKit might mean that JavaScriptCore has uses planned as well.

AFAIK all language bindings for the macOS system APIs go through the ObjC runtime library and call objc_msgSend() to invoke object or class methods (not sure about Swift though).

This probably means that a significant number of important apps are still coded in Objective-C, which would not be a big surprise. Is the momentum of Swift language adoption slowing down? If so, perhaps Apple is also hedging their bets.

It’s not so much the apps as the system frameworks they’re built upon, which are still almost universally Obj-C (or some other C-family language). Even if every third-party or user-facing first-party app was 100% Swift, there’d still be massive wins from speeding up objc_msgSend.

(Not to mention that even pure-Swift apps use a lot of Obj-C-isms when touching said system frameworks, like the target/selector setup for most UI controls).

Metal is a mix of Objective-C and C++14 subset as shading language.

Same applies to many system Frameworks written before Swift happened.

I bet they aren't running X rewritten in Swift blog posts inside Apple.

I wouldn't be surprised if Swift also calls objc_msgSend for accessing macOS APIs, or at least a practically identical function.

The Objective-C runtime library (which objc_msgSend is a part of) allows to access the "Objective-C object model" from other languages than Objective-C via a C-API.

Most new Apple project are still started with ObjC, you can tell from those hiring. I mean a little less than two years ago Apple Pay team were "suggesting" doing something new written in ObjC.

My guess is that Apple dont mandate Swift no new project. And the team gets to decide. It will probably be another few years when Swift 6.0 is out before a gradual transition of news apps to Swift by default.

And I am still skeptical of Swift being a system programming language. Sometimes I wonder why Apple dont make some more minor changes and improvement to ObjC.

Reply on news.ycombinator.com