Eliminating GIL in Ruby Through Hardware Transactional Memory (2013) | Hacker News Reader

Eliminating GIL in Ruby Through Hardware Transactional Memory (2013)

researcher.watson.ibm.com

51 pointsNowaker14 comments

A more recent version of the work: http://researcher.watson.ibm.com/researcher/view_person_subp...

I saw the first author of this paper present this work in my building about six months ago. Myself and others were impressed with both their results, and the rigor in their analysis. They experiment on multiple hardware platforms, and even compare against other VMs. In short, this is what good systems research looks like.

Note that the page I linked to has both the full paper and the slides from their conference talk. I should also disclose that I also work for IBM Research, so I may have some bias in liking this paper.

(Copying a comment I made on an older submission; that may be why this poster submitted the older research report.)

Darn - I'm still mad about Intel's TSX-HTM bug[0]. I really wanted to compile this and play with it.

[0] - http://techreport.com/news/26911/errata-prompts-intel-to-dis...

I summarized this paper in my blog if anyone wants a higher-level overview of what it means:

http://www.mikeperham.com/2013/12/31/rubys-gil-and-transacti...

Is it me or does anyone here thinks that with the recent progress in static compiled language in user-friendliness, the path of optimizing the ugly parts of dynamic languages outside of the language design itself is a waste of time ?

Note : not saying this research isn't interesting, because it may lead to many different uses. Just about the example chosen itself.

I have used many of the fancy staticly typed languages and still find dynamic languages more productive, and more accessible to a larger range of people.

I only find them more productive until about 300-500 LoC.

It's about at that point, particularly if there's multiple files, that I find myself suddenly wishing for stronger type systems.

That being said, most things I write (outside of work) aren't that long, and you can get started faster in dynamic languages.

I haven't felt any improvement in productivity at higher KLOC counts with statically typed languages in my coding. I've also worked at several large companies and have watched teams using both types of languages, and I have not seen more productivity from those using statically typed languages.

More importantly, there is no conclusive empirical evidence either way.

Which statically-typed languages are you using?

I've used many of them. Java, Scala, Haskell, ocaml, etc.

Also, in the open source world there is no visible difference in robustness or productivity.

Edit: I forgot to mention go, and I thought HN was better than down voting someone that has a different opinion.

jshen: I feel your pain. I think there's been too much down-voting by the karma bullies on HN lately, and I think that's the number one reason there's been less comments on HN.

Of course, there are folks who will feel that even though there are less comments lately the level of discourse is higher.

Removing-VM-lock-with-HTM has nothing to do with dynamic or static, compiled or not compiled. Many "staic compiled languages" can have global VM lock too.

That sort of neglects the impact of these sorts of efforts on existing codebases, and there's millions of man-hours poured into writing those.

...on a mainframe....

Ruby is the new RPG! :)

Reply on news.ycombinator.com