Testing new jump tables change for "switch"

235 views
Skip to first unread message

ben...@gmail.com

unread,
Jan 27, 2022, 4:00:34 PMJan 27
to golang-dev
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

unread,
Jan 27, 2022, 10:37:42 PMJan 27
to golang-dev
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
Reply all
Reply to author
Forward
0 new messages