2022 was IRL very busy. My family bought a new house, caught COVID, moved house, went skiing and then renovated a house. I started jokingly saying that my hobby at the moment was "Real Estate" because it’s what I spent a lot of my spare time on. In fact, like a lot of people since 2020 I’ve been less social, I’ve never been big on "new years' resolutions" but I would like to be more social in 2023. But I would also like to make time for other hobbies including Plasma.

I hadn’t completely left Plasma alone, but not working on it much also led to my motivation slipping. It’s easy to think of it as an obligation that I promised to do rather than something I want to do, and so I want to remind myself why I want to make Plasma.

This is why I like to write down my vision for Plasma, while this communicates my vision to others mostly it reminds myself what I was thinking.

I started Plasma over seven years ago. In fact five years ago I wrote a similar post, bemoaning how long this is taking. I want to remind myself (but also anyone reading) that I’m doing this in my spare time and the main point of this post is that spare time has not been abundant.

I worked on Mercury for over 9 years in total: 1.5 years during my Honours project (part time), 4 years for my Ph.D. 2 years for Mission Critical IT and just over 2 years for YesLogic. My work on Plasma has almost been as long, just less intensive and different.

So for 2023 I thought it’d be nice to nerd snipe myself and help build my interest and motivation. So some people were talking about virtual machine implementations on the https://proglangdesign.net/ discord server and comparing their performance. I gave Plasma a shot at solving Ackermann’s function for ack(3, 12), it crashed. After adding more stack space and re-compiling, it crashed some more. Plenty more stack space later it ran and completed in 45 seconds.

Let’s put that in perspective:

Previously when I’ve checked Plasma’s performance (so far only on micro-benchmarks) I’ve been able to claim "It’s faster than Python". Which doesn’t sound like a lot but "If Python is fast enough for your needs, then Plasma is also fast enough" is something concrete that people can use. It is faster than Python, at least version 3.8.10, so that’s still true. A friend of mine, fox, tested it with python 3.11 which was closer to Plasma’s performance. Also both Plasma and Python crashed until given larger stacks.

I expected it to be faster than Ruby, but last time I used Ruby was before the 1.8-1.9 era when I think they switched to a faster implementation. I know I haven’t attempted to optimise Plasma at all other than adding tail calls and basic simplification, so I know "I can do better".

Fox also noticed that Plasma is slower when its runtime is built with clang rather than GCC. The results above use GCC.

I tested the naive implementation of each Ackermann’s function for each language as shown on Rosetta Code. Some where modified to request a larger stack size.

It’s safe to say that I’ve managed to nerdsnipe myself. I’ve been refactoring the interpreter and considering faster implementations. Yes Plasma is interpreted, that’s just the first version. We can write native code generators later.

I’m also been considering what features we’ll need in the runtime & bytecode representation to support concurrency and parallelism. I think that quite a lot of the bytecode format will need to change, and was going to do that today but I built a frame for some bird-netting in the garden instead, because home maintenance stuff never ends!

I’ve updated the roadmap to move concurrency higher in the priority list to reflect this new focus.

Fox contacted me with information about Python (since I hadn’t given it enough stack space) and also ran some tests on Plasma. I’ve updated the last section with the new information including the Python rows in the table, the updated analysis WRT Python and the observation that Plasma is slower when compiled with Clang.