new | show | ask | jobs Github

redox99 20 hours ago

This seems like very low hanging fruit. How is the core loop not already hyper optimized?

I'd have expected it to be hand rolled assembly for the major ISAs, with a C backup for less common ones.

How much energy has been wasted worldwide because of a relatively unoptimized interpreter?

▲

Calavar 17 hours ago | parent | next [-]

Quite to the contrary, I'd say this update is evidence of the inner loop being hyperoptimized!

MSVC's support for musttail is hot off the press:

> The [[msvc::musttail]] attribute, introduced in MSVC Build Tools version 14.50, is an experimental x64-only Microsoft-specific attribute that enforces tail-call optimization. [1]

MSVC Build Tools version 14.50 was released last month, and it only took a few weeks for the CPython crew to turn that around into a performance improvement.

[1] https://learn.microsoft.com/en-us/cpp/cpp/attributes?view=ms...

▲

kccqzy 19 hours ago | parent | prev | next [-]

Python’s goal is never really to be fast. If that were its goal, it would’ve had a JIT long ago instead of toying with optimizing the interpreter. Guido prioritized code simplicity over speed. A lot of speed improvements including the JIT (PEP 744 – JIT Compilation) came about after he stepped down.

▲

int_19h 11 hours ago | parent | next [-]

I doubt it would have a JIT a long time ago. Thing is, people have been making JIT compilers for Python for a long time now, but the semantics of the language itself is such that it's often hard to benefit from it because most of the time isn't in the bytecode interpreter itself, it's dispatching things. People like comparing Python to JavaScript, but Python is much more flexible - all "primitive" types are objects can be subclassed for example, and even basic machinery like attribute lookups have a bunch of customization hooks.

So the problem is basically that a simple JIT is not beneficial for Python. So you have to invest a lot of time and effort to get a few percent faster on a typical workload. Or you have to tighten up the language and/or break the C ABI, but then you break many existing popular libraries.

	▲	pjmlp 3 hours ago \| parent [-]
		Those people usually overlook the history of Smalltalk, Self and Common Lisp, which are just as dynamic if not more, due to image use, debugging and compilation on the fly where anything can be changed at any time. For all its dynamism, Python doesn't have anything closer to becomes:. I would say that by now what is holding Python back is the C ABI and the culture that considers C code as Python.

▲

davidkhess 18 hours ago | parent | prev | next [-]

Should probably mention that Guido ended up on the team working on a pretty credible JIT effort. Though Microsoft subsequently threw a wrench in it with layoffs. Not sure the status now.

▲

pjmlp 3 hours ago | parent | prev | next [-]

He was part of the driving effort after joining Microsoft though.

▲

IshKebab 16 hours ago | parent | prev | next [-]

If performance was a goal... hell if it was even a consideration then the language would be very different.

▲

mhh__ 13 hours ago | parent | prev [-]

Python is full of decisions like this / or rather full of "if you just did some more work it'd be 10x better"

▲

pjc50 18 hours ago | parent | prev | next [-]

This is (a) wildly over expectations for open source and (b) a massive pain to maintain, and (c) not even the biggest timewaster of python, which is the packaging "system".

▲

loeg 17 hours ago | parent [-]

> not even the biggest timewaster of python, which is the packaging "system".

For frequent, short-running scripts: start-up time! Every import has to scan a billion different directories for where the module might live, even for standard modules included with the interpreter.

▲

tweakimp 16 hours ago | parent [-]

In the near future we will use lazy imports :) https://peps.python.org/pep-0810/

	▲	theLiminator 11 hours ago \| parent [-]
		This can't come soon enough. Python is great for CLIs until you build something complex and a simple --help takes seconds. It's not something easily worked around without making your code very ugly.

▲

WD-42 18 hours ago | parent | prev | next [-]

Probably because anyone concerned with performance wasn’t running workloads on Windows to begin with.

▲

pjmlp 17 hours ago | parent | next [-]

Games and Proton.

Apparently people that care about performance do run Windows.

▲

WD-42 17 hours ago | parent | next [-]

None of those games, or a very small amount of them, are written in python. None of the ones that need to be performant for sure.

	▲	int_19h 11 hours ago \| parent \| next [-]
		Games aren't written in Python as a whole, but Python is used as a scripting language. It's definitely less popular now than it used to be, mostly thanks to Lua, but it still happens.
	▲	pjmlp 15 hours ago \| parent \| prev [-]
		Indeed, but the question was about performance in general.