Objective-C D metal binding

[max haughton]

On Saturday, 11 March 2023 at 13:08:49 UTC, Steven Schveighoffer 
wrote:
> On 3/10/23 4:10 PM, ryuukk_ wrote:
>> On Friday, 10 March 2023 at 20:53:23 UTC, Hipreme wrote:
>>> Hello guys. I have been working for some time into binding 
>>> Metal to D.
>>> This has been quite an interesting journey and today I've 
>>> reached a point where it is usable.
>>> It is far from complete, but I included a lot of comments 
>>> from Apple's documentation, and also have tested and got an 
>>> entire Metal hello world working in D.
>>>
>>> The API I worked on is really nice, I manually put the 
>>> opIndex, opIndexAssign, wrapped Objective C Runtime Arrays to 
>>> a strongly typed array in D. The main point into this binding 
>>> is getting Metal to run on Hipreme Engine, so, I don't plan 
>>> into supporting what I don't use. That said, I still welcome 
>>> any contribution to make this a standard way to program using 
>>> Apple's Metal.
>>>
>>> I'll put an example folder the moment I get a dub fix for 
>>> macOS.
>>>
>>> ![Metal MacOS D Hello 
>>> World](https://user-images.githubusercontent.com/10136262/224425800-e417414e-b6be-4e92-93b4-9087b1b281a2.png)
>>>
>>> https://code.dlang.org/packages/d-metal-binding
>> 
>> Congrats!
>> 
>> But metal obj-c? do you mean DMD support only? so no Apple 
>> Silicon (intel only)?
>> 
>> I don't think Intel stuff on mac ecosystem will be a thing for 
>> too long, PPC era already vanished from history
>> 
>> There is the official C++ headers that you can use to make 
>> things easier
>> 
>> https://developer.apple.com/metal/cpp/
>
> From that page:
>
>      No measurable overhead compared to calling Metal 
> Objective-C headers, due to inlining of C++ function calls.
>
> D will not inline C++ function calls. So there will be overhead.

If you are able to use LTO then they'll be inlined. This may be 
slightly easier said that done for some build targets because 
apple's "clang" is actually a closed source fork so it's not 
impossible that there is LLVM incompatibility in there somewhere.

In the absence of evidence suggesting otherwise, the overhead of 
an additional function call is probably quite small relative to 
the metal part of the function call (especially if that Metal 
call ends up waiting on the GPU for something).

I'm now curious if there are I$ optimizations specifically for 
chasing function calls like this.