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

I ran both files through xxd then diffed them. I've literally changed every piece of hardware (at no small cost). "premature to immediately blame Apple" seems a bit off.

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.