4 ms·

This is pretty strange if it's true; shouldn't a switch (especially one that simple) compile into a jump table? Otherwise what's the point? Does Go just linearl

• tptacek 14y ago
  There is a general form to switch statements in Go that really is syntactic sugar over if/else chains. I get that serious emulators invest effort in making dispatch fast, and that a naive for/switch loop is not the fastest way to dispatch instructions, but it's nice for getting the emulator working. :)
  • daeken 14y ago
    > I get that serious emulators invest effort in making dispatch fast, and that a naive for/switch loop is not the fastest way to dispatch instructions If you're the kind of masochist that enjoys optimizing dispatch loops (hi, you're not alone), check this out: http://www.emulators.com/docs/nx25_nostradamus.htm http://www.emulators.com/docs/nx25_nostradamus.htm One of the best resources out there for this sort of stuff.
    • asb 14y ago
      Thanks, I hadn't seen that before. My go-to point for all this stuff has always been the papers by Ertl and others http://www.complang.tuwien.ac.at/forth/threaded-code.html http://www.complang.tuwien.ac.at/forth/threaded-code.html
• deleted 14y ago
  [deleted]
• laumars 14y ago
  I think the Go compiler handles switches a little more like a series of "if else" (In fact I think a few languages do that) but Go supports first class functions, you can map things somewhat differently using that. Ken Thompson does go into more detail in a link off the SO question I posted earlier. [edit: i see you've already spotted that link. Sorry about that]
• ANTSANTS 14y ago
  Dispatching a table of functions should have roughly similar performance to dispatching a large switch table, yes, but implementing opcodes as a table of functions allows you restructure your bytecode interpreter in a way that significantly improves performance. Here's a much better explanation than I could give of the dispatch-per-opcode technique, how it works, and why it's faster (tl;dr it's all about branch prediction): http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables/ http://eli.thegreenplace.net/2012/07/12/computed-goto-for-ef... That article explains how to implement the technique for C programs using a "computed goto"/"labels as values" gcc extension. While Go lacks that feature, dispatching a table of functions as the last statement in each opcode implementation should yield a similar result. As long as Go supports "tail-call optimization" in the trivial case of "functions that take no parameters and return nothing calling similar functions" it should work just fine. Googling suggests that Go does not support TCO, but at least this program didn't explode the stack: EDIT: Yes, it does. package main import ("fmt") var acc byte func main() { fmt.Println(acc) acc++ main() }
  • pcwalton 14y ago
    On my system that Go program does not seem to be tail call optimized. Look at the memory consumption over time. You aren't seeing an OOM because Go performs stack growth as necessary.
    • ANTSANTS 14y ago
      Oops, you're right, I was looking at the wrong process in htop: the "go run test.go" process used to build and launch it, not the actual test process, which indeed burned up memory very quickly (but not fast enough to crash when I ran it for a minute earlier). I should have sorted by CPU usage instead of searching by process name. Can anyone think of any other way to implement this kind of dispatch system in Go? If it isn't possible, I don't think Go deserves the status of being "a good language to write emulators in," as this is a pretty important technique for improving performance of CPU emulation.
      • cmccabe 14y ago