UPDATE: I have made a video version of this article.

Background

The term suckless software has come out of the suckless organization. The suckless organization is a network of people centered around suckless.org, its mailing list, and the founder of the suckless organization Anselm R. Garbe. Anselm has explained why he started the suckless organization in an episode of the FLOSS weekly podcast. I recommend this podcast to anyone who wants to get insight into the suckless organization from Anselm’s point of view. Anselm is also the author of a popular tiling window manager called dwm. The suckless organization publishes and maintains several software programs and has a philosophy document explaining its core beliefs related to software.

Properties of Suckless Software

First, it makes sense to call the software published and promoted by the suckless organization suckless software. It is a very subjective matter what a suckless computer program is. However, based on the texts and programs published by the suckless organization, one can distill a few properties that a program should have to be called suckless. I would summarize the necessary properties of a suckless program like this:

• The Program follows the UNIX philosophy for software design. The program should focus on doing one task and doing that task well.
• The number of features should be limited, and features that can easily be accomplished in some other way (e.g., by piping the output of a program to some UNIX utility) should be excluded.
• The program’s source code should be as easy to understand as possible. Few lines of code usually mean that it is easy to understand what the program is doing.
• The program should also keep things simple and easy to understand regarding the build and configuration process. Typically suckless programs are configured by editing a source code file (commonly named config.h if it is a program written in C).
• It is okay to depend on other software and libraries if this makes things simpler, easier to understand, and maintain. However, it is positive if the program has few dependencies, making it less likely to break due to a change in some dependency.
• A suckless program’s user interface should primarily focus on technically skilled users such as programmers. The creator should take great care to make the user interface efficient for experienced users, but user-friendliness for users who don’t have a software engineering background is less important.
• Last but not least, the source code of a suckless program should be freely available, and modifications should be permitted.

Programs that don’t follow the properties outlined above might suck (be bad) because they are/have:

• Difficult to use, extend and maintain due to the complexity of the code and the build system.
• Hard to combine with other programs to extend functionality.
• Have many bugs due to unnecessary complexity.
• Easily break if external dependencies change or have bugs.

Example of a Suckless Program

An example of a suckless program is a slide show presentation program called Sent. Sent takes a plain text file as input and displays a window with slides derived from the text file. An empty line signal that a new slide begins. A slide consists entirely of unformatted text or an image. Slides are automatically scaled so the content fits the window. To write a text slide, one writes text, and to create an image slide, one writes a line with the format @path_to_image_file.png. Sent’s source code is approximately 1000 lines of C code, including whitespaces and comments. One can contrast this with LibreOffice’s roughly 10 million lines of code. LibreOffice is an office suite containing a presentation tool, so it can do more than just presentations. The comparison is thus not fair, but since Sent’s code size is only about 0.01% of LibreOffice’s code size, it still shows a big difference in complexity. This difference means a lot since a programmer could easily fully understand the code of Sent in less than a day, while it would probably take a year or more to understand LibreOffice’s source code to a similar depth.

The program Sent can be so simple as it leverages the fact that many experienced computer users are confident and efficient at editing text in at least one text editor and one image editor. With such external tools, Sent can provide similar functionality as LibreOffice’s presentation tool. Additionally, Sent is more user-friendly and flexible than LibreOffice’s presentation in several ways. Users can edit the Sent presentation in Emacs, Vim, GEdit, or whatever text editor they like. One can create images for image slides in Gimp, Krita, Kolourpaint, Incskape, or whatever fits the particular picture or user. Last but not least, plain text files are straightforward to manipulate programmatically. For example, if a user wants to insert a series of slides for animation or something similar. Sent and LibreOffice are open source, but due to the complexity of LibreOffice’s source code and build process, a user is far more likely to be able to improve or fix a bug in Sent than in LibreOffice. Sent has the suckless properties listed above, and LibreOffice presentation doesn’t.

Why Do I Like Suckless Software

I like Suckless programs because they give me a sense of control. Furthermore, they also give me the power to combine tools to create new tools that I also have a sense of control over. Since I create these new tools, I can also make them fit precisely how I prefer to do things. Let me explain why suckless software gives me control and power. By being small and easy to change, I can fully understand suckless programs, fix bugs, or add extra functionality by myself. Therefore, I can be in control of suckless programs without depending on an external entity. As suckless programs are designed to be easily combined with other software, it is easy to combine them to create new efficient tools. For example, one can easily combine dwm, dmenu, xdotool, and a text editor to create a text template system that works across all applications.

Still, not all applications can easily have all of the suckless properties. Take advanced 3D modeling software like Blender, for example. This type of software requires sufficiently advanced algorithms and data structures so that they are not easy to understand or modify. However, after spending hundreds of hours with the program, a professional 3D designer can still feel in control of Blender and know its most important functionality. However, many other types of programs, like keeping bookmarks synchronized across computers, can be made much simpler and easier to understand than most bookmarking applications by combining several suckless programs as Luke Smith explains in one of his videos. So even though suckless programs might not be the best for every computing task, one can embrace the suckless way to increase the sense of control and power.

