Ruby.CodeCompared.To/Assembly

One line against fourteen, and the ratio is the point rather than an embarrassment. puts looks up a method on an object, converts its argument to a string, appends the newline it noticed was missing, and writes through a buffered IO object — and every one of those steps is machinery that has to exist somewhere. Here it does not exist at all, so the newline is the literal byte 10 and the write is four registers and an instruction.

There is no way to fall off the end of an assembly program safely. Without that last syscall the processor keeps executing whatever bytes follow in the .text section and the process dies on an illegal instruction. Ruby's exit being an exception is what lets ensure blocks and at_exit run on the way out; nothing here gets a say.

Sixteen instructions and one division per digit. puts value calls to_s, which allocates a new String object, which reserves heap memory, which the garbage collector will later have to account for — and the conversion inside it is this same division loop, written once in C and shared by every Ruby program ever run. Notice too that nothing here reports failure: a buffer too small would simply write past it.

The Integer in the assembly column is a lie told with a string literal, and it has to be — there is nothing to ask. That is the honest shape of the difference: Ruby carries type information alongside every value at runtime so that value.class can be answered, while a register carries sixty-four bits and the knowledge of what they mean lives entirely in your head. even?, meanwhile, really is one instruction; the method call around it is the expensive part.

This is the cost that makes Ruby Ruby. Reopening a class, defining method_missing, or swapping a method at runtime all work because the lookup happens at call time rather than at parse time — and the price is that every call is a lookup. The assembly column cannot be monkey-patched for exactly the same reason it is fast: the destination is baked into the instruction.

The buffer named doubled is the part worth staring at. map does not modify the array — it builds a second one, which in Ruby means asking the allocator for memory that the garbage collector will later have to visit. Chaining map.select.map allocates three arrays and walks the data three times, which is exactly what each_with_object and lazy exist to avoid.

Three copies and a hand-sized buffer. The 32 is the interesting number: it is a guess, and a longer name would run past the end of it with nothing to complain. Ruby's String grows itself, which is why interpolation cannot overflow and why it allocates. This is also why Ruby 4.0 freezing string literals by default matters — a frozen literal can be shared rather than copied, and copying is what this column does three times.

Three named locals became three registers and the names are gone. Ruby's locals are not free either — they live in the current frame's slot table — but they are looked up by name at parse time rather than remembered by you. Run out of registers here and you must decide, by hand, which value gets pushed to memory; that decision is what a register allocator makes thousands of times per program without mentioning it.

Masking with & 0xFF in Ruby is a real operation on an object; naming al instead of rax is free, because the bits were already there and the narrower name simply stops looking at the rest. The direction that costs something is widening a signed value, where the sign bit must be smeared across the new high bits — that is the movsx instruction, and it exists precisely because reading al into rax would otherwise leave stale bits on top.

Ruby reports Integer for both because the Fixnum/Bignum split was hidden behind one class in Ruby 2.4 — but the split is still there underneath, and it is a performance cliff you can fall off without noticing. The assembly column simply stops: sixty-four bits is all there is, and 1 << 64 would be zero. Ruby's arbitrary-precision integers are a data structure and a library, and this is the hardware they are built on top of.

Writing 17 / 5 and 17 % 5 as separate expressions asks the machine to divide twice unless something notices they are the same division — which is why Ruby has divmod, returning both at once. The instruction was always going to compute both; divmod is the interface that lets you keep the half you would otherwise throw away.

The condition is inverted, which is the commonest source of confusion when reading disassembly: your source says "if this is true, do the block" and the machine says "if this is false, skip the block". Note also that the two arms had to be arranged so control can rejoin — Ruby's if is an expression with one value and one exit, and here you build that yourself out of a jump.

Five iterations in Ruby means five block invocations, each with its own frame and its own index binding — which is why while is measurably faster than times in tight Ruby loops and why nobody writes Ruby that way anyway. The choice of rbx over rcx here is the kind of detail a register allocator handles silently; get it wrong by hand and the loop counter is destroyed by the write in the middle of it.

A parameter list is a promise about registers, and nothing enforces it. Calling combine having set only rdi is not an error — the function reads whatever rsi and rdx happened to hold. Ruby raises ArgumentError with a count before the method body ever runs, and that check is code somebody had to write.

