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

Python 3.13 Gets a JIT

tonybaloney.github.io

Post reply on HN
Print view View original

201–210 of 553 posts

Re: Python 3.13 Gets a JIT

#201

Post by Ringz »

Joker_vD wrote: post #183
guenthert wrote: post #171

Earlier quoted context omitted.

To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.

But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?

Yep. Therefore it’s better to

   def twice(x: int) -> int:
   if not isinstance(x, int):
           raise TypeError("Expected x to be an int, got " + str(type(x)))
    return x + x

Re: Python 3.13 Gets a JIT

#202

Post by sylware »

ageitgey wrote: post #3

For the lazy who just want to know if this makes Python faster yet, this is foundational work to enable later improvements: > The initial benchmarks show something of a 2-9% performance improvement. > I think that whilst the first version of this JIT isn’t going to seriously dent any benchmarks (yet), it opens the door to some huge optimizations and not just ones that benefit the toy benchmark programs in the standar…

I removed the SDKs of some big (big for the wrong reasons) open source projects which generates a lot of code using python3 scripts.

In those custom SDKs, I do generate all the code at the start of the build, which takes a significant amount of time for mostly non-pertinent anymore/inappropiately done code generation.. I will really feel python3 speed improvement for those builds.

Re: Python 3.13 Gets a JIT

#203

Post by bjackman »

cryptos wrote: post #6

I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.

JavaScript has to be fast because its users were traditionally captive on the platform (it was the only language in the browser).

Python's users can always swap out performance critical components to another language. So Python development delivered more when it focussed on improving strengths rather than mitigating weaknesses.

In a way, Python being slow is just a sign of a healthy platform ecosystem allowing comparative advantages to shine.

Re: Python 3.13 Gets a JIT

#204

Post by systems »

wrd83 wrote: post #17

Honestly I don't understand the pessimistic view here. I think every release since Microsoft started funding python has increased high single digit best case performance. Rather than focussing on the raw number compare to python 3.5 or so. It's still getting significantly faster. If they keep doing this steady pace they are slowly saving the planet!

I think the pessimism really comes from a dislike for Python

While very very very popular, Python is i think is very disliked languages, it doesnt have or it is not built around the current programming language features that programmers like, its not functional or immutable by default, its not fast, the tooling is complex, it uses indentation for code blocks (this feature was cool in the 90s, but dreaded since at least 2010)

so i guess if python become fasters, this will ensure its continued dominance, and all those hoping that one day it will be replace by a nicer , faster language are disappointed

this pessimism is the aching voice of the developers who were hoping for a big python replacement

Re: Python 3.13 Gets a JIT

#205

Post by mg »

onetoo wrote: post #96
mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

The restart isn't expensive in absolute terms, on a human level it's practically instant. You would only do this during development, hopefully your local machine isn't the production environment. It's also very easy, often just adding a CLI flag to your local run command. edit: Regarding performance, Python today can easily handle at least 1k requests per second. The vast vast vast majority of web applications today…

The thing is, I don't run my applications locally with a "local run command".

I prefer to have a local system set up just like the production server, but in a container.

Maybe using WSGI with MaxConnectionsPerChild=1 could be a solution? But that would start a new (for example) Django instance for every request. Not sure how fast Django starts.

Another option might be to send a HUP signal to Apache:

    apachectl -k restart
That will only kill the worker threats. And when there are none (because another file save triggered it already), this operation might be almost free in terms of resource usage. This also would require WSGI or similar. Not sure if that is the standard approach for Django+Apache.

Re: Python 3.13 Gets a JIT

#206

Post by amelius »

CJefferson wrote: post #21
cryptos wrote: post #6

I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.

A big part of what made Python so successful was how easy it was to extend with C modules. It turns out to be very hard to JIT Python without breaking these, and most people don’t want a Python that doesn’t support C extension modules. The JavaScript VMs often break their extensions APIs for speed, but their users are more used to this.

