Exactly. I feel like this author doesn't realise how long ago 32 bit was replaced. Only specifically retro gamers are still playing on PCs that old, and they're probably not online.
I'm surprised the launcher still supported any 32 bit operating systems this long.
Retro games are either played through emulators (ScummVM, DOSBox, etc.) or bought secondhand on physical media. Indeed both are offline and replayable forever and ever (granted that you back up the physical media you acquired accordingly).
> Which means your changes have to go through the Ruby team first. Any additional changes would also need to go through them …
I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.
There's a pretty huge difference between implementing a performance optimization that works in your use case, and upstreaming that optimization to be generally usable.
The latter is often orders of magnitude more work, and the existing solution is probably chosen to be well suited in general.
Patching a dependency comes with significant downstream costs. You need to carry the patch forward to new upstream versions . This implies remembering that the dependency was patched, extracting a patch from the existing changed code, and reapplying the patch, fixing comflicts, recompiling the now special version of that dependency and running tests, checking/updating required license notices accordingly.
This is in essence another form of technical dept.
I don't work on YJIT but I _think_ i know the (or maybe an) answer to this. The code for a JIT'd ruby method isn't contiguous in one location in memory. When a ruby method is first compiled, a straightline path through the method is emitted , and branches are emitted as stub code. When the stub is hit, the incremental compilation of that branch then happens. I believe this is called "lazy basic block versioning".
When the stub is hit the code that gets generated is somewhere _else_ in executable memory, not contiguous with the original bit of the method. Because these "lazy basic blocks" are actually quite small, the bookkeeping involved in "where is the code for this ruby method" would actually be an appreciable fraction of the code size itself. Plus you then have to do more bookkeeping to make sure the method you want to GC isn't referred to by the generated code in another method.
Since low memory usage is an important YJIT goal, I guess this tradeoff isn't worth it.
Maybe someone who knows this better will come along and correct me :)
This is essentially what systemd-resolved with the nss-resolve NSS module is right? It’s possible to use /etc/nsswitch.conf to entirely disable the built-in DNS resolution in glibc if you want.
> a per-thread GIL with an explicit mode to share particular objects
This is like Ruby's Ractors and I haven't really seen that be super successful so far. The "Objects" that need to be shared are things like class definitions, etc.... there are a ton of subtle issues with objects that are being marked as sharable when they should really not be or vice versa.
The problem is that with perf the stack trace is collected by the kernel (when the interrupt from the performance counters fires), and the kernel doesn’t implement dwarf unwinding of user space code.
It _could_, but the kernel folks have made it pretty clear they don’t want to put any code related to dwarf in the kernel.
Uh, can’t imagine too many people reading this are playing Origin-era EA games on a Pentium 4