Suckless Software Might Improve Your Physical and Mental Health

Several academic studies suggest that the sense of control is correlated with several positive mental and physical health measurements. I have argued in this article that suckless programs give you a better sense of control. Given that this is true, it is reasonable to believe that using suckless programs might improve your mental and physical health. Given that one takes the research on the sense of control seriously, it is worth contemplating if computer programs that are buggy and overly complex are harmful to your health. Based on my own experience and the people I have seen around me, I think the answer to this is yes.

My current idea for this blog is to primarily write about the following topics:

• Programming - This is my primary source of income, and I spend a substantial amount of my free time trying to become a better programmer.
• Software - I also plan to write about the software programs I use and like. I mainly use open-source software. I have also started to use more software that follows the suckless spirit in the last couple of years. Suckless programs generally try to do one thing and do that thing well and make it easy to combine computer programs with other programs to perform more advanced tasks. I believe that although suckless programs might often have a higher barrier to entry than other programs, they usually give you greater flexibility and a sense of control once you know them well.
• Computer science - I think this is an interesting field with many fascinating ideas and insights. I hold a Ph.D. degree, and the main subject of my dissertation was concurrent data structures, so I might write some posts that are related to that subject.
• Physical exercise - This is something that I think a lot of people in modern society do far too little of (programmers are not an exception). This video, which my brother created, explains why physical exercise is generally a good thing. Physical exercise and sports have been a part of my life since I was very young. I competed in cross-country skiing at a pretty high level in Sweden until I was 20 years old. After that, there have been many periods when I have done too little exercise, but I have always started to do more again when I have realized that I feel much better physically and mentally if I exercise a couple of days per week.
• Life balance - Getting a healthy balance between family, work, physical exercise, friends, and hobbies is far from trivial in modern developed societies. I believe this is something that has got increasingly difficult with an increased rate of technological and social change. I have struggled to get a good balance and am still trying to improve.

I think the list above should give you a good idea for what this blog will be about. I hope that the blog will be helpful for you even though this is not its primary purpose, as I have described above.

The scalability of ETS tables of type ordered_set with the write_concurrency option is substantially better in Erlang/OTP 22 than earlier releases. In some extreme cases, you can expect more than 100 times better throughput in Erlang/OTP 22 compared to Erlang/OTP 21. The cause of this improvement is a new data structure called the contention adapting search tree (CA tree for short). This blog post will give you insights into how the CA tree works and show you benchmark results comparing the performance of ETS ordered_set tables in OTP 21 and OTP 22.

Try it Out!

This escript makes it convenient for you to try the new ordered_set implementation on your own machine with Erlang/OTP 22+ installed.

The escript measures the time it takes for P Erlang processes to insert N integers into an ordered_set ETS table, where P and N are parameters to the escript. The CA tree is only utilized when the ETS table options ordred_set and {write_concurrency, true} are active. One can, therefore, easily compare the new data structure’s performance with the old one (an AVL tree protected by a single readers-writer lock). The write_concurrency option had no effect on ordered_set tables before the release of Erlang/OTP 22.

I got the following results when I ran the escript on my laptop with two cores (Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz):

$ escript insert_disjoint_ranges.erl old 1 10000000
Time: 3.352332 seconds
$ escript insert_disjoint_ranges.erl old 2 10000000
Time: 3.961732 seconds
$ escript insert_disjoint_ranges.erl old 4 10000000
Time: 6.382199 seconds
$ escript insert_disjoint_ranges.erl new 1 10000000
Time: 3.832119 seconds
$ escript insert_disjoint_ranges.erl new 2 10000000
Time: 2.109476 seconds
$ escript insert_disjoint_ranges.erl new 4 10000000
Time: 1.66509 seconds

We see that in this particular benchmark, the CA tree has superior scalability to the old data structure. The benchmark ran about twice as fast with the new data structure and four processes as with the old data structure and one process (remember that the machine only has two cores). We will look at the performance and scalability of the new CA tree-based implementation in greater detail later after describing how the CA tree works.

The Contention Adapting Search Tree in a Nutshell

The key feature that distinguishes the CA tree from other concurrent data structures is that the CA tree dynamically changes its synchronization granularity based on how much contention is detected inside the data structure. This way, the CA tree can avoid the performance and memory overheads that come from using many unnecessary locks without sacrificing performance when many operations happen in parallel. For example, let us imagine a scenario where the CA tree is initially populated from many threads in parallel, and then it is only used from a single thread. In this scenario, the CA tree will adapt to use fine-grained synchronization in the population phase (when fine-grained synchronization reduces contention). The CA tree will then change to use coarse-grained synchronization in the single-threaded phase (when coarse-grained synchronization reduces the locking and memory overheads).

