5 ms·
Well I ran it in IntelliJ and saw the same results. Then I found the problem... I used compile_static3.groovy from your repo for the test which contains the fo
by mbell 14y ago
Well I ran it in IntelliJ and saw the same results. Then I found the problem...
I used compile_static3.groovy from your repo for the test which contains the following:
bench(d, "fib_dynamic", 30, "Full dynamic ")
bench(d, "fib_integer", 30, "Groovy w/ explicit types")
bench(d, "fib", 40, "Explicit type w/@CompileStatic")
Notice the '40' on the last line :p
Corrected results:
Full dynamic took 305 ms
Groovy w/ explicit types took 22 ms
Explicit type w/@CompileStatic took 7 ms
Which is much more like what I expected compared to Ruby at 475ms.
- mgkimsal 14y agoBut.... this was in my verbal presentation - move that @compilestatic benchmark to the first test - it'll be different. There's something about running it after the other two which is adding to the benefit - caching maybe? Moving it to the first one gives me 18-20ms generally. Try it :)
- mbell 14y agoJust a guess but the JIT may be detecting the recursion and replacing it with a loop. The recursion signature is the same for each method so the JIT may be able to catch that. Letting the JIT warm up is enlightening though, I looped the 3 tests 1000 times and also looped my ruby test 1000 times and I get this: Explicit type w/@CompileStatic took 5 ms Groovy w/ explicit types took 11 ms Full dynamic took 75 ms Ruby took 464ms
- mgkimsal 14y agoVery interesting - haven't compared it to Ruby, but the 75ms was interesting on its own. I knew dynamically Groovy would generally be faster than Ruby, but not by that much, given the runtime dynamism. Thanks! (and thanks for the pull request fix)