This chain of saved frame pointers is what a Ruby backtrace is made of, one level down. Note that mov rsp, rbp erases nothing — it moves a number, and the locals sit there until the next call overwrites them. That is why a C extension can hand Ruby a pointer to a dead frame and get plausible garbage rather than an immediate crash, and why those bugs surface far from their cause.

Indexing is genuinely free here, and it is also unchecked — numbers[9] reads whatever bytes follow. Ruby returns nil for an out-of-range index rather than raising, which surprises people coming from other languages; the reason it can offer any answer at all is that it knows the length and tests it, which is work this column does not do.

A Ruby Array knows its own length, which is what makes -1, length, each and bounds checking all possible from the same stored number. Here the 3 appears twice — once as count and once as the literal character printed — and nothing connects them. Getting one wrong is the single most common way hand-written assembly reads memory it does not own.

Taking a substring is this: the same address with a smaller count, and no copying. It is also why message.length is instant in Ruby — the count was stored, not rediscovered. The thing Ruby adds on top is that length counts characters while this counts bytes, and for anything outside ASCII those are different numbers; bytesize is the one that matches this column.

The first byte being 42 rather than 0 is little-endianness, and it is the same fact in both columns. This is the strongest evidence that the machine is not hidden from Ruby so much as kept at arm's length: pack, unpack, bytesize and force_encoding are all Ruby admitting that underneath the String there is a byte buffer with a layout — the same buffer dq produces here.

The instruction names and the Ruby operators line up one to one, which they do for no other part of this page. Ruby wraps them in method dispatch and arbitrary precision, so huge_number & 1 still works past 64 bits — but for a Fixnum the work being wrapped really is a single and. When you write flags & MASK in Ruby you are not modeling the machine; you are using it.

This is where the old "multiply by a power of two using a shift" advice comes from. It is worth knowing and not worth doing: any compiler turns value * 4 into a shift already, and in Ruby the method dispatch around either operator costs far more than the instruction inside. Write the multiplication that says what you mean.

Ruby's rule that only nil and false are falsy — that 0 and "" are true — is a deliberate departure from this, and the departure is the point. Here zero is the only thing that can mean "nothing", so zero and false and empty are forced to be the same idea. Ruby separates them by making nil a real object with its own address, which costs a comparison and buys you being able to say that zero is a perfectly good number.

Note the letters are indexed with [rsi + rbx] and no scale, because they are single bytes — the same loop over 8-byte values needed * 8. Ruby's block does not care: each_with_index works the same over strings, integers or arbitrary objects because the size is the collection's problem, not the caller's. That indifference is what a block buys, and it is bought with an object per iteration.

The assembly never builds the intermediate array that select returns — it adds as it goes, which is what sum chained onto select makes unnecessary in Ruby too. That is the practical reading of this row: the allocation Ruby performs between select and sum exists only because the two steps were written as separate passes, and numbers.sum { ... } or each_with_object removes it.

Every object Ruby has ever made for you bottoms out in a syscall like this one, batched: the interpreter asks the kernel for large regions and hands out pieces of them, and the garbage collector is the bookkeeping that lets a piece be handed out twice. Nothing here will ever give the page back, and nothing would complain about using it afterward. Array.new(3, 0) is that entire apparatus, invoked by writing eleven characters.

The message is a fixed string because interpolating the numbers would mean writing the conversion loop again — which is itself the lesson about what warn "…#{index}…" costs. More importantly, the check had to be written. Ruby returns nil for numbers[5] and raises only on fetch; here, omitting the cmp reads whatever bytes follow the array and the program carries on with them, which is what a segfault in a C extension looks like from the inside.

Reading rcx after that syscall would print whatever the kernel left behind, and the program would not crash or complain — it would simply be wrong, in a way that changes with the kernel version. The reason this page can be interesting rather than terrifying is that Ruby has an enormous amount of C standing between you and facts like this one, and the C was written by people who read the ABI document.

In a real dump the faulting line is a mov just like the one after dereference, and the register named in it holds 0x0000000000000000. That is the whole diagnosis: something handed the extension a null pointer and nothing tested it. Ruby raises NoMethodError on nil for the same situation because the interpreter performs the test that this column had to be told to perform.