launchdaemon
R Tyler Croy 🦀The cost of computing matters.
I'm grateful for @bert_hubert 's fantastic presentation linked within 👇
https://brokenco.de/2025/07/09/write-more-efficient-code.html
HalvarFlake@rtyler @bert_hubert it's worth looking at Open telemetry and the OTel Profiling Agent in this context.
@HalvarFlake @bert_hubert I agree _something_ is needed :) We use Datadog's APM which has been delightful for smashing silly performance issues
ティージェーグレェ🎵 Everything counts in large amounts🎵 ーDepeche Mode, "Everything Counts"
When I was young, and naive, I thought that the end goal was to take "bloated" code (even if it were some binary generated by a ghastly [to me at the time, horrifically inefficient boiler plate code visible from a simple hex editor] C compiler) and hand optimize it, I don't think I was alone.
In more recent years, the XlogicX blog "Assembly is too high level" (e.g. https://xlogicx.net/Assembly_Is_Too_High-Level_-_Full_Offsets.html) gave me hope that perhaps some kept that goal alive!
The demo scene and "code golf" and "size coding" certainly still seem to care.
I attended the 20th anniversary of REcon last month and I am not sure if I met many birds of a feather who shared similar sentiments? At least one I think. That one was well worth the trip if nothing else.
Alas, it seems in 2025, there are far too few of us low level optimize minded sorts left, relative to all the slop being generated, "at scale".
The depressing reality is, SO MUCH good would come of simply re-writing egregiously inefficient interpreted language programs implemented in Python or Ruby or Perl etc. in something such as C, I don't even know where to begin.
Here's just one example, which took some janky Python OpenAI speech to text (which seemed to completely ignore prior art such as julius) that required GPUs and re-implemented it in not even the most elegant or most portable C, but still significantly better than the Python jank: https://github.com/ggml-org/whisper.cpp
Voila! No more GPUs required! Lamentably, still uses the training models that were probably created completely unethically (unlike the prior art of julius). But still, take the wins where you can get them?
In the article you linked, "In my day job we operate a number of web properties receiving billions of requests per month"
I guess that's a good starting point to consider efficiencies?
I am old enough that 1MHz CPUs were still considered luxuries that I needed to access at labs, not something I had at home. I had been coding for years, before my parents eventually got what was an IMHO insanely overpriced and shitty microcomputer and worse: wasteful with its 7MHz 16bit CPU, running an obscenely bad OS that couldn't even task swap, let alone multi-task.
To quote someone from another blog comment about 1980s DSP designs: "One day I, as a fresh college grad, expressed my amazement at the mathematical processing power of those DSPs, which was impressive back in 1989. His response? 'That just means you can make 20 million mistakes per second.'"
Still, it used to be a prerequisite for some, to have considered the perils of MFLOPs levels of bugs, before they were granted much in the way of a system with an uplink capable of "srs" bandwidth (SGI workstations for example, had 10Gigabit interconnects, in the 1990s; while most home users with modems were still struggling to contend with a reliable 56K connection. My first college as an undergrad had a 56K uplink for their entire campus, and my personal modem could devour approximately one quarter of that bandwidth!).
By around 2013 I helped with a patch a bug in BIND (CVE-2013-4854) that was being actively exploited. It's estimated that there are around a billion DNS packets on the Internet, an hour.
I've known folks who have patched bugs in TCP/IP stacks, so I am not at their levels, yet. Maybe someday? Doesn't feel like it, but you never know. Bugs are friggin everywhere.
Regardless, improving the low hanging fruit where and whenever possible, is a win! Rust isn't my first choice, but there are way worse choices in 2025; unfortunately, some of those worse choices are much more popular.
It is with some chagrin that in recent years, most of my code "contributions" openly, have been to a system implemented in TCL; which is so much slower than even Python and Ruby and Perl (let's say, conservatively, those three languages are on average around 60x slower than C; TCL? On average: 200x slower! Meanwhile, in the 1980s I was already optimizing asm and machine code on systems with nanosecond level timing considerations; contrast that with golang's "halt the world" best in class garbage collector which was measured in milliseconds last I checked? Many don't even seem to pay attention to such orders of magnitude of inefficiencies intrinsic to their language choices! To me, that is unconscionable.). I seem to be at the opposite end of where I once was in some regards, yet the impact to potential users is not insignificant; which is why I keep contributing to such things despite the inefficient implementation choices.
I still think refactoring/rewriting/re-implementing in lower level more efficient languages would be a huge win in terms of efficiency, and worthwhile. But maybe some of that can be automated to a degree?
It's dumbfounding to me that in the 21st century there are still so many companies that rely on what I would consider "time sharing" paradigms and pay for compute and bandwidth in ways that would have been obscenely expensive to the point of having bankrupted some past employers if they were not smarter about self hosting hardware and IXPs and peering (instead of relying on things such as AWS as alluded to in that writing or GCP or Azure and other, as bad, yet popular, alternatives in a day and age where economical libre/free open source hardware with CPUs measured in GHz exist in plurality and RAM in ranges of 8GB or more are being sold for mere hundreds of dollars, if that.).
But I guess, because it is profitable and easy for some to rely on centralized systems, rather than cultivate their own in house expertise? Such avarice and inefficiencies will continue to persist until more wise up?
Similarly, I am guessing it was very strategic that Micro$oft hired Guido van Rossum. It's not that Python is good. However, from a sophomoric perspective, there are a lot of fools, writing a lot of Python and a mint is being made to the detriment of the planet and all living beings who are cursed to be alive right now on it, in the process.
CC: @bert_hubert@eupolicy.social
When I was young, and naive, I thought that the end goal was to take "bloated" code (even if it were some binary generated by a ghastly [to me at the time, horrifically inefficient boiler plate code visible from a simple hex editor] C compiler) and hand optimize it, I don't think I was alone.
In more recent years, the XlogicX blog "Assembly is too high level" (e.g. https://xlogicx.net/Assembly_Is_Too_High-Level_-_Full_Offsets.html) gave me hope that perhaps some kept that goal alive!
The demo scene and "code golf" and "size coding" certainly still seem to care.
I attended the 20th anniversary of REcon last month and I am not sure if I met many birds of a feather who shared similar sentiments? At least one I think. That one was well worth the trip if nothing else.
Alas, it seems in 2025, there are far too few of us low level optimize minded sorts left, relative to all the slop being generated, "at scale".
The depressing reality is, SO MUCH good would come of simply re-writing egregiously inefficient interpreted language programs implemented in Python or Ruby or Perl etc. in something such as C, I don't even know where to begin.
Here's just one example, which took some janky Python OpenAI speech to text (which seemed to completely ignore prior art such as julius) that required GPUs and re-implemented it in not even the most elegant or most portable C, but still significantly better than the Python jank: https://github.com/ggml-org/whisper.cpp
Voila! No more GPUs required! Lamentably, still uses the training models that were probably created completely unethically (unlike the prior art of julius). But still, take the wins where you can get them?
In the article you linked, "In my day job we operate a number of web properties receiving billions of requests per month"
I guess that's a good starting point to consider efficiencies?
I am old enough that 1MHz CPUs were still considered luxuries that I needed to access at labs, not something I had at home. I had been coding for years, before my parents eventually got what was an IMHO insanely overpriced and shitty microcomputer and worse: wasteful with its 7MHz 16bit CPU, running an obscenely bad OS that couldn't even task swap, let alone multi-task.
To quote someone from another blog comment about 1980s DSP designs: "One day I, as a fresh college grad, expressed my amazement at the mathematical processing power of those DSPs, which was impressive back in 1989. His response? 'That just means you can make 20 million mistakes per second.'"
Still, it used to be a prerequisite for some, to have considered the perils of MFLOPs levels of bugs, before they were granted much in the way of a system with an uplink capable of "srs" bandwidth (SGI workstations for example, had 10Gigabit interconnects, in the 1990s; while most home users with modems were still struggling to contend with a reliable 56K connection. My first college as an undergrad had a 56K uplink for their entire campus, and my personal modem could devour approximately one quarter of that bandwidth!).
By around 2013 I helped with a patch a bug in BIND (CVE-2013-4854) that was being actively exploited. It's estimated that there are around a billion DNS packets on the Internet, an hour.
I've known folks who have patched bugs in TCP/IP stacks, so I am not at their levels, yet. Maybe someday? Doesn't feel like it, but you never know. Bugs are friggin everywhere.
Regardless, improving the low hanging fruit where and whenever possible, is a win! Rust isn't my first choice, but there are way worse choices in 2025; unfortunately, some of those worse choices are much more popular.
It is with some chagrin that in recent years, most of my code "contributions" openly, have been to a system implemented in TCL; which is so much slower than even Python and Ruby and Perl (let's say, conservatively, those three languages are on average around 60x slower than C; TCL? On average: 200x slower! Meanwhile, in the 1980s I was already optimizing asm and machine code on systems with nanosecond level timing considerations; contrast that with golang's "halt the world" best in class garbage collector which was measured in milliseconds last I checked? Many don't even seem to pay attention to such orders of magnitude of inefficiencies intrinsic to their language choices! To me, that is unconscionable.). I seem to be at the opposite end of where I once was in some regards, yet the impact to potential users is not insignificant; which is why I keep contributing to such things despite the inefficient implementation choices.
I still think refactoring/rewriting/re-implementing in lower level more efficient languages would be a huge win in terms of efficiency, and worthwhile. But maybe some of that can be automated to a degree?
It's dumbfounding to me that in the 21st century there are still so many companies that rely on what I would consider "time sharing" paradigms and pay for compute and bandwidth in ways that would have been obscenely expensive to the point of having bankrupted some past employers if they were not smarter about self hosting hardware and IXPs and peering (instead of relying on things such as AWS as alluded to in that writing or GCP or Azure and other, as bad, yet popular, alternatives in a day and age where economical libre/free open source hardware with CPUs measured in GHz exist in plurality and RAM in ranges of 8GB or more are being sold for mere hundreds of dollars, if that.).
But I guess, because it is profitable and easy for some to rely on centralized systems, rather than cultivate their own in house expertise? Such avarice and inefficiencies will continue to persist until more wise up?
Similarly, I am guessing it was very strategic that Micro$oft hired Guido van Rossum. It's not that Python is good. However, from a sophomoric perspective, there are a lot of fools, writing a lot of Python and a mint is being made to the detriment of the planet and all living beings who are cursed to be alive right now on it, in the process.
CC: @bert_hubert@eupolicy.social