In The Ruby Syntax Holy Grail: adding opt_respond_to to the Ruby VM, part 3, I found what I referred to as the “Holy Grail” of Ruby syntax. I’m way overstating it, but it’s a readable, sequential way of viewing how a large portion of the Ruby syntax is compiled. Here’s a snippet of it as a reminder: // prism_compile.c staticvoidpm_compile_node(rb_iseq_t *iseq, const pm_node_t *node, LINK_ANCHOR *const ret, bool popped, pm_scope_node_t *scope_node) { const pm_parser_t *parser = scope...| JP Camara
In Finding the compiler: adding opt_respond_to to the Ruby VM, part 2, I found the entrypoint into the compiler! It takes the root of our abstract syntax tree - pm->node - and produces a rb_iseq_t. rb_iseq_t is an “InstructionSequence”, which represents our virtual machine bytecode. Here’s the code where we left off: // ruby.c static VALUE process_options(int argc, char**argv, ruby_cmdline_options_t *opt) { //... pm_parse_result_t *pm =&result.prism; int error_state; iseq = pm_iseq_new_...| JP Camara
In Adding opt_respond_to to the Ruby VM: part 1, inspired by recent JSON gem optimizations, I setup my goal: I want to add a new bytecode instruction to the Ruby VM which optimizes respond_to? calls. I took this Ruby code: if $stdout.respond_to?(:write) puts "Did you know you can write to $stdout?"end And identified what bytecode instructions matter most (I think): == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(3,3)> # ... 0002 putobject :write 0004 opt_send_without_block <calldata!mid:resp...| JP Camara
I was honored to present a talk on Ruby concurrency at RubyConf 2024. It represents a high-level distillation of much of my writing and research over the past year. The conference itself was great, and presenting was such a fun experience. Here is the talk, titled “In-Depth Ruby Concurrency: Navigating the Ruby Concurrency Landscape”: If you want the slides, I’ve published them as a short YouTube video: I know it’s a bit odd to share my slides as a video, but there are so many animati...| JP Camara
There is a recent language comparison repo which has been getting shared a lot. In it, CRuby was the third slowest option, only beating out R and Python. The repo author, @BenjDicken, created a fun visualization of each language’s performance. Here’s one of the visualizations, which shows Ruby as the third slowest language benchmarked: The code for this visualization is from https://benjdd.com/languages/, with permission from @BenjDicken The repository describes itself as: A repo for coll...| JP Camara
👋🏼 This is part of series on concurrency, parallelism and asynchronous programming in Ruby. It’s a deep dive, so it’s divided into 12 main parts: Your Ruby programs are always multi-threaded: Part 1 Your Ruby programs are always multi-threaded: Part 2 Consistent, request-local state Ruby methods are colorless The Thread API: Concurrent, colorless Ruby Interrupting Threads: Concurrent, colorless Ruby Thread and its MaNy friends: Concurrent, colorless Ruby Fibers: Concurrent, colorles...| JP Camara
👋🏼 This is part of series on concurrency, parallelism and asynchronous programming in Ruby. It’s a deep dive, so it’s divided into 12 main parts: Your Ruby programs are always multi-threaded: Part 1 Your Ruby programs are always multi-threaded: Part 2Consistent, request-local state Ruby methods are colorless The Thread API: Concurrent, colorless Ruby Interrupting Threads: Concurrent, colorless Ruby Thread and its MaNy friends: Concurrent, colorless Ruby Fibers: Concurrent, colorless...| JP Camara
👋🏼 This is a series on concurrency, parallelism and asynchronous programming in Ruby. It’s a deep dive, so it’s divided into 12 main parts: Your Ruby programs are always multi-threaded: Part 1 Your Ruby programs are always multi-threaded: Part 2Consistent, request-local state Ruby methods are colorless The Thread API: Concurrent, colorless Ruby Interrupting Threads: Concurrent, colorless Ruby Thread and its MaNy friends: Concurrent, colorless Ruby Fibers: Concurrent, colorless Ruby ...| JP Camara
👋🏼 This is a series on concurrency, parallelism and asynchronous programming in Ruby. It’s a deep dive, so it’s divided into 12 main parts: Your Ruby programs are always multi-threaded: Part 1 Your Ruby programs are always multi-threaded: Part 2 Consistent, request-local state Ruby methods are colorless The Thread API: Concurrent, colorless Ruby Interrupting Threads: Concurrent, colorless Ruby Thread and its MaNy friends: Concurrent, colorless Ruby Fibers: Concurrent, colorless Ruby...| JP Camara
👋🏼 This is a series on concurrency, parallelism and asynchronous programming in Ruby. It’s a deep dive, so it’s divided into 12 main parts: Your Ruby programs are always multi-threaded: Part 1 Your Ruby programs are always multi-threaded: Part 2Consistent, request-local state Ruby methods are colorless The Thread API: Concurrent, colorless Ruby Interrupting Threads: Concurrent, colorless Ruby Thread and its MaNy friends: Concurrent, colorless Ruby Fibers: Concurrent, colorless Ruby ...| JP Camara
In part 5, we finally got our new instruction defined and outputting as part of our bytecode. if you didn’t run it yourself, you just had to trust me that it really did run. But, I just dropped most of the implementation code in without explaining it. Let’s start off by walking through the basic version, then start planning for the true optimization. The progress so far Here’s our sample Ruby program:| jpcamara.com
In Peephole optimizations: adding opt_respond_to to the Ruby VM, part 4, we dug deep. We found the connection between prism compilation and the specialization we need for our new bytecode, called “peephole optimization”. We learned how to debug and step through C code in the Ruby runtime, and we added some logic for matching the “pattern” of the instruction we want to change. Now that we know where the specialization needs to go and how to match what needs to be specialized - what do ...| jpcamara.com