PassiveLogic’s truly autonomous control of buildings and more is enabled by the use of physics-based digital twin simulations. To match these simulations to the real world and use them to make optimal control decisions, we need to be able to run these simulations faster than real-time. Additionally, we need to be able to optimize them at the edge, not on massive servers. Differentiable programming and gradient descent optimization are the key items needed to make this possible.

Recently, members of the PassiveLogic compiler team had the opportunity to attend the 2023 LLVM Developers’ Meeting in Santa Clara, CA. It was a tremendously rewarding experience for all of us.

For the vast majority of programmers, when our code doesn’t build or doesn’t run correctly it’s almost always our fault. The compiler is pretty much the last thing we blame. However, at PassiveLogic, we push the limits of the Swift programming language, in particular by using an experimental language feature and helping in its evolution. As a result, “my code broke the compiler” is something you hear a little more frequently around here.

Over the past year, significant work has gone into identifying, reproducing, and fixing bugs in differentiable Swift that stood in the way of specific applications. As a result of that effort, we at PassiveLogic are now able to deploy all of our Swift-based simulation and control software into production. This is an important milestone for us on our way to deploy truly autonomous control systems for buildings.

Back in 2010, I gave a talk about the use of OpenGL shaders to accelerate image and video processing on mobile devices. The response from that talk was strong enough that two years later I started work on the open source framework GPUImage with the goal of making this kind of processing more accessible to developers. In an attempt to broaden the reach of this framework, today I'm introducing the completely-rewritten-in-Swift GPUImage 2 with support for Mac, iOS, and now Linux. This isn't just a port, it's a complete rewrite of the framework.

At the beginning of this year we started a complete rewrite of our robotics software from Objective-C to Swift, for reasons described here. That rewrite was concluded two months ago, passed testing a month ago, and has been deployed to all of our customers. As a result, I wanted to do a final analysis of the rewrite and what we learned from it.

This week, Apple enhanced Swift with several additions or changes, bumping it to version 2. Perhaps the biggest change was the introduction of an official error-handling model based on try/catch semantics. At first, I was skeptical about this approach when compared to other techniques (primarily the use of a Result return value), but after applying it to real-world code, I've found it to work extremely well.

At SonoPlot, we just undertook a full rewrite of our robotic control software from Objective-C to Swift. While at first it might appear crazy to rework a large, stable project in a brand-new language, we did so after carefully examining sources of bugs in our Objective-C application and determining that Swift would prevent a large percentage of them. While we've only just started, we've learned enough so far that I thought there would be value in sharing this.

I always find it more effective to learn new programming concepts by building projects using them, so I decided to do the same for Apple's new Swift language. I also wanted to see how well it would interact with my open source GPUImage framework. As a result, I made GPUImage fully Swift-compatible and I've built and committed to the GitHub repository a couple of Swift sample applications. I wanted to write down some of the things that I learned when building these.