4 ms·

biggest improvement is 68% for optcarrot (ruby-based NES emulator). not bad at all!

m12k 5y ago
I imagine an emulator will have hot paths in tight loops in a way that web apps don't, so it makes sense that it sees the biggest benefit from jit'ing
pjmlp 5y ago
JRuby also runs it quite fast, although I think does require some warmup measured in minutes, until it is almost C like.
- lf-non 5y ago
  We used to run a production service written in JRuby until a year or so ago (at which point it was rewritten in kotlin). It was a minimal pure ruby service deployed as a tomcat servlet. Despite not using any heavy weight framework (eg. rails etc.) its performance (after warmup) was nowhere close to "almost C like". JVM gives you true multithreading etc. but claiming that JRuby performance is C like is just misleading.
  - pjmlp 5y ago
    Well, https://news.ycombinator.com/item?id=13056334 https://news.ycombinator.com/item?id=13056334
    - byroot 5y ago
      That's TruffleRuby, not JRuby. And even then, I haven't benchmarked myself, but I wouldn't be surprised most NES emulators written in C or other native languages out there would do way more than 150FPS. Edit: and it doesn't really matter either way because while useful, optcarrot is a very different workload from what Ruby is generally used for.
      - nitrogen 5y ago
        very different workload from what Ruby is generally used for. Ruby is generally used for a lot of things, including scientific computing. I'm using it to process sound and make videos about sound, for example. Audio processing isn't too far off from the type of hot loop an emulator would have, so I hope to see benefits from YJIT in my own work, and will also try TruffleRuby once I've finished my current round of video editing.
      - pjmlp 5y ago
        Yeah, I got that wrong. Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS, unless we are talking about VR, which is nonsense for a NES emulator anyway. Trying to win the benchmarks game makes people lose sight from what actually matters. SPA would never had taken off if it wasn't for the work done in JavaScript JITs. Similarly, Ruby JITs can open doors for just being the language used for Rails applications.
        byroot 5y ago
        > Who cares if they do more than 150 FPS I don't, but you said "almost C like".
        pjmlp 5y ago
        If we are going pedantic, we can also start discussing how crappy C used to be in 8 and 16 bit computers. "C like" as in the human doesn't see a difference.
        Zababa 5y ago
        > Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS Things in 120 FPS feels smoother than in 60 FPS. Less than 60 compared to 30, but it's still noticable. I don't know the exact mechanism, but I suppose that's because the real world has no concept of FPS and what we see is continuous, so our eyes are used to seeing something like this.
        5y ago
- nobleach 5y ago
  Back in the day, I used JRuby because it was the only way I was able to run Ruby on Windows 2003 servers that I was forced to use while working for the Federal Government. (Yes, Thin and Mongrel existed, but their perf on Windows was REALLY bad) Was it fast? No. Was it "good enough?" yep. It never fell over.
munificent 5y ago
Even that's not very large. Moving from a bytecode VM to a JIT is a big jump in codebase complexity that all future maintainers and contributors to Ruby will have to take on. The set of people who can contribute to a JIT is much smaller than to a bytecode VM. I'd guess one or two orders of magnitude. I can't see that codebase complexity being worthwhile unless the JIT at least gives you something like 2-3x better perf across the board. In Java and JS VMs, you do see an improvement of that scale.
- joelbluminator 5y ago
  That's an interesting take. It seems like Matz and the rest of Ruby core don't see this as such a big deal though as this is going to get merged. I can see the added complexity but this can just be another piece of Ruby core maintained by a few experts, no? Seems like most Ruby contributors specialize anyway.

m12k 5y ago

I imagine an emulator will have hot paths in tight loops in a way that web apps don't, so it makes sense that it sees the biggest benefit from jit'ing

pjmlp 5y ago

JRuby also runs it quite fast, although I think does require some warmup measured in minutes, until it is almost C like.

lf-non 5y ago
We used to run a production service written in JRuby until a year or so ago (at which point it was rewritten in kotlin). It was a minimal pure ruby service deployed as a tomcat servlet. Despite not using any heavy weight framework (eg. rails etc.) its performance (after warmup) was nowhere close to "almost C like". JVM gives you true multithreading etc. but claiming that JRuby performance is C like is just misleading.
- pjmlp 5y ago
  Well, https://news.ycombinator.com/item?id=13056334 https://news.ycombinator.com/item?id=13056334
  - byroot 5y ago
    That's TruffleRuby, not JRuby. And even then, I haven't benchmarked myself, but I wouldn't be surprised most NES emulators written in C or other native languages out there would do way more than 150FPS. Edit: and it doesn't really matter either way because while useful, optcarrot is a very different workload from what Ruby is generally used for.
    - nitrogen 5y ago
      very different workload from what Ruby is generally used for. Ruby is generally used for a lot of things, including scientific computing. I'm using it to process sound and make videos about sound, for example. Audio processing isn't too far off from the type of hot loop an emulator would have, so I hope to see benefits from YJIT in my own work, and will also try TruffleRuby once I've finished my current round of video editing.
    - pjmlp 5y ago
      Yeah, I got that wrong. Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS, unless we are talking about VR, which is nonsense for a NES emulator anyway. Trying to win the benchmarks game makes people lose sight from what actually matters. SPA would never had taken off if it wasn't for the work done in JavaScript JITs. Similarly, Ruby JITs can open doors for just being the language used for Rails applications.
      - byroot 5y ago
        > Who cares if they do more than 150 FPS I don't, but you said "almost C like".
        pjmlp 5y ago
        If we are going pedantic, we can also start discussing how crappy C used to be in 8 and 16 bit computers. "C like" as in the human doesn't see a difference.
      - Zababa 5y ago
        > Who cares if they do more than 150 FPS, when humans cannot see more than 60 FPS Things in 120 FPS feels smoother than in 60 FPS. Less than 60 compared to 30, but it's still noticable. I don't know the exact mechanism, but I suppose that's because the real world has no concept of FPS and what we see is continuous, so our eyes are used to seeing something like this.
        5y ago
nobleach 5y ago
Back in the day, I used JRuby because it was the only way I was able to run Ruby on Windows 2003 servers that I was forced to use while working for the Federal Government. (Yes, Thin and Mongrel existed, but their perf on Windows was REALLY bad) Was it fast? No. Was it "good enough?" yep. It never fell over.

munificent 5y ago

Even that's not very large. Moving from a bytecode VM to a JIT is a big jump in codebase complexity that all future maintainers and contributors to Ruby will have to take on. The set of people who can contribute to a JIT is much smaller than to a bytecode VM. I'd guess one or two orders of magnitude. I can't see that codebase complexity being worthwhile unless the JIT at least gives you something like 2-3x better perf across the board. In Java and JS VMs, you do see an improvement of that scale.

joelbluminator 5y ago
That's an interesting take. It seems like Matz and the rest of Ruby core don't see this as such a big deal though as this is going to get merged. I can see the added complexity but this can just be another piece of Ruby core maintained by a few experts, no? Seems like most Ruby contributors specialize anyway.