Hacker News Reader

Awesome blog post Ben! Question: how did you come up with your list of opcodes?

I ask because while some opcodes are obviously needed others as not so obvious and coming up with a balanced instruction set is somewhat difficult design problem.

View on HN

Good question. A bit of experience, some guesswork, and a lot of testing and benchmarking along the way. I separated out global and local opcodes originally because I wanted individual variable accesses to be fast (why do at runtime what you can do at compile time). As I mention in the article, originally I had all the builtin functions as separate opcodes, but that was slower due to the sheer number of opcodes and Go's current binary tree approach to "switch". I also used Go's profiling tools a bunch to see where the hotspots where. I'm sure there's significant room for improvement, but it's hard, because sometimes when you improve one benchmark, something else suffers.

What tools did you use for timing and benchmarking beyond the tools included in the go distribution?

Just the Go benchmarking tools built into "go test", as well as a couple of scripts of my own just using "time ./goawk 'BEGIN { ... test script ... }'" and that kind of thing. Nothing fancy!

Reply on news.ycombinator.com