tenderlove

RubyGems.org backfilled older releases with `created_at` fields, so theoretically you could still do the cooldown with very old gems (though I don't know why you would). It's only private / alternative gem servers that may not provide `created_at` fields.

This absolutely happened and is not speculation. I can't find the emails from the individuals that emailed me, but I did find my email to the board of directors asking that the website language be changed because people had pinged me thinking I would be getting money, or that the money would go to fund rubygems.org.

At the time I'd sent the email I was unaware Ruby Together was on HN front page (and that's why people were pinging me)

As I said in my blog post, it imports both and combines them in the UI. Also as I said in my blog post, I switched to shooting only in raw, and it still exhibited file corruption.

That's a mistake no mater what application you're importing to, else we'll be graced with another blog post, "Darktable app Corrupts Photos"

Thanks dad.

This is also my guess. It's really a bummer, and I'd report it to Apple but since it's nondeterministic I have no idea how to provide repro steps.

Here you go!

  https://gist.github.com/tenderlove/25853f50ab46a58738ff2cc22d682f2b

Thank you! Wish it had panned out for Class#new, but I don't feel bad about doing it. :)

Yes, but if it ends up creating any ephemeral objects in the process of determining those returned objects, then the allocation sequence is still not homogeneous.

Yes! People might do `map` transformations, but it's very common to do other stuff at the same time. Any other allocations during that transformation would ruin cache hit rate.

At the same time, the callsite for any given `.new()` invocation will almost always be creating an instance of the exact same class. The target expression is nearly always just a constant name. That makes it a prime candidate for good inline caching at those callsites.

Yes again!

One reason is that we think we can make better use of registers. Since LBBV doesn't "see" all blocks in a particular method all at once, it's much more challenging to optimize register use across basic blocks. We've added type profiling, so ZJIT can "learn" types from the runtime.

It's not being abandoned, we're just shifting focus to evaluate a new style of compiler. YJIT will still get bug fixes and performance improvements.

ZJIT is a method based JIT (the type of compiler traditionally taught in schools) where YJIT is a lazy basic block versioning (LBBV) compiler. We're using what we learned developing and deploying YJIT to build an even better JIT compiler. IOW we're going to fold some of YJIT's techniques in to ZJIT.

And if so, will these YJIT features likes Fast Allocations be brought to ZJIT?

It may not have been clear from the post, but this fast allocation strategy is actually implemented in the byte code interpreter. You will get a speedup without using any JIT compiler. We've already ported this fast-path to YJIT and are in the midst of implementing it in ZJIT.

It says on the website it's 12x faster so it must be true!

https://rubyui.com

libffi can't know how to unwrap Ruby types (since it doesn't know what Ruby is). The advantage presented in this post is that the code for type unboxing is basically "cached" in the generated machine code based on the information the user passes when calling `attach_function`.

I think tenderworks wrote this post.

Thank you!

Ya, I really enjoy pattern matching. I think new language features just take a long time to percolate through the community. I remember when `->` was controversial, but that's the only way I write lambdas today. :D

I didn't know it was controversial either! D:

This is great to hear. <3

While RUM is out of date, I still think it's an excellent resource. Some of the information in the book may be out of date, but I think it's an excellent place to start when you want to jump in to Ruby's source. Basically, after reading RUM the best place to go is to start reading the source.

That said, it would be really great if Pat (or someone besides me) published an update version of RUM

This guide is interesting but extremely out of date. I recommend Ruby Under a Microscope[1] though it is also out of date as well (but less out of date than the Ruby Hacking Guide)

1. https://nostarch.com/rum

Use a password manager with autofill so you'll make no mistakes where you are

I hope that you'll watch the recording of the talk when it's released. The context of the "cliche" is with regard to the community, the framework, and why Eileen continues to remain on the core team. It's nothing to do with the design or functionality of the framework itself. :)

I've seen different people mean different things by this, do you mean the IR is a list of bytecode handler addresses, and then the end of every handler is a load+indirect jump? Or is there also a dispatch table? In my experience the duplication of the dispatch sequence (i.e. no dispatch "loop") is worth 10-40% and then eliminating the dispatch table on top of that a bit more.

It's the former. Each bytecode is the handler address and every handler does a load + jump. There's no dispatch table (though there are compilation options that allow you to use a dispatch table, but I doubt anybody does that since you'd have to specifically opt in when you compile Ruby).

Sure, the question is always about the dynamic frequency of such call sites. What kind of ICs does YARV use? Are monomorphic calls inlined?

In one of our production applications, the most popular inline cache sees over 300 different classes and ~600 shapes (this is only for instance variable reads, I haven't measured method calls yet but suspect it's similar).

The VM only has a monomorphic cache (YJIT generates polymorphic caches), and neither the VM nor the JIT do inlining right now.

I'll take a stab at this.

YARV (Ruby's VM) is already direct threaded (using computed gotos), so there's no dispatch loop to eliminate. YARV is a stack based virtual machine, and the machine code that YJIT generates writes temporary values to the VM stack. In other words, it always spills temporaries to memory. We're actively working on keeping things in registers rather than spilling.

Ruby programs tend to be extremely polymorphic. It's not uncommon to see call sites with hundreds of different classes (and now that we've implemented object shapes, hundreds of object shapes). YJIT is not currently splitting or inlining, so we unfortunately encounter megamorphic sites more frequently than we'd like.

I'm sure there's more stuff but I hope this helps!

Yes!!!! My plan is to make a promotional video with Euro Beat music. I also want to feature "multi-line editing!"

Maybe we could do something like reparse the line and check the arity? We know the reader doesn't take a parameter, but the user clearly provided one, so maybe we could eliminate suggestions that have the wrong arity.

You're not sure about the technical details, but it's clearly the technology's fault?

Which part of raw web performance? These don't seem like web performance benchmarks. IOW I'm not sure how calculating digits of PI impacts serving HTML.

Seems like we need benchmarks for actual web workloads. :)

I wrote it because I can never remember what the `test` instruction does to the zero flag. Every time I use the instruction I have to look up the docs. Looking up docs is fine, but running code in a REPL helps me remember things better.

Thank you so much, I really appreciate it. I really should blog more, I just haven't been "feeling it" lately. Words of encouragement really help, so thank you so much! :D

Hi!

Yes, that is one of my goals. I'll be presenting this project at RubyConf and I hope that I can get the compiler to compile itself by then. Breaking the circular dependencies is somewhat tricky, and you'll see some frankly ridiculous code inside TenderJIT that is meant to break those cycles.

It's x86-64 specific right now. I'm interested in adding ARM support so I'll do that at some point in the future. My desktop is x86-64 and our production machines are as well, which is why I started with it.

Thanks for the interest!