On On composition

2020-01-20

I came across a brilliant essay titled On composition by Shalabh Chaturvedi. He is wondering about the composition barriers laid out by the OS we use and how it forces code duplication and thereby an extremely inefficient use of our programming capacity. He mentions how he has to reimplement the sort function if he is writing a program in Java or Python, even though Unix has a built-in sort command. It totally resonated with me, I have to chip in.

He talks about interfaces, that our functions need to fit like Lego blocks in order to be callable by one another, which is spot on. There is another important aspect though.

Latency.

If you call a function that was implemented within your language, it will occur a significantly lower overhead than executing a Unix command. But how much? I did a little benchmark in Go on adding two numbers.

Go function call to add 2 numbers: 3ns.
Executing a Linux process that adds 2 numbers: 1800000ns.

It's a million times faster to call a function than to run a process.

If we used them extensively, everything we do would be like a million times slower. Obviously, we can't possibly use them everywhere. We couldn't use them even if the Lego fitting problem would suddenly disappear.

An interesting question follows. What if we eliminated the process execution overhead? That would completely change the game. Now suddenly it would be feasible to execute code written in other languages. We could suddenly start to compose our programs in ways never possible before. We could start building skyscrapers.

That's precisely what I'm working on with the Boomla OS. It is optimizing the whole, not parts of the system.

So how long does it take to execute a process in Boomla? Well, that's not quite the right term, because Boomla doesn't have processes, it is built on functions instead. It's like processes never run in the background, they always return instead.

Functions are the new processes.

Adding 2 numbers by executing a Boomla program: 65000ns.

3ns, 65000ns, 1800000ns. Boomla can execute programs 27x faster than mainstream operating systems even though it is not heavily optimized yet. We can easily expect a 10x improvement at minimum, at which point we are at a 6us overhead.

Latency numbers aren't absolute though. What matters is the overhead in relative terms. Lowering the response time means you will need to reimplement less and less features in your own language.

Of course, we will still need to solve the Lego block issue. Boomla is also addressing that with its unique file concept, where files can not only store byte sequences but structured data. It is also memory indexed and transactional like databases, so you don't really need a database any more.

There are lots of databases out there that are optimized to their limits. Yet making a request to them within the same datacenter still costs me about 1ms. If I have to make 1000 requests sequentially, it will take 1000ms even if they can respond in zero time.

Boomla can talk to the integrated filesystem about 200x faster by eliminating the communication overhead. That's 5ms for 1000 requests.

It will be interesting to see how far this approach can take us.

Let's discuss on Reddit.