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

141–150 of 553 posts

Re: Python 3.13 Gets a JIT

#141

Post by pjmlp »

fnord123 wrote: post #101
pjmlp wrote: post #37

Earlier quoted context omitted.

It is a very big deal, as it will finally shift the mentality regarding: - "C/C++/Fortran libs are Python" - "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment

> it will finally shift the mentality regarding "C/C++/Fortran libs are Python" But pjmlp, I use Python because it's a wrapper for C/C++/Fortran libs. - Chocolate Giddyup

Just like Tcl happens to be.

Re: Python 3.13 Gets a JIT

#142

Post by skriticos2 »

dagw wrote: post #26
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.

anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes. There are a lot of faster python runtimes out there. Both Google and Instagram/Meta have done a lot of work on this, mostly to solve internal problems they've been having with python performance. Microsoft has also done work on parallel python. There's PyPy and Pythran and no doubt several others. However none of these attempts h…

JS also had the major advantage of being sandboxed by design, so they could work from there. Most of the technical legacy centered around syntax backwards compatibility, but it's all isolated - so much easier to optimize.

Python with it's C API basically gives you the keys to the kingdom on a machine code level. Modifying something that has an API to connect to essentially anything is not an easy proposition. Of course, it has the advantage that you can make Python faster by performance analysis and moving the expensive parts to optimized C code, if you have the resources.

Re: Python 3.13 Gets a JIT

#143

Post by oblio »

guappa wrote: post #112
oblio wrote: post #104

Earlier quoted context omitted.

JS V8, Java (any JVM), .NET use JITs. If those aren't solid proving grounds for JITs, nothing is.

And nobody writes short lived commands in those because of startup time.

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.

Re: Python 3.13 Gets a JIT

#144

Post by pjmlp »

kragen wrote: post #79
pjmlp wrote: post #58

Earlier quoted context omitted.

Yeah, I guess if one wants to go more technical, I see it as the first step of a JIT that didn't had the opportunity to evolve due to market decisions.

i guess if they had, we would know whether a jit made newtonscript faster or slower, but they didn't, so we don't. what we do know is that an aot compiler sometimes made newtonscript faster (though maybe only if you added enough manifest static typing annotations to your source code) that seems closer to the opposite of what you were saying in the point on which we were in disagreement?

I guess my recolection regarding NewtonScript wasn't correct, if you prefer that I put it like that, however I am quite certain in regards to the other languages in my list.

Re: Python 3.13 Gets a JIT

#145

Post by pjmlp »

eesmith wrote: post #62
pjmlp wrote: post #55

Earlier quoted context omitted.

Python with JIT is faster than Python without JIT. Having a Python with JIT, in many cases it will be fast enough for most cases. Data science running CUDA workloads isn't the only use case for Python.

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 been written in Python.

Re: Python 3.13 Gets a JIT

#146

Post by a-french-anon »

guenthert wrote: post #108
blagie wrote: post #65

Earlier quoted context omitted.

From the write-up, I honestly don't understand how this paves the way. I don't see an architectural path from a cut-and-paste JIT to something optimizing. That's the whole point of a cut-and-paste JIT.

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…

Isn't CL a good counter-example to that "dynamism inherently stunts performances" mantra?

Re: Python 3.13 Gets a JIT

#147

Post by AndrewDucker »

dagw wrote: post #140
AndrewDucker wrote: post #127

Earlier quoted context omitted.

Why are you assuming that they'd have to rewrite all of their libraries? I don't see anything in the article that says that.

The reason this approach is so much slower than some of the other 'fast' pythons out there that have come before is that they are making sure you don't have to rewrite a bunch of existing libraries. That is the problem with all the fast python implementations that have come before. Yes, they're faster than 'normal' python in many benchmarks, but they don't support the entire current ecosystem. For example Instagram's…

Aaah, so it's not this approach that you're saying is an issue, it's the ones that significantly change Python. Gotcha, that makes sense. Thank you.

Re: Python 3.13 Gets a JIT

#148

Post by kragen »

pjmlp wrote: post #144
kragen wrote: post #79

Earlier quoted context omitted.

i guess if they had, we would know whether a jit made newtonscript faster or slower, but they didn't, so we don't. what we do know is that an aot compiler sometimes made newtonscript faster (though maybe only if you added enough manifest static typing annotations to your source code) that seems closer to the opposite of what you were saying in the point on which we were in disagreement?

I guess my recolection regarding NewtonScript wasn't correct, if you prefer that I put it like that, however I am quite certain in regards to the other languages in my list.

i agree that the other languages gained a lot for sure

maybe i should have said that up front!

except maybe common lisp; all the implementations i know are interpreted or aot-compiled (sometimes an expression at a time, like sbcl), but maybe there's a jit-compiled one, and i bet it's great

probably with enough work python could gain a similar amount. it's possible that work might get done. but it seems likely that it'll have to give up things like reference-counting, as smalltalk did (which most of the other languages never had)

Re: Python 3.13 Gets a JIT

#149

Post by pas »

superlopuh wrote: post #78
pdimitar wrote: post #54

Earlier quoted context omitted.

What do you mean by "it will shift the mentality"? There is no magical JIT that will ever make e.g. the data science Python & C++ amalgamations slower than a pure Python. Likely never happening, too. Also no mentality shift is expected on the "Python is too dynamic" -- which is a strange thing to say anyway -- because Python is not getting any more static due to these JIT news.

I'm fairly certain that this is false, and am working on proving it. In the cases that Numba is optimised for it's already faster than plausible C++ implementations of the same kernels. https://stackoverflow.com/questions/36526708/comparing-pytho...

it's not faster, it's about as fast as C++ compiled with O3 optimizations. which is great and also much more likely to be true.

Re: Python 3.13 Gets a JIT

#150

Post by formerly_proven »

lifthrasiir wrote: post #91
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…

An important context here is that the same code was reused for interpreter and JIT implementations (that's a main selling point for copy-and-patch JIT). In the other words, this 2--9% improvement mostly represents the core interpreter overhead that JIT should significant reduce. It was even possible that JIT itself might have no performance impact by itself, so this result is actually very encouraging; any future opc…

Copy&patch seems not much worse than compiling pure Python with Cython, which roughly corresponds to "just call whatever CPython API functions the bytecode interpreter would call for this bunch of Python", so that's roughly a baseline for how much overhead you get from the interpeter bit.
Post reply on HN