Testing new jump tables change for "switch"

[ben...@gmail.com]

Hi Keith, Josh, others,

I'm working on a change to my GoAWK interpreter to change it from an AST-walking interpreter to a bytecode (really "word code") interpreter, with a big "switch" with about 85 cases, one for each opcode. I think a jump table might really help, so thanks for your work on this! https://go-review.googlesource.com/c/go/+/357330/

Should I be able to check out this branch and test it as of now, or is it unfinished? (Your comment indicates it may be ready to test.) I tried that and didn't see any speed difference executing "goawk 'BEGIN { for (; i<10000000; i++) s+=i+i+i+i+i }'", which should exercise the big switch millions of times.

This made me think I'm doing something wrong. Can I just check out the Gerrit change, run src/make.bash, and build using the "go" executable that it created? I'm not sure whether 1) I'm holding it wrong, 2) the change isn't ready yet, or 3) it simply didn't speed up this code.

FWIW, my GoAWK code change is here: https://github.com/benhoyt/goawk/pull/88

Cheers,
Ben.

[ben...@gmail.com]

I looked at the code change a bit more closely, and realized it's only implemented for int64 right now (I think). So I changed my Opcode type to int64 and re-ran my quick-n-dirty benchmark above, and now I'm seeing the jump tables in action. I've verified it's outputting an indirect jump (objdump shows "jmpq *(%rsi,%r12,8)").

Here are the results, showing the best of 5 runs. It's 10% faster for this code. Maybe not as big an improvement as I was hoping, but still pretty good!

$ time perflock ./goawk 'BEGIN { for (; i<10000000; i++) s+=i+i+i+i+i }'
real        0m0.853s

$ time perflock ./goawk_jumptables 'BEGIN { for (; i<10000000; i++) s+=i+i+i+i+i }'
real        0m0.765s

-Ben