2024-06-05

• Nice morning in LA. Wonderful latte and reading session. Decided to focus on fighting distraction during reading. Set a timer for 25 min and tried to see how long I could go without picking up my phone. Made it 15 mins 😕 but only suffered one lapse. Glad I made the attempt to test myself.
  
• oh yeah, wanted to publish this wonderful thing that happened. Yesterday dinner was awesome. Went to Costco and got myself a couple slices of pepperoni pizza. Listened to this history book about the Italian Renaissance. Was a wonderful section about the lives of Raphael and Michelangelo. The sun was going down over LA. The whole thing cost $5. It was perfect.
  
• Was reading more of Systems Performance. Enjoying it well enough. But I’m realizing that it’s moving into territory that is a bit too abstract. I wish I could easily make the ideas/information more concrete, mainly through sample exercises. The section I read today was about profiling off-cpu threads. This contrasts with on-cpu profiling in that the off version is a measure of what causes the thread to wait (e.g. disk or network i/o, blocked on acquiring a lock, etc) where the on version measures which part of the program is using cpu cycles the most. Together, these two types of profiles (usually shown in flame graphs), give a good idea of how the thread transitions between various states it can be in and what perf improvements are available. What I would love are some highly practical examples. Like maybe a Docker container I can load up that has a sample application that you can run in various configurations and then a set of commands are provided that walk you through a perf analysis using both types of profiles. That would be excellent. I recall something at the beginning of the book about there being samples? Not totally sure. But will see if I can track some down so that this info gets out of the world of purely abstract concepts and becomes something I’m familiar with on a more physical level.
  
• Saw this on HN today. Love this kind of thing. Identifying important information (exposed secrets) by figuring out what it is correlated with (entropy) and separating it from irrelevant things on that basis. Often involves looking at a thing from a new perspective. In this case, lines in a codebase are not just instructions for a program, but also little blobs of entropy, and the biggest blobs could be very interesting.
  
• Listening to this Dwarkesh podcast rn. It’s an interesting thing. Two pretty smart, sophisticated guys talking about AI stuff. At one point, the guest (Leopold Aschenbrenner) talked about how the trendline for AI electricity use is that in some small number of years, AI compute will use 20% of electricity production (exact year of 2027 iirc, but I’m not gonna go back and verify, the vibes of 2027 are directionally correct). This is a pretty wild prediction, among several in the podcast. Interesting to hear how smart people get to these kinds of things. Of course, it triggers some rationalist skepticism. Basically, if you find yourself making an absurd prediction on a small timescale, you should pause and assess whether there’s some factor you don’t see that will keep things from going totally bonkers. Like if you find yourself with a bonkers prediction, it becomes much more likely that you are missing some important factor in your model vs you actually being correct. Unfortunately, these guys in the podcast didn’t spend much time assessing potential gaps in their models. Admittedly, it’s more fun and exciting to talk about how AI might destroy the US government or CCP vs asking something like “my model predicts 20% of US electricity production will shift to data centers, why might that not pan out?” To me, both are fun and interesting, would be great for them to both get reasonable airtime.
  
• Continuing in my journey writing Python backend code. Splitting out a large-ish project into pieces. Decided on a “services” model deployed as a monolith. The nice thing about “services” is that they create really strong separation of concerns in the codebase. You define really clear contracts via methods and input/output data types, which makes everything quite testable. But there are drawbacks, of course. I do struggle now with the N+1 queries problem, and I’m more concerned about performance issues if/when things start to scale. I guess the good news is that I have plenty of vertical scaling left to use (backing store is currently on a $5/month VPS lol) and then if/when it ever becomes time to go beyond a single-machine for persistence, the service boundaries will at least make the process easier. Been pretty challenging, though, all said. Lots more tests. Lots more class/interface design questions. Lots more non-trivial stuff that I’m not super familiar with in Python. But overall, I have come away very happy with Python as an environment for writing this kind of code.

---

---

---