6 ms·

I run a production Rust web service. The speedup for this service over using slightly stripped Rails was only about 5x. As you said, you can gain like 50-100x p

I run a production Rust web service. The speedup for this service over using slightly stripped Rails was only about 5x. As you said, you can gain like 50-100x performance improvements from not using the default Rails JSON serialization and skipping ActiveRecord. After that, you're lucky to gain 5x performance from re-writing the whole thing in Rust. Most of the hot spots of serving web applications using Ruby are already written as native extensions. I think Rust is fantastic. I'm writing a tinyrb like "Ruby" VM in Rust at the moment. But... it's just not worth the hassle for plugging web services together. Maybe if you're at Google scale and already have web services in C++ it'd be a good choice.

hardwaresofton 9y ago
Let's not forget that 5x is actually a big difference, especially in terms of the end user... You can also avoid much more near-the-edge performance issues/instability. As you alude to it may not be worth a 10x increase in developer effort to try and do a bunch of rewriting when you could do something (as you said) like just replacing the bloatiest, slowest parts of rails and get large performance gains. Have you written anything about this? I'd love to read more. As a person that is neutral/dislike on ruby and full-on hates rails, I'd love to hear from someone who's experienced running something as new as Rust in production alongside a rails application, especially from someone who likes ruby.
- rozap 9y ago
  Right, but you can also get that same 5x increase from writing something using a higher level language running on the JVM or BEAM. You don't need to go full on "systems programming" to have something that outperforms Ruby.
  - jashmatthews 9y ago
    MRI Ruby and BEAM are both bytecode VMs. There's no simple 5x increase in performance there. BEAM is register based, and YARV is stack based, so BEAM tends to be a little faster. The JVM is a completely different beast. Thanks to improvements in the JVM for hosting dynamic languages, JRuby is able to offer some serious performance advantages over MRI Ruby, and I'm really excited about TruffleRuby.
    - hardwaresofton 9y ago
      Just to confirm why this is getting downvoted -- I'm guessing the MRI vs BEAM statement is super wrong? I can't say I know much about erlang's VM but being "bytecode VMs" I don't think MRI the same as BEAM, nevermind the primary paradigms they service being completely different. I assume JRuby is faster than MRI Ruby (at least for parallelizable tasks), so I can't imagine the second statement being wrong per say... Also I'd never heard of TruffleRuby, and call me prejudiced, but I don't want to be anywhere near anything developed by Oracle, whether it's oracle labs or not (I hadn't heard about GraalVM before). Speaking of fast ruby... I'm surprised no efforts to make ruby faster/swap out MRI haven't panned out. In python land I know there are efforts like pypy and pypy+stm tackling the slowness and GIL problems while maintaining axiomatic use of the language.
      - jashmatthews 9y ago
        I'm not sure why this is downvoted so hard because it's true. BEAM has massive advantages over MRI Ruby/Cython for concurrency and parallelism but not really much in sheer throughput. For example, Sinatra + Sequel on MRI has a 50% lead in throughput over Phoenix + Elixir on BEAM here: https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune&l=hos0zj&f=zijxtr-zik0zj-zik0zj-zik0zj-zhxjwf-zijunz-zik0zj-cn3 https://www.techempower.com/benchmarks/#section=data-r15&hw=... Bytecode VMs all have the same fundamental problem with instruction dispatch overhead, regardless of what language or paradigm they're supporting, which is why JIT is so important even though it's so much additional complexity. JRuby is now 2-3x faster in general as the JVM improved support for hosting dynamic languages, and it's in heavy production use at places like TalkDesk, so in that sense it is the "faster Ruby". There's also Topaz, which is Ruby built using the underlying framework of PyPy, but performance is disappointing AFAIK.
gameswithgo 9y ago
5x is an amazing speedup! How much latency did that strip out for end users?
- jashmatthews 9y ago
  Almost nothing in the context of the long-running analytical queries the web layer has to wait on the DB for.
  - api 9y ago
    How much did this save you in energy and hosting fees?
    - jashmatthews 9y ago
      Not at a large enough scale for either to be relevant.
bhaak 9y ago
But if you are talking about a stripped down Rails without ActiveRecord, we are looking at something on par with a Sinatra service. That is pretty lean already. Compared to Rails you already have a big performance improvement. 5x overhead for a Ruby webservice on that level is decent. I wouldn't have expected much more.
0xffff2 9y ago
I find the fact that anyone can speak dismissively about a 5x speedup disheartening. Has anyone ever done a study on how much CO2 we are emitting in the name of "developer productivity"?
- nostrademons 9y ago
  It's probably less than you think. Humans - just by virtue of existence - produce a huge amount of CO2, both through the air they breathe, the meat they eat, the automobiles they get to work in, the heavy machinery used to build those roads & buildings, the manufactured goods they consume, etc. And the CO2 cost of a developer isn't just that one developer's emissions; it's also those of all the support staff needed, from managers/admins/HR at work to the food service workers that serve them meals out to the doctors/lawyers/therapists and other service providers they visit to the parents that raised them. It's almost certain one developer generates more CO2 than any reasonable number of servers that run their code. Anything that reduces manpower costs is a net positive for emissions. Besides, when the equation changes (say, when the software enters maintenance mode but the servers stay up), they'll be a strong economic incentive to spend the developer time to rewrite it more efficiently.
  - nkurz 9y ago
    It's almost certain one developer generates more CO2 than any reasonable number of servers that run their code. I'm not so sure. Let's do a back-of-the-envelope estimate. Assume a single really hefty server that consumes 1 kilowatt. Over one year, this is about 10,000 kw hr. 1 kw hr of electricity produced by a coal fired plant generates about 1 kg of CO2 (https://carbonpositivelife.com/co2-per-kwh-of-electricity/ https://carbonpositivelife.com/co2-per-kwh-of-electricity/). Thus that big server running for a year produces about 10 metric tons of CO2. An average American lifestyle (all in, total country production divided by population, https://www.theguardian.com/environment/datablog/2009/sep/02/carbon-emissions-per-person-capita https://www.theguardian.com/environment/datablog/2009/sep/02...) involves the production about about 20 tons of CO2 per year. So if you write code that full-time on more than 2 really big servers per year, your code might be producing more CO2 than the rest of your lifestyle. I'm guessing that most of the errors in this are probably overestimating the code's CO2 (probably not coal fired, probably less than 1 kw, a year is less than 10,000 hours), so more realistically maybe it's 4-8 servers to be break-even? Still, I think it's fair to say that there are some participants in this forum whose running code probably generates more CO2 than the rest of their lifestyle.
skybrian 9y ago
Not having used Rust, I'm wondering how it makes writing a VM easier or harder?

hardwaresofton 9y ago

Let's not forget that 5x is actually a big difference, especially in terms of the end user... You can also avoid much more near-the-edge performance issues/instability. As you alude to it may not be worth a 10x increase in developer effort to try and do a bunch of rewriting when you could do something (as you said) like just replacing the bloatiest, slowest parts of rails and get large performance gains. Have you written anything about this? I'd love to read more. As a person that is neutral/dislike on ruby and full-on hates rails, I'd love to hear from someone who's experienced running something as new as Rust in production alongside a rails application, especially from someone who likes ruby.

rozap 9y ago
Right, but you can also get that same 5x increase from writing something using a higher level language running on the JVM or BEAM. You don't need to go full on "systems programming" to have something that outperforms Ruby.
- jashmatthews 9y ago
  MRI Ruby and BEAM are both bytecode VMs. There's no simple 5x increase in performance there. BEAM is register based, and YARV is stack based, so BEAM tends to be a little faster. The JVM is a completely different beast. Thanks to improvements in the JVM for hosting dynamic languages, JRuby is able to offer some serious performance advantages over MRI Ruby, and I'm really excited about TruffleRuby.
  - hardwaresofton 9y ago
    Just to confirm why this is getting downvoted -- I'm guessing the MRI vs BEAM statement is super wrong? I can't say I know much about erlang's VM but being "bytecode VMs" I don't think MRI the same as BEAM, nevermind the primary paradigms they service being completely different. I assume JRuby is faster than MRI Ruby (at least for parallelizable tasks), so I can't imagine the second statement being wrong per say... Also I'd never heard of TruffleRuby, and call me prejudiced, but I don't want to be anywhere near anything developed by Oracle, whether it's oracle labs or not (I hadn't heard about GraalVM before). Speaking of fast ruby... I'm surprised no efforts to make ruby faster/swap out MRI haven't panned out. In python land I know there are efforts like pypy and pypy+stm tackling the slowness and GIL problems while maintaining axiomatic use of the language.
    - jashmatthews 9y ago
      I'm not sure why this is downvoted so hard because it's true. BEAM has massive advantages over MRI Ruby/Cython for concurrency and parallelism but not really much in sheer throughput. For example, Sinatra + Sequel on MRI has a 50% lead in throughput over Phoenix + Elixir on BEAM here: https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune&l=hos0zj&f=zijxtr-zik0zj-zik0zj-zik0zj-zhxjwf-zijunz-zik0zj-cn3 https://www.techempower.com/benchmarks/#section=data-r15&hw=... Bytecode VMs all have the same fundamental problem with instruction dispatch overhead, regardless of what language or paradigm they're supporting, which is why JIT is so important even though it's so much additional complexity. JRuby is now 2-3x faster in general as the JVM improved support for hosting dynamic languages, and it's in heavy production use at places like TalkDesk, so in that sense it is the "faster Ruby". There's also Topaz, which is Ruby built using the underlying framework of PyPy, but performance is disappointing AFAIK.

gameswithgo 9y ago

5x is an amazing speedup! How much latency did that strip out for end users?

jashmatthews 9y ago
Almost nothing in the context of the long-running analytical queries the web layer has to wait on the DB for.
- api 9y ago
  How much did this save you in energy and hosting fees?
  - jashmatthews 9y ago
    Not at a large enough scale for either to be relevant.

bhaak 9y ago

But if you are talking about a stripped down Rails without ActiveRecord, we are looking at something on par with a Sinatra service. That is pretty lean already. Compared to Rails you already have a big performance improvement. 5x overhead for a Ruby webservice on that level is decent. I wouldn't have expected much more.

0xffff2 9y ago

I find the fact that anyone can speak dismissively about a 5x speedup disheartening. Has anyone ever done a study on how much CO2 we are emitting in the name of "developer productivity"?

nostrademons 9y ago
It's probably less than you think. Humans - just by virtue of existence - produce a huge amount of CO2, both through the air they breathe, the meat they eat, the automobiles they get to work in, the heavy machinery used to build those roads & buildings, the manufactured goods they consume, etc. And the CO2 cost of a developer isn't just that one developer's emissions; it's also those of all the support staff needed, from managers/admins/HR at work to the food service workers that serve them meals out to the doctors/lawyers/therapists and other service providers they visit to the parents that raised them. It's almost certain one developer generates more CO2 than any reasonable number of servers that run their code. Anything that reduces manpower costs is a net positive for emissions. Besides, when the equation changes (say, when the software enters maintenance mode but the servers stay up), they'll be a strong economic incentive to spend the developer time to rewrite it more efficiently.
- nkurz 9y ago
  It's almost certain one developer generates more CO2 than any reasonable number of servers that run their code. I'm not so sure. Let's do a back-of-the-envelope estimate. Assume a single really hefty server that consumes 1 kilowatt. Over one year, this is about 10,000 kw hr. 1 kw hr of electricity produced by a coal fired plant generates about 1 kg of CO2 (https://carbonpositivelife.com/co2-per-kwh-of-electricity/ https://carbonpositivelife.com/co2-per-kwh-of-electricity/). Thus that big server running for a year produces about 10 metric tons of CO2. An average American lifestyle (all in, total country production divided by population, https://www.theguardian.com/environment/datablog/2009/sep/02/carbon-emissions-per-person-capita https://www.theguardian.com/environment/datablog/2009/sep/02...) involves the production about about 20 tons of CO2 per year. So if you write code that full-time on more than 2 really big servers per year, your code might be producing more CO2 than the rest of your lifestyle. I'm guessing that most of the errors in this are probably overestimating the code's CO2 (probably not coal fired, probably less than 1 kw, a year is less than 10,000 hours), so more realistically maybe it's 4-8 servers to be break-even? Still, I think it's fair to say that there are some participants in this forum whose running code probably generates more CO2 than the rest of their lifestyle.

skybrian 9y ago

Not having used Rust, I'm wondering how it makes writing a VM easier or harder?