The structure of a CA tree is illustrated in the following picture:

The actual items stored in the CA tree are located in sequential data structures in the bottom layer. These sequential data structures are protected by the locks in the base nodes in the middle layer. The base node locks have counters associated with them. The counter of a base node lock is increased when contention is detected in the base node lock and decreased when no such contention is detected. The value of this base node lock counter decides if a split or a join should happen after an operation has been performed in a base node. The routing nodes at the top of the picture above form a binary search tree that directs the search for a particular item. A routing node also contains a lock and a flag. These are used when joining base nodes. The details of how splitting and joining work will not be described in this article, but the interested reader can find a detailed description in this CA tree paper (preprint PDF). We will now illustrate how the CA tree changes its synchronization granularity by going through an example:

1. Initially, a CA tree only consists of a single base node with a sequential data structure as is depicted in the picture below:

   

2. If parallel threads access the CA tree, the value of a base node’s counter may eventually reach the threshold that indicates that the base node should be split. A base node split divides the items in a base node between two new base nodes and replaces the original base node with a routing node where the two new base nodes are rooted. The following picture shows the CA tree after the base node pointed to by the tree’s root has been split:

   

3. The process of base node splitting will continue as long as there is enough contention in base node locks or until the max depth of the routing layer is reached. The following picture shows how the CA tree looks like after another split:

   

4. The synchronization granularity may differ in different parts of a CA tree if, for example, a particular part of a CA tree is accessed more frequently in parallel than the rest. The following picture shows the CA tree after yet another split:

   

5. The following picture shows the CA tree after the forth split:

   

6. The following picture shows the CA tree after the fifth split:

   

7. Two base nodes holding adjacent ranges of items can be joined. Such a join will be triggered after an operation sees that a base node counter’s value is below a certain threshold. Remember that a base node’s counter is decreased if a thread does not experience contention when acquiring the base node’s lock.

   

8. As you might have noticed from the illustrations above, splitting and joining results in that old base nodes and routing nodes gets spliced-out from the tree. The memory that these nodes occupy needs to be reclaimed, but this can not happen directly after they have got spliced-out as some threads might still be reading them. The Erlang run-time system has a mechanism called delayed dealloc, which the ETS CA tree implementation uses to reclaim these nodes safely.

Benchmark

The performance of the new CA tree-based ETS ordered_set implementation has been evaluated in a benchmark that measures the throughput (operations per second) in many scenarios. The benchmark lets a configurable number of Erlang processes perform a configurable distribution of operations on a single ETS table. The curious reader can find the source code of the benchmark in the test suite for ETS.

The following figures show results from this benchmark on a machine with two Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz (32 cores in total with hyper-threading). The average set size in all scenarios was about 500K. More details about the benchmark machine and configuration can be found on this page.

We see that the throughput of the CA tree-based ordered_set improves when we add cores all the way up to 64 cores, while the old implementation’s throughput often gets worse when more processes are added. The old implementation’s write operations are serialized as the data structure is protected by a single readers-writer lock. The slowdown of the old version when adding more cores is caused by increased communication overhead when more cores try to acquire the same lock and by the fact that the competing cores frequently invalidate each other’s cache lines.

Further Reading

The following paper describes the CA tree and some optimizations in much more detail than this blog post. The paper also includes an experimental comparison with related data structures.

• A Contention Adapting Approach to Concurrent Ordered Sets (preprint). Journal of Parallel and Distributed Computing, 2018. Konstantinos Sagonas and Kjell Winblad

There is also a lock-free variant of the CA tree that is described in the following paper. The lock-free CA tree uses immutable data structures in its base nodes to substantially reduce the amount of time range queries, and similar operations can conflict with other operations.

• Lock-free Contention Adapting Search Trees (preprint). In the proceedings of the 30th Symposium on Parallelism in Algorithms and Architectures (SPAA 2018). Kjell Winblad, Konstantinos Sagonas, and Bengt Jonsson.

The following paper, which discusses and evaluates a prototypical CA tree implementation for ETS, was the first CA tree-related paper.

• More Scalable Ordered Set for ETS Using Adaptation (preprint). In Thirteenth ACM SIGPLAN workshop on Erlang (2014). Konstantinos Sagonas and Kjell Winblad

It might also be interesting to look at the author’s Ph.D. thesis if you want to get more links to related work or want to know more about the motivation for concurrent data structures that adapt to contention.

Conclusion

The Erlang/OTP 22 release introduced a new ETS ordered_set implementation that is active when the write_concurrency option is turned on. This data structure (a contention adapting search tree) has superior scalability to the old data structure in many different scenarios and a design that gives it excellent performance in a variety of scenarios that benefit from different synchronization granularities.