Ruby Threads and the Global Interpreter Lock in C

Re:Ruby Threads and the Global Interpreter Lock in C by montanalow on Thursday November 27, 2014 @03:37PM (#8668665)

Rubinius is neat, but for me personally (and I think most of the community) it's performance. Writing C enables optimizations by hand that still yield very significant performance gains over the best of what any other high level language (java, c++, ruby) can muster. I don't want to write C, but I'm glad someone else does so I get the benefits when I write Ruby.

[ Parent | on HN ]

Re:Ruby Threads and the Global Interpreter Lock in C by FranzVonSuppe on Thursday November 27, 2014 @03:55PM (#8668703)

I don't understand how you can say Java, C++, and Ruby in the same breath. They are not at all alike. Also what optimizations are available to C which are not in C++? C++ is (almost) a strict superset of C.

[ Parent | on HN ]

Re:Ruby Threads and the Global Interpreter Lock in C by Argorak on Thursday November 27, 2014 @05:15PM (#8668928)

Just because C++ is a superset of C doesn't mean that all C++ features are in a way comparable to C (in compiling and at runtime).

[ Parent | on HN ]

Re:Ruby Threads and the Global Interpreter Lock in C by lmm on Thursday November 27, 2014 @06:46PM (#8669147)

Restrict pointers in C let you write code that's faster than the C++ equivalent for functions that copy a lot of memory.

[ Parent | on HN ]