Working Notes: a commonplace notebook for recording & exploring ideas.
Home. Site Map. Subscribe. More at expLog.
Like the set on HyGPT, starting a series of notes on software dynamics, queueing and hardware behavior that I hope to learn this year: I'll be categorizing these as Mechanical Sympathy.
Kicking off with notes from Understanding Software Dynamics by Richard Sites.
The book starts off with some classic advice: particularly around making Fermi estimates and understanding hardware, linking to Jeff Dean's talk on numbers everyone must know.
The second chapter talks through estimating cpu utilization -- in a way that can be reasoned about. There are so many potential ways that the compiler, pipelining on the CPU, or other systems can interfere -- it's extremely valuable to be very empirical, and to check all assumptions. The best recommended way to benchmark is to run the benchmark with multiple iterations over the same piece of code (after confirming that the compiler isn't eliding all the synthetic work): once with n, and once with 2n. Then the actual cost of n iterations can be determined by subtracting them.
The best mechanism to deal with variations in runtime across runs is to choose the minimum to minimize noise -- this may not be immediately intuitive, but is something I'd also learned from watching Android Benchmarking talks. The minimum time is almost certainly the one where nothing else interfered while benchmarking, and should truly represent the workload.
Books I'd like to cover include The Art of Computer Systems Performance Analysis, The Nature of Mathematical Modeling, any math books that help me with understanding these parts, Linkers & Loaders, etc. I expect to increase this list over time, particularly to incorporate books that help me understand GPU behavior, LLMs, etc.
At the same time, Queueing theory also applies to organizations and systems, so I'd also like to complement this series with The Principles of Product Development Flow, which also goes into the math.
As an attempt at capturing interesting links -- and recording where I find them -- I've set up a Google Form for myself that publishes to a spreadsheet. I use it to upload papers straight to my drive, capture links from HN & Twitter, etc. I'm excited to see which of my technical news sources I should maintain and which ones I should cut down on.
libSegFault.soA colleague -- CT -- pointed me to libSegFault.so: a very useful
utility that can be LD_PRELOADed. Spending some time googling made
me realize I'd been missing out on some very useful infrastructure.
There are some great blogposts on this, and also seems to be a really fun pattern I now want to apply on other pieces of native code. LibSegFault itself adds a SEGFAULT handler that prints a lot of useful information to help isolate where the segfault happened, without needing to recompile the code at all.
Mark announced that we're building LLaMa3 -- and given that's public, I can also say that I'm helping out with that by building and maintaining tools for the team. This is one of the projects I've been most excited about in my career so far.
— Kunal