4 ms·
I don't understand bolting concurrency onto something that is interpreted. A compiler would get you 10-100x speedup, without your users having to do the comple
by gameswithgo 6y ago
I don't understand bolting concurrency onto something that is interpreted. A compiler would get you 10-100x speedup, without your users having to do the complex thing of writing safe parallel code.
- jashmatthews 6y agoCRuby has had JIT for over 3 years now and I think JRuby must be over a decade?
- gameswithgo 6y agoare those first class options now? or is it like python where you can kinda sorta sometimes use a jit?
- jashmatthews 6y agoFirst class option in Ruby 2.6 onwards.
- pjmlp 6y agoYeah, but not that impressive in capabilities, hence other projects. https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/ https://developers.redhat.com/blog/2020/01/20/mir-a-lightwei...
- jashmatthews 6y agoWhile MIR could be an interesting alternative to CraneLift it doesn't really address the challenges faced by trying to improve performance via JIT compilation within CRuby.
- chubot 6y agoRuby can’t be compiled easily due to the very dynamic semantics of the language. If you wanted to compile it, it would probably start behaving a lot more like Crystal, which looks similar but behaves completely differently.
- gameswithgo 6y agoyou could aot compile most of most programs and jit the rest. or just jit everything
- jashmatthews 6y agoIf you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. If you're talking about producing a static binary then both Rubymotion and TruffleRuby can do this.
- chubot 6y agoI should have clarified that I meant "compiled easily for 10-100x speedup" (on representative workloads) as the OP was saying. You can definitely compile anything... whether it's worthwhile is a totally different story. I learned this the hard way :) As far as I remember the Ruby 3x3 effort yielded 3x on SOME workloads, with tremendous effort, which is about what I would have expected due to Ruby's very dynamic semantics.
- jashmatthews 6y agoTruffleRuby already has that kind of performance increase on microbenchmarks. The CRuby JIT for 3x3 built by one person in their spare time.
- FooBarWidget 6y ago> If you're talking about just compilation then it's easy enough doing something like context-threading where you translate bytecode into a call instruction per operation to a function implementing the bytecode. Ruby has already been doing threaded dispatch on bytecodes since 1.9.
- jashmatthews 6y agoContext-threading is a JIT technique. CRuby can optionally use call-threading where each op is a function and dispatch is an infinite loop of function calls. It's not the default since direct or token threading are faster but it's there. Call-threading looks like this: while(1) { interpreter_state = *virtual_program_counter++(interpreter_state); } There's an indirect jump here. With context-threading you JIT very simple code which looks like this and has only direct calls: interpreter_state = put1(interpreter_state); interpreter_state = put1(interpreter_state); interpreter_state = plus(interpreter_state);
- ramchip 6y agoA lot of web services do a little bit of work, wait on a DB query, do a little bit of work, wait on DB, etc. It’s even more true with websockets, which spend most of their time idle waiting for messages. Good concurrency support lets you handle thousands (even millions) of these activities in a single process, which is massively more efficient than using a process each, and puts less load on other systems (DB, Splunk, Graphite, RabbitMQ…) Green threads in particular make it possible to get these benefits without writing the code in async style. You just write regular, blocking code and the runtime / frameworks take care of yielding to the scheduler (event loop) when appropriate.