Aesthetics of single threading

Every one of your examples are things that I find really enjoyable. As someone who is a terribly scatter brained procrastinator, the 6AM deadline is clarifying. Realizing at 11:30pm that I haven't started the essay is (or was, long ago) a jolt of wakefulness and focus. The time between 11:45pm and 5:45am flies by in a blur. Driving 1000mi in a day--18+hr of focus. Keep the speed high enough above the speed limit to make decent time over ground but avoid the risk of a sneaky traffic cop. Take advantage of the lulls in traffic, long sight lines (or tight, windy sections) to increase your average speed. Eat just enough to not lose energy but not enough to not be hungry--a little hunger sharpens focus. Drink enough water to not be totally dehydrated, but little enough that your bathroom breaks coincide with fuel stops. Pager goes off at 3AM. Critical alert, connection pools full, database CPU 100%, p99 response times equal to the configured timeout, circuit breakers tripping. The urgency gives life some meaning. You were groggy and sleepy 1min ago and now you're blasted wide awake, throttle firewalled. Don't threaten me with a good time ;)

>" Sometimes when we think we are 'multitasking,' we're just looking for ways to avoid the problem."

Which can be correct course of action. If I stuck trying to figure out how to solve some hard problem it is very good ide to switch for a while and magically the solution comes back later on since brain still manages to do something in background. Alternatively if I have to do whole lot of monotonous non rewarding work for whatever reason I would go nuts if I try to finish it in one step (considering it is long enough)

I've read that the (first?) preemptive multi-tasking was implemented in Apollo lander, to leave more processing power to more critical sensors. No one though of it in such general terms though.

I have a 16 core M4 Max and running at a fraction of the potential maximum speed just isn't very optimal on modern CPUs like that.

Threading is hard, especially if they share a lot of state. Memory management with multiple threads sharing stuff is hard and ideally minimized. What is optimal very much depends on the type of workload as well. Not all workloads are IO dependent, or require sharing a lot of state.

Using threads for blocking IO on server requests was popular 20 years ago in e.g. Java. But these days non blocking IO is preferred both for single and multi threaded systems. E.g. Elasticsearch uses threading and non blocking IO across CPU cores and cluster nodes to provide horizontal scalability for indexing. It tends to stick to just one indexing thread per CPU core of course. But it has additional thread pools and generally more threads than CPU cores in total.

A lot of workloads where the CPU is the bottleneck that have some IO benefit from threading by letting other threads progress while one is waiting for IO. And if the amount of context switching can be limited, that can be OK. For loads that are embarrassingly parallel with little or no IO and very limited context sharing, a 1 thread per CPU core tends to be the most optimal. It's really when you start having more than threads than cores that context switching becomes a factor. What's optimal there is very much dependent on how much shared state there is and whether you are IO or CPU limited.

In general, concurrency and parallelism tend to be harder in languages that predate when threading and multi core CPUs were common and lack good primitives for this. Python only recently started addressing the GIL obstacle and a big motivation for creating Rust was just how hard doing this stuff is in C/C++ without creating a lot of dead locks, crash bugs, and security issues. It's not impossible with the right frameworks, a lot of skill and discipline of course. But Rust is getting a well deserved reputation for being very optimal and safe for this kind of thing. Likewise functional languages like Elixir are more naturally suited for running on systems with lots of CPUs and threads.

Event loops are great but composition is hard. This is due to the fact that the OS (e.g. Linux) provides event loops with custom event types (eventfd()) but the performance is worse than if you built it yourself.

The bad performance leads to a proliferation of everyone building their own event loops, which don't mesh together, which in turn leads to people standardizing on large async frameworks like tokio.

I think this is a bit like a factory:

- you get a queue as input (a belt);

- you process it;

- you output a queue (also a belt);

So you're doing one thing, over and over, synchronously, blocking in between.

then you tell the kid to hold on, i’m making a sandwich give me a minute and teach them to wait a minute, tell your partner to sit together for breakfast or lunch to go over complicated thing, and don’t answer the phone, let the machine get it if you’re doing something. if it’s important right here, right now, then they can call back or you can call back after you’re done doing the thing.

modern society teaches us to be available to everything all at the same time, when we really need to learn how to slow down and refocus our thoughts on one thing at a time.

Studies have shown again and again how detrimental "multitasking" is to our cognitive abilities, which is the author's point.

It's just a metaphor.

I loved reading it a little bit at the start, then I switched to reading a little bit in the middle and then continued from were I was at the start.

YMMV.