kenjin4096

30 ms·

1.
by kenjin4096 1mo ago
Woops, I meant to write tail call optimization not tail calls. Shouldn't have used the term interchangeably. Yeah I'm aware that C doesn't have proper tail calls. Thanks for the correction though.
2.
by kenjin4096 1mo ago
I think Anton is replying to me in that LWN article IIRC. I personally didn't know C only had tail calls that late and learnt something new there! On the other hand, I am pretty new to the compiler space myself, and I count early 2000s
3.
by kenjin4096 2mo ago
This is an intuitive step and I kind of did something similar initially (I simplified the diagram a lot, but it was basically what you are suggesting). However, it slowed down the computed goto interpreter by 6% (though not the tail calling
4.
by kenjin4096 2mo ago
Pablo is a great speaker and I love Tachyon! However, this is a different type of/target for profiling. Tachyon profiles the entire CPython interpreter, this blog post is just type profiling/recording and interpreter path profilin
5.
by kenjin4096 6mo ago
Update: I put up a PR to document the trace recording interpreter https://github.com/python/cpython/pull/146110
6.
by kenjin4096 6mo ago
> I've never seen where the high level discussions were happening Thanks for your interest. This is something we could improve on. We were supposed to document the JIT better in 3.15, but right now we're crunching for the 3.15
7.
by kenjin4096 6mo ago
I implemented most of the tracing JIT frontend in Python 3.15, with help from Mark to clean up and fix my code. I also coordinated some of the community JIT optimizer effort in Python 3.15 (note: NOT the code generator/DSL/infra,
8.
by kenjin4096 9mo ago
Tier-ups for trace-based JITs have been explored before. You can find an example here https://dl.acm.org/doi/abs/10.1145/2398857.2384630 I know LBBV isn't technically tracing, but it's quite similar
9.
by kenjin4096 9mo ago
> Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. Sorry but unless your workload is some C API numpy number cruncher that just does matmuls on the CPU, that's
10.
by kenjin4096 9mo ago
Woops, thanks for noticing, fixed!
11.
by kenjin4096 9mo ago
Yeah, I believe that statement and it seems to hold true for MSVC as well. Thanks for your work inspiring all of this btw!
12.
by kenjin4096 9mo ago
Thank you very much for the kind words, that means a lot to me!
13.
by kenjin4096 9mo ago
So it seems I was wrong, [[msvc::musttail]] is documented! I will update the blog post to reflect that. https://news.ycombinator.com/item?id=46385526
14.
by kenjin4096 9mo ago
Thanks :), that was indeed my intention. I think the previous 3.14 mistake was actually a good one on hindsight, because if I didn't publicize our work early, I wouldn't have caught the attention of Nelson. Nelson also probably wo
15.
by kenjin4096 9mo ago
Thanks for reading! For now, we maintain all 3 of the interpreters in CPython. We don't plan to remove the other interpreters anytime soon, probably never. If MSVC breaks the tail calling interpreter, we'll just go back to buildin
16.
by kenjin4096 9mo ago
Got it. I'll try to set one up this weekend.
17.
by kenjin4096 9mo ago
I'm the author of the thread you linked. Community stewardship is actually happening in some form or another now. 3.15 has some JIT upgrades that are in-progress. This has a non-exhaustive list of them https://docs.python.or
18.
by kenjin4096 1y ago
Hey Maxime! > whereas AFAIK the Python JIT project was lead by a student. I am definitely not leading the team! I am frankly unqualified to do so lol. The team is mostly led by Mark Shannon, who has 10+ years of compiler/static anal
19.
by kenjin4096 1y ago
Hi, author of the post here, stability indeed has been a priority. There are some points which are not exactly the case though: > - Most of the work has just been plumbing. Int/float unboxing, smarter register allocation, free-threa
20.
by kenjin4096 2y ago
This is a good point. We already observed this in our LTO and PGO builds for the computed goto interpreter. On modern compilers, each LTO+PGO build has huge variance (1-2%) for the CPython interpreter. On macOS, we already saw a huge regres
21.
by kenjin4096 2y ago
That's a fair question. The blog post mentions it brings a 1-5% perf improvement. Which is still significant for CPython. It does not complicate the source because we use a DSL to generate CPython's interpreters. So the only compl
22.
by kenjin4096 2y ago
We don't normally test with bleeding-edge compilers on the faster cpython benchmarks page because that would invalidate historical data. E.g. if 2 years ago we used GCC 11 or something to compile and run a benchmark, we need to run it
23.
by kenjin4096 2y ago
Hello. I'm the author of the PR that landed the tail-calling interpreter in CPython. First, I want to say thank you to Nelson for spending almost a month to get to the root of this issue. Secondly, I want to say I'm extremely emba