Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Posts on Made of Bugs
How should we think about error-handling in concurrent programs? In single-threaded programs, we’ve mostly converged on a standard pattern, with a diverse zoo of implementations and concrete patterns. When an error occurs, it is propagated up the stack until we find a stack frame which is prepared to handle it. As we do so, we unwind the stack frames in-order, giving each frame the opportunity to clean up or destroy resources as appropriate.
For a while now, I’ve been fascinated by Z3 and by SMT solving more broadly. While on pat leave recently, I was reminded of the existence of regular-expression crossword puzzles, and allowed myself to get nerdsniped by writing a Z3-backed solver. I expected to spend perhaps an afternoon cranking out a quick solver; I ended up getting sucked into understanding and debugging Z3 performance, and learning far more about Z3 and about SMT than I expected.
While investigating the performance of the new Python 3.14 tail-calling interpreter, I learned (via this very informative comment from Sam Gross) new (to me) piece of performance trivia: Modern CPUs mostly no longer struggle to predict the bytecode-dispatch indirect jump inside a “conventional” bytecode interpreter loop. In steady-state, assuming the bytecode itself is reasonable stable, modern CPUs achieve very high accuracy predicting the dispatch, even for “vanilla” while / switch-style interpreter loops1!
About a month ago, the CPython project merged a new implementation strategy for their bytecode interpreter. The initial headline results were very impressive, showing a 10-15% performance improvement on average across a wide range of benchmarks across a variety of platforms. Unfortunately, as I will document in this post, these impressive performance gains turned out to be primarily due to inadvertently working around a regression in LLVM 19. When benchmarked against a better baseline (such GCC, clang-18, or LLVM 19 with certain tuning flags), the performance gain drops to 1-5% or so depending on the exact setup.
Earlier this month, I used Claude to port (parts of) an Emacs package into Rust, shrinking the execution time by a factor of 1000 or more (in one concrete case: from 90s to about 15ms). This is a variety of yak-shave that I do somewhat routinely, both professionally and in service of my personal computing environment. However, this time, Claude was able to execute substantially the entire project under my supervision without me writing almost-any lines of code, speeding up the project substantially compared to doing it by hand.
More in technology
We keep reading scary reports of swarms of AI agents breaking into computer systems and doing other untoward and perhaps illegal things. To what degree do these agents influence each other? And is there anything we can learn from human behavior that would help mitigate these problems? That’s the heady backstory behind [episode 46](https://www.tractionheroes.com/2439976/episodes/19905275-tribal-psychology) of [_Traction Heroes_](https://www.tractionheroes.com/). Harry brought a short reading from David McRaney’s [_How Minds Change_](https://www.amazon.com/How-Minds-Change-Surprising-Persuasion-ebook/dp/B093R2CP2V/) about the impact of our groups on our thinking and behavior. Here’s the key fragment: > the latest evidence coming out of social science is clear. Humans value being good members of their groups much more than they value being right. So much so that as long as the group satisfies those needs, we will choose to be wrong if it keeps us in good standing with our peers. We never lack evidence for this: just tune in to the news. People do stupid things to remain in good standing with their milieu _all the time_. (I know I have!) And apparently, so do AIs. (Although as I pointed out in the show, we mustn’t anthropomorphize technology.) But more importantly, knowing about the perils of tribal psychology can help us be more effective when working in groups — and therefore, to gain traction. [_Traction Heroes episode 46: Tribal Psychology_](https://www.tractionheroes.com/2439976/episodes/19905275-tribal-psychology)
There's a chance, slim as it might be, that things won't go the way the've gone the last 30 years with digitization the moving to rental models for everyhing.
Three years ago, I bought an Asus laptop, specifically the Zenbook Pro 17. It's a powerful machine and works just fine for my needs, but it had one problem that made me want to either return it or throw it out the window. I would work on projects for hours on end and close the lid when I was done. I haven't manually shut down a computer in more than 10 years. I only do so after a forced update or during a debugging session. So I would close the lid, and a couple of hours later I would open it back up. Instead of waking from sleep, the computer would start from scratch as if it had been turned off and the battery was nearly dead. That meant everything I had open was closed. I'm lucky that most of the applications I run can restore a previous session, but it was extremely annoying. I had a similar issue with my previous Asus, and I had blamed Windows for it. The computer often woke from sleep just so Microsoft could perform an update, which used up all my battery. Sometimes I would open my backpack to find a dead laptop that was warm to the touch. I've written this blog post at least five times. Each time I thought I had solved the issue, but then it came back. This time, though, I think I have finally resolved it. So if you have an Asus laptop running Windows and you experience this very annoying issue, you are not alone. In my case, the culprit was the Wi-Fi adapter, specifically the MediaTek Wi-Fi 6E MT7922. The Solution On Windows: Open Device Manager. Expand Network adapters. Right-click the MediaTek device and click Properties. Click the Advanced tab. In the Property box, select Power Saving. In the Value field, select Disabled. That's it. After three years of annoying restarts, this finally solved my problem. Now let me explain what was going on. What Was Happening (based on Windows Event Viewer) When the laptop lid is closed, Windows initiates "Modern Standby." In this state, the screen turns off to save power, but the system remains partially active to maintain background network connectivity. Shortly after, Windows attempts to transition into a deeper low-power state and disconnects the network adapter to conserve battery. However, the MediaTek Wi-Fi driver (mtkwlex) fails to handle this low-power transition properly. About a minute later, it generates Event ID 1033 errors referencing a network device path (specifically \Device\NDMP3 in my logs). Because the driver's error message resource is missing or corrupted, Windows Event Viewer cannot interpret the error and displays a generic warning instead: "The description for Event ID 1033 from source mtkwlex cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted..." Because the Wi-Fi driver fails to sleep, it keeps the system partially awake. This causes abnormal background battery drain and heat buildup, which is exacerbated when the laptop is in an enclosed space like a bag. In response to this abnormal drain, Windows triggers Event 507: "Austerity Battery Drain Budget Exceeded." It's important to note that this event is Windows intentionally waking the laptop up to prevent the battery from dying completely. However, because the Wi-Fi driver is already in a crashed or unstable kernel state, the system fails to recover from this forced wake-up. The result is a silent system crash or thermal shutdown, followed by Event 12 ("The operating system started"), which confirms the laptop rebooted. The Result With the fix in place, the Wi-Fi device no longer attempts to enter its power-saving sleep mode, so it never crashes. The ultimate solution would be a fixed MT7922 driver, but try as I might, I haven't been able to find one online. It's been three weeks so far, and I've been able to resume my work without coming back to a crashed computer. I hope this helps someone else.
Associate Professor Cathy Wu uses reinforcement learning to help map out improvements to transportation and other multifaceted systems.
