logoalt Hacker News

cogman10 • today at 2:07 PM • 2 replies • view on HN

I think this is a major issue with requiring a PEP for what's a performance optimization.

JITs are big nasty things that by their nature have to do a lot of things. You are basically saying "Give us a PEP for a new python interpreter and compiler".

What they do is fuzzy by their nature because optimizations are very rarely universally beneficial. It's a game of measuring, looking for regressions, and tackling the biggest problem next for whatever sample applications you have available. You always run into the risk of overfitting on top of all that (You may have made django faster, but you've made flask slower).

This is the sort of thing that, IMO, should not go through the PEP process. It's an implementation detail for the runtime.

Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements. They'd never get done. Or if any javascript engine needed ECMA acceptance before they could do a new JIT optimization.


Replies

stickfigure • today at 2:21 PM

> Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements.

They do:

https://openjdk.org/jeps/197

https://openjdk.org/jeps/515

Not every optimization requires a JEP, but certainly something as big as "add or remove a JIT" would 100% require a JEP.

adrian17 • today at 2:19 PM

> Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements.

FWIW, I definitely can find a bunch of both PEPs and JEPs for internal optimizations, random examples:

https://peps.python.org/pep-0509/

https://openjdk.org/jeps/147

➕ show 1 reply