In this article, I talk about the reasoning behind the reduced instruction set architecture of PicoGK, our open-source geometry kernel, which forms the foundation of the LEAP 71 technology stack. Reduced instruction set architectures are not a new concept, and in the following text, I dive a bit into their history and how it eventually led to the creation of PicoGK.
It is easy to think that more is more, when it comes to the functionality of software, especially when it is intended as the foundation for other people’s work. If there is a built-in function for everything, they can get things done quickly.
Going down memory lane — early PCs and where they turned wrong
The same seemed true at the beginning of the PC revolution, when microprocessor manufacturers like Intel and Motorola added more and more instructions to their processors. If you have a suitable function for every task, your software will execute at blazing speeds, as it can rely directly on the native hardware implementation — that was the thinking, and it appeared to make sense.
Computational heat exchanger, based on LEAP 71’s compact open-source geometry kernel, PicoGK
But with complexity comes a cost: Development cycles stretch out and it’s increasingly harder to ensure that your processor is flawless. And of course bugs hardcoded in silicon are really tough to fix later. Complex functionality requires more time to execute, even in silicon, and, as a consequence, the energy use of the processor starts to rise.
Still, the so-called CISC (Complex Instruction Set Computer) processor architecture, won the processor wars and dominated computing for many decades.
There was a counter-movement that started to gain momentum in the 1980s, especially in the field of workstation CPUs. The idea seemed counter-intuitive at first: try to reduce the amount of instructions to an absolute minimum; make the processor as compact as possible. When instructions are simple, you can make them fast, executing in just one CPU cycle. And surprisingly, this often offset the additional work on the software side. Complex code built on simple instructions often ran faster than software built on complex instructions.
RISC to the rescue
This approach, named RISC (Reduced Instruction Set Computer), may have been destined to the annals of a few now-forgotten high-end workstation computer manufacturers — if not for one man, Hermann Hauser.
The BBC Micro personal computer created by Acorn. (Source Wikipedia)
Hauser, an Austrian, who had chosen England as his home, is one of the early PC trailblazers. In 1978 he started Acorn Computers, which briefly become famous for introducing the BBC Micro personal computer, which dominated the British educational market for a while. Acorn pioneered the use of reduced-instruction set microprocessors for home computers. Their processor became known as the Acorn RISC Machine, or short ARM.
Of course ARM processors now are at the heart of practically any modern mobile device, including the MacBooks we use at LEAP 71 and which I am writing this text on.
It turns out, with modern chip technology, you can make the instructions of ARM’s RISC architecture blazingly fast and energy efficient. A low number of instructions is easy to validate and test. In contrast, processor giant Intel, which dominated the market for decades, faced many challenges with bugs and security issues in recent years. Not really surprising, given the enormous amount of functionality hard-coded directly into the CPU.
In this context, RISC was a really good idea, and it became a (decades-late) overnight success.
When I had to devise an approach for PicoGK, LEAP 71’s foundational open-source geometry kernel, I realized, that we should follow the path of RISC, instead of trying to cram functionality into the core, like we did with Hyperganic, my previous company.
CISC was a mistake for geometry kernels too
When Michael Gallo and I started Hyperganic almost a decade ago, we felt pressed to provide a broad set of functionality, otherwise people would not be able to use the Hyperganic Core for anything interesting. So not only did Michael and his team build an entire voxel-based kernel from scratch (with hand-coded assembly language optimizations!), they built a user interface framework, printer output, support structures, complex latticing, infills, warping… All right into the base system. Very much a CISC approach.
Even our first rocket engine, that I presented in my TEDx talk in 2018 was implemented directly in the C++-based core (it was Michael’s 2017 end-of-year holiday project).
In retrospect, it may sound crazy, but we just followed the path that every software vendor is on. Business Development requests a feature that is essential for a client, and of course you build it directly into the software. We always tried to wrap our heads around how we can make it as simple as possible for outside engineers to use the system, ideally without writing code; and implementing high-level, black-box functionality seemed the right thing to do. That’s the path every engineering tool is on today.
The thinking is: ideally, you provide push-button functionality, written by software experts, which hopefully does what you want. Maybe add a few blocks and wires. But the flip side is of course, if there’s no button for it — sorry, you are out of luck, there is no way to extend the system. Maybe raise a support request, and hopefully we get to it someday.
A new type of engineer
My thinking changed completely, when Josefine joined Hyperganic in 2021. Here was a driven Aerospace engineer, who knew basic coding when she started. But more importantly who was eager to dive in head first and translate her engineering knowledge directly into algorithms. And, surprisingly, the requests she had for our Core team were very different. Instead of asking for high-level functions that did only one thing, she asked for access to low-level functions that she could work on top of.
And these requests were only a few. Fundamentally it was: give me a brush to paint with, and stop holding my hand.
Josefine’s original Aerospace rocket engine, printed in copper on an AMCM M4K industrial 3D printer in 80cm height.
Josefine represents a new type of engineer. Someone who is eager to rethink how engineering should be done in the 21st century. She was appalled by the amount of repetitive work she had to do in her previous career in Formula One. And she is not alone.— I have since met many engineers who want to work on the abstract level of code instead of manually pushing the buttons of a glorified three-dimensional sketching application (CAD).
Engineers who say, stop dumbing down tools to graphical interfaces, and wires and icons. Give me a way to build abstract computational models of complex machinery.
These are the humans who will pioneer Computational Engineering.
And for this new group of trailblazers, we needed a different approach.
RISC for PicoGK
Why would you build complex functionality into a software core, bogging down scores of C++ and assembly-language programmers with very specific requests, when you can provide a radically reduced set of functions instead. The higher-order functionality is then written by the domain experts — by the engineers themselves. Just like Hermann Hauser rationalized, when he decided the ARM hardware instructions should be simple and fast, and everything else can be done outside this verified and compact core.
Simple, fast, and robust clearly beats complex, slow, and fragile any day of the week.
Computational heat exchanger, based on LEAP 71’s compact open-source geometry kernel, PicoGK
When we had to choose the technology foundation for LEAP 71 this year, it was clear that thekernel would have to have the smallest instruction set imaginable.
Thanks to existing open-source projects like OpenVDB, I coded the first iteration of what became PicoGK in a few weeks. On top of the core C++ part, I built the main framework in C#, which Josefine in turn based the LEAP 71 Shape Kernel on. So like any good software architecture, the LEAP 71 tech stack has tiers. A small execution layer at the bottom, which is tiny and robust. Above it you have higher level functionality that gets increasingly abstract in every layer. At the lowest tier you interact with the voxel field, you paint matter into space. At the top, at the level of the Computational Engineering Model, you specify a rocket engine using parameters like fuel type and thrust level. But it always goes down to the validated core to create robust and unbreakable geometry.
And, since PicoGK is open-source, you can always see what is going on.
We tested the tiny (pico) geometry kernel, PicoGK, for a few months, creating all the objects you see on the LEAP 71 website (and on our Instagram channel).
Now it’s open-source for everyone to build upon.
Let’s hope PicoGK, or one of its successors, will one day be a ubiquitous, as the reduced instruction set architectures in today’s computing devices.
Head over to X to discuss.
