Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

fidget-spinner.github.io

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#121

Post by cpburns2009 »

nikisweeting wrote: post #117
_ZeD_ wrote: post #61

Earlier quoted context omitted.

keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript. Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution. Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how f…

genuinely curious, doesn't JS's proxy objects and prototype-based MRO have a similar performance impact in theory?

Yeah, I don't see how Python is fundamentally different from JavaScript as far as dynamicism goes. Sure Python has operator overloading, but JavaScript would implement those as regular methods. Pyrhon's init & new aren't any more convoluted than JavaScript's constructors. Python may support multiple inheritance but method and attribute resolution just uses the MRO which is no different than JavaScript's prototype chain.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#122

Post by DrewADesign »

NetMageSCW wrote: post #86
DrewADesign wrote: post #68

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

Depending on how important the GUI is to you, I would look into LINQPad for stuff that is scripting but too heavy.

Looks neat!

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#123

Post by titzer »

boulos wrote: post #84
pjmlp wrote: post #81

Earlier quoted context omitted.

I know what happened last year, my point was the prior history that lead to that effort. https://thenewstack.io/guido-van-rossums-ambitious-plans-for... Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts. And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as…

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime. Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simp…

> you also saw the V8 folks give up and make Dart

V8 still got substantially faster after the first team left to do Dart. A lot of runtime optimizations (think object model optimizations), several new compilers, and a lot of GC work.

It's a huge investment to make a dynamic language go as fast as JS these days.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#124

Post by eru »

tom_ wrote: post #114
kenjin4096 wrote: post #98

Earlier quoted context omitted.

> 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 probably false. In 3.11 alone, CPython sped up by around 25% over 3.10 on pyperformance for x86-64 Ubuntu. https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-fas... 3.14 is 35-45% f…

As a data point, running a Python program I've been working on lately, which is near enough entirely Python code, with a bit of I/O: (a prototype for some code I'll ultimately be writing in a lower-level language) (macOS Ventura, x64) - System python 3.9.6: 26.80s user 0.27s system 99% cpu 27.285 total - MacPorts python 3.9.25: 23.83s user 0.32s system 98% cpu 24.396 total - MacPorts python 3.13.11: 15.17s user 0.28s…

> [...] and I've just assumed the performance will still be as limited as it always has been...!)

Historically CPython performance has been so bad, that massive speedups were quite possible, once someone seriously got into it.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#125

Post by eru »

titzer wrote: post #123
boulos wrote: post #84

Earlier quoted context omitted.

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime. Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simp…

> you also saw the V8 folks give up and make Dart V8 still got substantially faster after the first team left to do Dart. A lot of runtime optimizations (think object model optimizations), several new compilers, and a lot of GC work. It's a huge investment to make a dynamic language go as fast as JS these days.

> It's a huge investment to make a dynamic language go as fast as JS these days.

Yes, and on the other hand, other language implementations like CPython can learn from everything people figured out for JS.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#126

Post by nurettin »

pjmlp wrote: post #45
publicdebates wrote: post #15

Earlier quoted context omitted.

Important enough, or benefits them directly? I have no good guesses how improving Python's performance would benefit them, but I would guess that's the real reason.

Microsoft was the one hiring Guido out of retirement, and alongside Facebook finally kicking off the CPython JIT efforts. Python is one of the Microsoft blessed languages on their devblogs.

+ It is also blessed by PowerBI and recently, Excel.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#127

Post by pjmlp »

kccqzy wrote: post #13
redox99 wrote: post #7

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?

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.

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

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#128

Post by pjmlp »

int_19h wrote: post #102
kccqzy wrote: post #13

Earlier quoted context omitted.

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.

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 c…

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.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#129

Post by pjmlp »

everforward wrote: post #87
pansa2 wrote: post #67

Earlier quoted context omitted.

> I would also say there’s generally less impetus to optimize CPython Nonetheless, Microsoft employed a whole "Faster CPython" team for 4 years - they targeted a 5x speedup but could only achieve ~1.5x. Why couldn't they make a significantly faster Python implementation, especially given that PyPy exists and proves it's possible?

Pypy has much slower C interop than CPython, which I believe is part of the tradeoff. Eg data analysis pipelines are probably still faster in numpy on CPython than pypy. Not an expert here, but my understanding is that Python is dynamic to the point that optimizing is hard. Like allowing one namespace to modify another; last I used it, the Stackdriver logging adapter for Python would overwrite the stdlib logging libr…

See Smalltalk, Self and Common Lisp, and you will find languages that are even more dynamic than Python, and are in the genesis of high performance JIT research.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#130

Post by pjmlp »

pansa2 wrote: post #89
canucker2016 wrote: post #77

Earlier quoted context omitted.

Don't forget that there was a Google attempt at making a faster Python - Unladen Swallow. It got lots of PR but never merged with mainline CPython (wikipedia says a dev branch was released). see https://en.wikipedia.org/wiki/Unladen_Swallow

Unladen Swallow got a lot of hype but was only a very small project. IIRC the only people working on it were two interns. V8 was a much higher priority - Google hired many of the world’s best VM engineers to develop it.

Some of them like Lars Bak, have background up to Self VM, which is a language much more dynamic than Python.

Anything goes regarding changing object shapes, it is one step further than Smalltalk in language plasticity.

Post reply on HN