A Project Manifest

Solo is a domain-specific programming language for manipulating arrays efficiently. Solo provides an effective shorthand for representing common SIMD (Single-Instruction Multiple-Data) operations as exposed by Intel x64 CPUs. A programmer already adept at SIMD programming can use Solo to write SIMD-based functions in a high-level and portable manner without losing any efficiency.

Solo’s primary usefulness comes from its ability to abstract block sizes: rather than forcing programmers to use specific SIMD instructions, which (in Intel x86) always operate on fixed-length arrays, Solo works with arrays of any length, and generates loops that use the appropriate SIMD instructions. The most difficult part of writing these loops by hand is sharing information between iterations; Solo automates this process, at the cost of having a limited set of operators.

I am working on Solo as part of university study. Most of my projects don’t get as far along as this has - I hope I manage to finish it off nicely.

Sitrep is a suite of utilities providing status bar information, each only being a few hundred lines of C. The goal of these utilities is to provide status bar information as efficiently as possible, relying on Linux-specific OS APIs (e.g. timerfd_create(2)) rather than shell scripts. I’m designing it for use in eww for my status bar, though its output can be customized easily.

The main goal I want these utilities to solve is event prediction: they should suspend execution until the moment when a change occurs, so that no CPU time is wasted. The date-time utility, for example, uses Linux’s timerfd system (see timerfd_create(2)) to synchronize outputting to the moment the minute changes. The battery utility uses udev notifications rather than checking periodically, as udev exposes notifications from the underlying hardware and they are as precise as possible.

This is very much a side project, but it’s an interesting exploration of the limitless possibilities of over-engineering. Most of these utilities could be replaced with single-line shell invocations, but they put so much effort into perfect, absolution precision that they become exciting to work on.

Ella is a Rust library providing a replacement for the standard Future APIs. Rather than using the Waker interface, which is unnecessarily difficult to understand, it provides a simple event passing system that is more obvious and efficient. It is generic enough to be used for e.g. GUI event notifications (e.g. as in GTK or the lower-level Wayland). It uses monomorphization rather than dynamic objects, giving the compiler more optimization opportunities.

Ella is part of a running streak of async-related projects. I started working with async by trying to introduce a nice concurrency system to C, before realizing that the language was too limited. I moved on to Rust, where I found that the Waker system embedded in the built-in Future interface was very difficult to work with. Firstly, Waker includes a raw trait object, and the compiler cannot inline any of its methods. Because Wakers are meant to be so generic, they almost always use dynamic allocation and thread-safety, even when it is unnecessary. I decided to rewrite Future so that events are passed to futures directly rather than through Wakers, and to introduce Executor as a distinct type so that futures can be generic over them.

I hope to use Ella as a basis for all my async-reliant Rust projects. I’m really excited to build an efficient io_uring-based standard library on top of it, and to implement an allocation-minimizing Wayland client library (the usual one for Rust, Smithay/wayland-rs, unnecessarily requires dynamic allocation and thread safety, like the libwayland C library).