3 ms·
This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for
by evanphx 16y ago
This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubinius shine. It's getting the performance of the methods that MRI implements in C that we still have work to do on. This is part of the strategy of the project, because it means that we're improving the performance of all ruby code, thus raising the bar not for just one method but for the whole program.
- kemiller 16y agoHi Evan, This is perhaps a silly question, but now that you have a solid base of ruby-in-ruby is there any room to re-optimize certain critical sections (hashes, sockets...) in C? Perhaps using a custom API that preserves most or all of the flexibility that is Rubinius's hallmark? I presume that since you still support most compiled gems that linking to C code is still possible. Just wondering if there might be a best-of-both-worlds solution out there.
- evanphx 16y agoWe already done that, optimize out certain things into primitives, which are implemented in C++. We support as subset of the MRI extension API, mainly we don't support anything using RBASIC(), RHASH(), or RREGXP() because those expose raw C data structures and we don't use the same data structures as MRI.
- headius 16y agoAren't String and Array a mix of both C++ and Ruby, though? So it's a bit more like saying it's running that mix of C++ and Ruby 1.5x slower than MRI runs C, for varying percentages of Ruby and C++. Still awesome though!