HN user

tekknolagi

1,872 karma

[ my public key: https://keybase.io/tekknolagi; my proof: https://keybase.io/tekknolagi/sigs/3yeAq3H_gbqDnK8_Il6wEe8ncwrDEkYiZc0ld5NxGIE ]

https://bernsteinbear.com

email on website

Posts63
Comments630
View on HN
bernsteinbear.com 3mo ago

Value Numbering

tekknolagi
2pts0
cfallin.org 3mo ago

The acyclic e-graph: Cranelift's mid-end optimizer

tekknolagi
74pts22
bernsteinbear.com 3mo ago

Value numbering

tekknolagi
2pts0
railsatscale.com 4mo ago

ZJIT removes redundant object loads and stores

tekknolagi
92pts19
wingolog.org 5mo ago

Two mechanisms for dynamic type checks

tekknolagi
1pts0
bernsteinbear.com 6mo ago

The GDB JIT Interface

tekknolagi
6pts0
railsatscale.com 7mo ago

Adding Iongraph Support to ZJIT

tekknolagi
8pts1
www.chrisgregory.me 8mo ago

Graph Neural Networks for Faster Search

tekknolagi
2pts0
bernsteinbear.com 1y ago

ClassDistribution from S6 JIT is neat

tekknolagi
3pts0
bernsteinbear.com 1y ago

Zero-overhead checks with fake stack overflows

tekknolagi
1pts0
railsatscale.com 1y ago

Fast Allocations in Ruby 3.5

tekknolagi
267pts67
railsatscale.com 1y ago

ZJIT has been merged into Ruby

tekknolagi
50pts6
pdubroy.github.io 1y ago

And Change

tekknolagi
4pts2
pypy.org 1y ago

Doing the Prospero-Challenge in RPython

tekknolagi
29pts2
bernsteinbear.com 1y ago

Nix derivations by hand, without guessing

tekknolagi
3pts0
www.mattkeeter.com 1y ago

The Prospero Challenge

tekknolagi
2pts0
bernsteinbear.com 1y ago

Optimizing Django by not being silly

tekknolagi
2pts0
bernsteinbear.com 1y ago

Representing Type Lattices Compactly

tekknolagi
87pts27
railsatscale.com 1y ago

Interprocedural sparse conditional type propagation

tekknolagi
2pts0
bernsteinbear.com 1y ago

A Compiler IR for Scrapscript

tekknolagi
5pts0
bernsteinbear.com 1y ago

Weak references and garbage collectors

tekknolagi
3pts0
jennyjams.net 1y ago

Baby's Second Garbage Collector

tekknolagi
2pts0
bernsteinbear.com 1y ago

Abstract Interpretation in the Toy Optimizer

tekknolagi
2pts0
bernsteinbear.com 2y ago

Some Tricks from the Scrapscript Compiler

tekknolagi
2pts0
bernsteinbear.com 2y ago

Vectorizing ML Models for Fun

tekknolagi
1pts1
github.com 2y ago

Cado: Python notebook IDE with a focus on reactivity

tekknolagi
4pts1
bernsteinbear.com 2y ago

A quick look at destination-driven code generation

tekknolagi
60pts10
bernsteinbear.com 2y ago

Compiling ML models to C for fun

tekknolagi
3pts0
bernsteinbear.com 2y ago

Compiling ML models to C for fun

tekknolagi
7pts0
bernsteinbear.com 3y ago

Compiling Typed Python

tekknolagi
108pts50

If all you're doing is summing small integers---frequently the case---it's much preferable to optimize that to be fast and then skip the very dynamic method lookup (the slower, less common case)

YJIT is not deprecated. That word has a specific meaning in Ruby. You can continue to use YJIT.

With any luck, this performance in the next year or two will be enough to make it a happy change. "Damn, free money" etc

Earnestly: why are you annoyed? I tried to make it clear that you don't have to make any changes. If you want, you can try ZJIT (which should not be anything other than a one character change), but you don't have to.

In this case, we used to abort (i.e. abort(); intentionally crash the entire process) but now we jump into the interpreter to handle the dynamic behavior.

If someone writes dynamic ruby code to add two objects, it should succeed in both integer and string cases. The JIT just wants to optimize whatever the common case is.