Thoughts about what features a REPL (and the language being evaluated in the REPL!) should have to be useful.
Read this as part of some archaeology into numeric representation in early Lisp systems. But it actually turned out to be pretty neat systems paper in general. One thing that's striking is how readable this 50 year old paper still is. The vocabulary of systems programming has changed surprisingly little (just switched from words to bytes), and even the problems being solved are at the core the same. It's all about memory hierarchies, even at the dawn of computing.
Paper describes an early version of BBN Lisp for a machine with 16K words of core memory, and 88K words of absurdly slow drum memory. Hardware has no paging support. How do you make efficient use of the drum memory, to fit in meaningful programs? So you need to somehow do paging in software, and reorganize the data layouts to minimize pointer chasing and page faults. (The latter bit is what I was really interested in, while looking at the history of tagged pointers).
Take a bitset implementation that splits the set into blocks, and adaptively uses the best data representation for each block. How do you determine which internal representations actually make sense?
Slides with anecdotes on game optimization in general, but on the Jaguar CPU in particular. E.g. didn't realize you really have to use SIMD on those CPUs, or you can't even use the full cache bandwidth. Neat example of a custom spatial database near the end.
"tl;dr don't bother".
The painful step-by-step journey of implementing a seemingly trivial optimization in a production compiler. Especially the "Lessons Learned" part is great; I'm fighting the temptation not to just quote all of it here.
> I switched to a 12” MacBook before I started working on my swiftc PR. It was so slow that I was only able to iterate on the code once a day, because a single compile and test run would take all night. I ended up buying a top-of-the-line 15” MacBook Pro because it was the only way to iterate on the codebase more than once a day.
> It’s really easy to break swiftc because of how complex it is. My original pull request was approved and merged in a month. Despite only having about 200 lines of changes, I received 125 comments from six reviewers. Even after that much scruitiny, it was reverted almost immediately because it introduced a memory leak that a seventh person found after running a four hour long standard library integration test.
Yes, it's a Bitcoin article. But it's also really good!
> Bitcoin neatly avoids the double-spending problem plaguing proof-of-work-as-cash schemes because it eschews puzzle solutions themselves having value.