3 ms·
I don't understand why we have to pretend Ruby could ever be as fast as C. Or faster. That's like saying a jockey is faster than their horse. Ruby is riding
by john_the_writer 3y ago
I don't understand why we have to pretend Ruby could ever be as fast as C. Or faster. That's like saying a jockey is faster than their horse. Ruby is riding on C, so it cannot be faster.
Also why even bother. Ruby is fast enough for the job it does. It's higher level and makes things that are "harder" in C, easier. Dev time is less, and thats where we win. We take the win, and accept what it is.
- deleted 3y ago[deleted]
- michaelteter 3y agoI think the point of the essay is that we shouldn’t immediately assume that going to C is the best way to speed up part of a Ruby system. It might be conventional wisdom to break out to C for the speed gain, but a purpose made, hand written piece of Ruby, with JIT optimizations, and be a better/faster solution.
- vidarh 3y agoSome Ruby implementations are "riding on C". Others are not, e.g. Truffle Ruby. While beating C overall would be very hard because of the dynamism of Ruby, most Ruby code is not very dynamic after a short warmup (loading for most code; connecting a database etc. for code using a dynamic ORM), and at least on specific code it's at least theoretically possible for a Ruby JIT to beat C by optimising to the actual runtime configuration and evaluate out all the dynamism that costs Ruby performance. TruffleRuby goes part-way there, in terms of guarded section that makes assumptions about types but where the guards shunts code that breaks those assumptions onto a slow path, but a Ruby JIT or a combination of a bytecode compiler and JIT, can at least in theory go much further. E.g. a whole lot of the Ruby code library contains type checks that a compiler could hoist and/or elide. Yjit is a baby step, but a good start.