On the other hand, rewriting the C modules and adapting them to a different C API is very straightforward after you've done 1 or 2 of such modules. Perhaps it's even something that could be done by training an LLM like Copilot.

Re: Python 3.13 Gets a JIT

#207

Post by cuchoi »

Difwif wrote: post #169
guenthert wrote: post #108

Earlier quoted context omitted.

Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code. That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more…

AFAIK good JITs like V8 can do runtime introspection and recompile on the fly if types change. Maybe using the type hints will be helpful but I don't think they are necessary for significant improvement.

Doesn't Python already do this? https://www.youtube.com/watch?v=shQtrn1v7sQ

Re: Python 3.13 Gets a JIT

#208

Post by oblio »

guappa wrote: post #197
oblio wrote: post #143

Earlier quoted context omitted.

Do a quick test with the latest JVM. Print Hello, world. That's it. Time it. Do the same with Python. The difference is minuscule. People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.

> Do a quick test with the latest JVM. java: 031s python: 013s it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower. 3x slower isn't my definition of minuscule.

> java: 031s python: 013s

I'm confused, what kind of time measurement system is this? Are those 31 seconds versus 13 seconds? 0.31s vs 0.13s? If it's the first case, something is wrong with that machine, Hello World should not take that long. If it's the second, are we talking about 0.18s? See below.

> it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower.

I don't know how you write your scripts, but in practice most scripts hang waiting for IO (especially network) or waiting for a specific command to process something...

> 3x slower isn't my definition of minuscule.

Nope, but based on what you've presented so far, unless I'm misunderstanding, it's my definition of "premature optimization".

Re: Python 3.13 Gets a JIT

#209

Post by JodieBenitez »

jampekka wrote: post #198
JodieBenitez wrote: post #157

Earlier quoted context omitted.

Not so bad compared to what I tried a few years ago. Might finally be usable for us...

All major browsers have supported it for over eight years. Maybe the problem was between the seat and the keyboard? https://caniuse.com/mdn-api_crypto_subtle

Maybe 8 years is not much in a career ? Maybe we had to support one of those browsers that did not support it ? Maybe your snarky comment is out of place ? And even to this day it's still significantly slower than Python stdlib according to the tester. So much for "why python not as fast as js, python is slow, blah blah blah".

Re: Python 3.13 Gets a JIT

#210

Post by eesmith »

pjmlp wrote: post #145
eesmith wrote: post #62

Earlier quoted context omitted.

I think Python without a JIT in many cases is already fast enough for most cases. I don't do data science.

Sure, for UNIX scripting, for everything else it is plainfully slow. I know Python since version 1.6, and is my scripting language in UNIX like environments, during my time at CERN, I was one of the CMT build infrastructure build engineer on the ATLAS team. It was never been the language I would reach for when not doing OS scripting, and usually when a GNU/Linux GUI application happens to be slow as mollasses, it has…

There's a lot of Django going on in the world.

shrug. If we're talking personal experience, I've been using Python since 1.4. It's been my primary development language since the late 1990s, with of course speed critical portions in C or C++ when needed - and I know a lot of people who also primarily develop in Python.

And there's a bunch of Python development at CERN for tasks other than OS scripting. ("The ease of use and a very low learning curve makes Python a perfect programming language for many physicists and other people without the computer science background. CERN does not only produce large amounts of data. The interesting bits of data have to be stored, analyzed, shared and published. Work of many scientists across various research facilities around the world has to be synchronized. This is the area where Python flourishes" - https://cds.cern.ch/record/2274794)

I simply don't see how a Python JIT is going to make that much of a difference. We already have PyPy for those needing pure Python performance, and Numba for certain types of numeric needs.

PyPy's experience shows we'll not be expecting a 5x boost any time soon from this new JIT framework, while C/C++/Fortran/Rust are significantly faster.

Post reply on HN