I just got approval to open-source my work on lifting Swift code to GPU kernels. It is currently in the proof-of-concept stage, but we are getting good results so far and starting to roll it out into our product. I'm going through final approvals now and am planning to release the code here soon:
Our current target system utilises an integrated NVIDIA GPU, but in principle it could support other GPU backends in the future (if you squint, the SBC we are using shares many characteristics with the M* SoC, for example).
In the meantime, I'm currently at the LLVM developers meeting, so if you are interesting in using Swift to write code that runs on the GPU, come find me!
I am very interested in this project as I plan to get Swift to work with GPUs (for my Swift OS and other gpu acceleration/workloads). How many GPU models do you tend to support (I currently use "old" models: 1080 ti and a quadro nvs 295)?
Is this project a Swift wrapper or is it a standalone driver?
Internally we are using a Jetson Orin (sm 8.6). If your device is supported by recent CUDA (I'm currently using 12.6) then it will probably work. I don't have access to other cards to try at the moment though.
Also note the Orin is an iGPU, and I'm not sure what performance will be like on a dGPU, but very curious to find out!
A little backgrounder for the Swift community if you are noticing the number of different efforts rolling out. The PassiveLogic team has been building core frameworks for physical AI, autonomous systems, and robotics — all built in the Swift language. We have team members contributing to the Swift compiler or open source for keypath performance, auto-diff, WASM, and now direct-to-GPU. Coming soon are projects we will be open sourcing in introspection types, formal methods, GraphRAG, inferencing, ontological graphs, and distributed computing.
Why are we using Swift?
Python is great for AI prototyping. But it’s not appropriate for the embedded world where AI needs to be fast, continue to learn at the edge, and where you also need to delver bomb-proof systems code. Swift is the only language that can claim 1st-class differentiability, a formal type system, native introspection types, modern safety and concurrency, and fast compiled systems programming — all in one environment. We will be rolling out a series of these projects to open source, over the next year.
It has none of the required features stated. Mojo is a nice competitor for Python, but also takes on much of Python’s +/- for better or worse. Each language is built to solve a set of problems — and conversely doesn’t solve everything.
Similarly Swift derives some of its systems heritage from staying ABI compatible with C — one of its superpowers in for embedded. But if you wanted for example a dynamic language for a web environment — it’s not that.
When talking about embedded compiler-driven systems programming languages for scaled applications, I’m not sure there are any languages that could be taken seriously outside of C++, Swift and Rust for all the obvious reasons. And only two of those are safety-focused modern options for industrial applications. And only one of those has a formal type system, introspection types, auto-diff, and direct C-bridging. None of which Mojo has.
Of course C++ was knocked out of the three contending systems programming languages for not being a safe modern industrial strength language… leaving me only with Rust and Swift to compare in the final knockout round. But also as Joakim wrote, it fails on all other accounts anyways.
I don't have a comparison to Mojo, but that could be interesting to add. The above benchmarks are so simple I would be surprised if Mojo has much to play with, so I think comparing against CUDA (the implementations are taken from the CUDA samples repo) is a good baseline. It's difficult to really see the differences in the above charts, but once the code is available (real soon now™) you can decide for yourself.
