State of the Lambda

Re:State of the Lambda by mbell on Saturday September 22, 2012 @04:52PM (#4558954)

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.

[ Parent | on HN ]

Re:State of the Lambda by mgkimsal on Saturday September 22, 2012 @06:44PM (#4559252)

But.... 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 :)

[ Parent | on HN ]

Re:State of the Lambda by mbell on Saturday September 22, 2012 @07:17PM (#4559324)

Just 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

[ Parent | on HN ]

Re:State of the Lambda by mgkimsal on Saturday September 22, 2012 @09:26PM (#4559633)

Very 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)

[ Parent | on HN ]