search

ocamllabs / icfp2016-blog

Canopy blog data that powers ICFP liveblog
http://icfp2016.mirage.io
17 stars 6 forks source link

Write up notes + links for my talk #210

Closed WillSewell closed 7 years ago

WillSewell commented 8 years ago

@avsm any chance I can get this merged? :)

gasche commented 7 years ago

Merged, thanks! Sorry for the delay.

WillSewell commented 7 years ago

No problem. By the way @gasche, I'm not sure if you looked at the slides, but I actually mentioned your blog post in the talk. Kudos for your work there! It lead me down an interesting road of looking into the OCaml GC, which I knew nothing about previously.

gasche commented 7 years ago

Thanks -- I was told after your talk. Interestingly, someone contributed a Java implementation to my gitlab repository, and the results are noticeably worse than Haskell's: even the G1 collector which is supposed to be the most incremental has latencies in around 60-70ms on my machine, compared to 50ms for Haskell.

(I should take the time to put up a proper README with a language comparison and encourage other people to contribute their implementation for other languages: it sounds like you've found a fun problem to turn into a micro-benchmark.)

WillSewell commented 7 years ago

That is interesting. I had assumed that the JVM GC would perform well in this case. Particularly because I thought that the main reason for having a different algorithm in the old generation is to optimise for this exact problem.

I wonder if it can be tuned though. Because it's incremental, I don't see why you can't get a knob that lets you bound the maximum pause time, letting you trade latency for throughput.

Sounds like a great idea: encouraging contributions using other languages.