maxime_cb
Joined 4 years ago
Karma
448
Submissions
81
Member since
Dec 6
Recent submissions
Comment · 1 month ago
Comment · 1 month ago
Author here. The disassembly for the old enum handling had many spills, simply because the old value enum can't fit in a single register. If you have an instruction that two operands with two of those big value enums, it needs 4 registers instead of 2. That, coupled with better cache-friendliness, explains a lot.
Comment · 2 months ago
I'm assuming you mean that this tech became available in OpenCV 25 years ago, but as it turns out, the underlying tech can be traced back much further, at least as far as 1977! :)
https://ieeexplore.ieee.org/document/1674847 G. J. Vanderbrug and A. Rosenfeld, “Two-Stage Template Matching,” IEEE Transactions on Computers, Vol. C-26, No. 4, pp. 384–393, April 1977. DOI: 10.1109/TC.1977.1674847
Comment · 2 months ago
Thanks :)
I've made a couple of music apps over the years, including one of the oldest JS music apps on the web, that also does URL encoding: https://pointersgonewild.com/2012/04/23/musictoy-music-made-...
But also generally, I was looking at other web-based drum machines, and most of them are either super basic, full of ads, or they have bad cryptic UIs. I also wanted to design a more advanced sequencer with a timeline that would have an intuitive UI to work with.
I built a sequencer in NoiseCraft, a browser-based music programming language I built a few years ago (e.g. https://noisecraft.app/101), but you can't chain pattern in this sequencer, which makes it harder to create longer piece (though people have found workarounds).
Comment · 7 months ago
I gave a talk about ZJIT and the motivation for the change at RubyKaigi 2025 if people are curious. It's on YouTube.
Comment · 7 months ago
Max Bernstein is now leading the team. He's also an excellent compiler engineer.
Comment · 1 year ago
Thanks Ken. Apologies if I misunderstood the situation. I wish you all the best.
Comment · 1 year ago
Ruby has the same unfortunate problem.
Comment · 1 year ago
Instigator of YJIT, the CRuby JIT here.
It's easy to dismiss our efforts, but Ruby is just as dynamic if not more than Python. It's also a very difficult language to optimize. I think we could have done the same for Python. In fact the Python JIT people reached out to me when they were starting this project. They probably felt encouraged seeing our success. However they decided to ignore my advice and go with their own unproven approach.
This is probably going to be an unpopular take but building a good JIT compiler is hard and leadership matters. I started the YJIT project with 10+ years of JIT compiler experience and a team of skilled engineers, whereas AFAIK the Python JIT project was lead by a student. It was an uphill battle getting YJIT to work well at first. We needed grit and I pushed for a very data-driven approach so we could learn from our early failures and make informed decisions. Make of that what you will.
Yes Python is hard to optimize. I Still believe that a good JIT for CPython is very possible but it needs to be done right. Hire me if you want that done :)
Several talks about YJIT on YouTube for those who want to know more: https://youtu.be/X0JRhh8w_4I
Comment · 2 years ago
YJIT is optimized primarily for web workloads. We look at rails performance a lot, but also at various other libraries that are used in that context. If you look at the headline benchmarks at https://speed.yjit.org, it will give you an idea of what we're mostly focused on. This is in contrast with academic compiler project, which often focus on microbenchmarks and code that is very different from the code users actually run in practice.
YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle).
That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).
FWIW this post was very well received on the Rust subreddit. They loved it and it got over 350 upvotes, so that community definitely didn't receive it as some sort of attack on Rust.