Examples Templates Store Pricing Docs Turbo CSS Blog Boomla WishList Introducing Turbo UI Named buckets Turbo CSS is Tailwind CSS on steroids Introducing Turbo CSS, the most advanced web-design language Calculate how much storage you use Better login system Collaboration settings Filesystem and Database are not cutting the problem space right What I'm working on 64bit File node IDs New how-to videos Creating buttons gets easier Introducing reusable components HTTPS by default Introducing the Boomla Theme CDN for faster pageloads Write your own website builder on top of Boomla On On composition Shared admin access A fresh config editor Building a multi-purpose theme A filesystem to replace your CMS New file link type: scope Mobile editing support Inline file wrapping changed Package sandboxing New PHP-like JavaScript engine [sjs-4e] Send emails to the website owner New JavaScript engine [sjs-4] A better editing experience New email service provider Glossary and other changes New panel changes Improved registration flow Boomla goes multiplayer Using local dev tools Why Boomla doesn't need Git File Panel Let's build a community Automatic updates Improved sjs-3 API New Frontend CSS modules Work offline with Boomla Faster page loads via caching Drag & drop supercharged Supporting CommonJS modulesĀ  Paranoid about loosing data IDE usability improvements Simple App install flow Meetups in Budapest Goodbye broken links Flow control from user space Customizing apps Contextmenu support for apps Deprecating the .Class file Hello Changelog Embedding 3rd party plugins Introducing Tools Installing apps just got amazing Public beta Host on our servers Simple deploy with push/pull Version Control for the Web 350M files on a 1TB disk 2 weeks in review
Control Panel

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.


Cheers,

you can follow me on Twitter