metal-cpp VS objc4

My understanding is the proliferation of “XYZ-cpp” AI frameworks is due to the c++ support in Apple’s gpu library ‘Metal’, and the popularity of apple silicon for inference (and there are a few technical reasons for this): https://developer.apple.com/metal/cpp/

This is basically also what the "official" C++ API for Metal does (https://developer.apple.com/metal/cpp/), it's an automatically generated bindings wrapper which calls into ObjC runtime functions.

I also dabbled a bit with this idea by parsing clang AST-dumps of macOS system headers:

https://github.com/floooh/objc-ast-experiments

Unfortunately this is very brittle, and also broke on ARM CPUs, I guess the shim code needs some ABI adjustments (famously, objc_msgSend has multiple "ABI shapes": https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...).

There's official C++-interface: https://developer.apple.com/metal/cpp/

It doesn't matter if the project driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/).

In the future, the question won't be "what language do I need to learn to code on this platform", but instead "are there language bindings for my favourite language".

this? https://developer.apple.com/metal/cpp/

Doesn't it just use objc/runtime.h and if anything is missing you can just add your custom api calls?

Metal has C++ bindings (which cover a full app lifecycle so you don’t have to touch Objective-C/Swift at all) but they’re based on the Objective-C memory model. There are some helper structs mimicking shared pointers, but you’ll still need to understand the basics of how an autorelease pool is used to avoid memory leaks and/or bad access crashes.

On https://developer.apple.com/metal/cpp/ check Foundation folder and all those nice Object::sendMessage().

> The specific method that's causing me trouble right at the moment is "computeCommandEncoder"

Yeah, it looks like there's no way to avoid autorelease here.

> It looks like objc_retainAutoreleasedReturnValue might be exactly what I'm looking for, even if it isn't 100% guaranteed; if I'm understanding, it would be safe, and wouldn't actually leak as long as you had an autorelease pool somewhere in the chain.

Indeed it would be safe and wouldn't leak, but the optimization is very much not guaranteed. It's based on the autorelease implementation manually reading the instruction at its return address to see if it's about to call objc_retainAutoreleaseReturnValue. See the description here:

https://github.com/apple-opensource/objc4/blob/a367941bce42b...

In fact – I did not know this before just now – on every arch other than x86-64 it requires a magic assembly sequence to be placed between the call to an autoreleasing method and the call to objc_retainAutoreleaseReturnValue.

It looks like swiftc implements this by just emitting LLVM inline asm blocks:

    %6 = call %1* bitcast (void ()* @objc_msgSend to %1* (i8*, i8*, %0*)*)(i8* %5, i8* %3, %0* %4) #4