Hacker News new | ask | show | jobs
by pizlonator 345 days ago
JIT and VM writer here. I’m also pretty clued in on how CPython works because I ported it to Fil-C.

I think if I was being paid to make CPython faster I’d spend at least a year changing how objects work internally. The object model innards are simply too heavy as it stands. Therefore, eliminating the kinds of overheads that JITs eliminate (the opcode dispatch, mainly) won’t help since that isn’t the thing the CPU spends much time on when running CPython (or so I would bet).
2 comments
kzrdude 345 days ago
Many changes of that kind have been made by the faster-cpython team I believe, Mark Shannon was rather focused on it (and had a decade of experience of that kind of tweaks to python).

But I'm trying to find/recall a blog post that detailed the different steps in shrinking the CPython object struct...

If you say that's not enough, more radical changes needed, I would understand.

link
pizlonator 344 days ago
Gotta be careful about the tone and mindset here.

Given any arbitrarily optimized thing, it is always possible to optimize it more. And the fact that it's possible to optimize it more is not meant as a criticism of folks who did the previous optimizations.

So, I have no doubt that Mark and others have worked on exactly the thing I'm talking about and that they've gotten wins. And I have no doubt that more can be done. Also, not saying I would do a better job at it than Mark or anyone else

link
cs_throwaway 345 days ago
Do you think it may be feasible to do this and maintain the FFI?
link
pizlonator 345 days ago
That's the hard part!

I think that the FFI makes it super hard to do most of the optimizations I'd want to do. Maybe it makes them impossible even. The game is to find any chance for size reduction and fast path simplification that doesn't upset FFI

link