It is actually as optimized as the Go compiler's ability to optimize code (SSA and all) - there's a lot of work coming on optimization for the upcoming Go versions that specifically target performance (which is already pretty good).
Go is fast, but this tool isn't translating into idiomatic Go code; it's building a bunch of runtime Objects which do all of the dynamic dispatch that you know and love in CPython, except CPython has a bunch of optimizations to alleviate memory pressure, among other things. This isn't to slight the project, which is very ambitious and impressive and could in theory be as fast as native Go--it just hasn't been treated to an optimization pass yet.
Why do we need this again?
bhat 15 points · Jan 2017
It's a faster way to run certain Python2.7 codebases, such as the ones that Google has.
weberc2 2 points · Jan 2017
This is only true for certain workloads--namely those which are good candidates for parallelization. This is unoptimized.
[deleted] 1 points · Jan 2017
It is actually as optimized as the Go compiler's ability to optimize code (SSA and all) - there's a lot of work coming on optimization for the upcoming Go versions that specifically target performance (which is already pretty good).
weberc2 3 points · Jan 2017
Go is fast, but this tool isn't translating into idiomatic Go code; it's building a bunch of runtime Objects which do all of the dynamic dispatch that you know and love in CPython, except CPython has a bunch of optimizations to alleviate memory pressure, among other things. This isn't to slight the project, which is very ambitious and impressive and could in theory be as fast as native Go--it just hasn't been treated to an optimization pass yet.
[deleted] 3 points · Jan 2017
I see your point - yeah I agree. I'm planning to do the python benchmarks on http://benchmarksgame.alioth.debian.org/u64q/python.html to compare CPython vs. Grumpy and see how performant they are right now.
weberc2 1 points · Jan 2017
Cool. Post it to /r/golang when you've got results!