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

51–60 of 553 posts

Re: Python 3.13 Gets a JIT

#51

Post by kragen »

pjmlp wrote: post #50
kragen wrote: post #42

Earlier quoted context omitted.

when i wrote ur-scheme one of the surprising things i learned from it was that ahead-of-time compilation worked amazingly well for scheme. scheme is ruthlessly monomorphic but i was still doing a type check on every primitive argument i didn't realize they ever jitted newtonscript

NewtonScript 2.0 introduced a mechanism to manually JIT code, functions marked as native get compiled into machine code. Had the Newton not been canceled, probably there would be an evolution from that support. See "Compiling Functions for Speed" https://www.newted.org/download/manuals/NewtonToolkitUsersGu...

this is great, thanks! but it sounds like it was an aot compiler, not a jit compiler; for example, it explains that a drawback of compiling functions to native code is that they use more memory, and that the compiler still produces bytecode for the functions it compiles natively, unless you suppress the bytecode compilation in project settings

Re: Python 3.13 Gets a JIT

#52

Post by japanman185 »

pjmlp wrote: post #37
cqqxo4zV46cp wrote: post #16

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

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

Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks

Re: Python 3.13 Gets a JIT

#53

Post by helboi4 »

cturner wrote: post #33
irjustin wrote: post #13

Earlier quoted context omitted.

[flagged]

The article will be a confusing read to someone who does not know what a JIT is. Look at the paper after the heading "What is a JIT?" The first paragraph moves towards an answer - "compilation design that implies that compilation happens on demand when the code is run the first time" But then it backtracks on this and says that it could mean many things, and gets wishy-washy, and says that python is already a JIT. Th…

Yeah as a junior without a CS degree I was reading this article thinking "this is very interesting" but found it very hard to really grasp the difference between Ahead of Time and JIT from their explanations. Just that it was different from the previous python interpreter method, which seems woefully inefficient. I do know that Java has a JIT and I've read about this, but I guess it became quickly clear that I didn't really understand it since I couldn't follow this article. I think I will need to read more about this elsewhere and come back to fully grasp the impact.

Re: Python 3.13 Gets a JIT

#54

Post by pdimitar »

pjmlp wrote: post #37
cqqxo4zV46cp wrote: post #16

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

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

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.

Re: Python 3.13 Gets a JIT

#55

Post by pjmlp »

pdimitar wrote: post #54
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

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.

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.

Re: Python 3.13 Gets a JIT

#56

Post by pjmlp »

japanman185 wrote: post #52
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

Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks

Another one that hasn't seen UNIX scripting in shell languages or Perl, Apache modules, before Python came to be.

Re: Python 3.13 Gets a JIT

#57

Post by BossingAround »

japanman185 wrote: post #52
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

Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks

Facts are objective; "Python is awful" is your opinion.

Re: Python 3.13 Gets a JIT

#58

Post by pjmlp »

kragen wrote: post #51
pjmlp wrote: post #50

Earlier quoted context omitted.

NewtonScript 2.0 introduced a mechanism to manually JIT code, functions marked as native get compiled into machine code. Had the Newton not been canceled, probably there would be an evolution from that support. See "Compiling Functions for Speed" https://www.newted.org/download/manuals/NewtonToolkitUsersGu...

this is great, thanks! but it sounds like it was an aot compiler, not a jit compiler; for example, it explains that a drawback of compiling functions to native code is that they use more memory, and that the compiler still produces bytecode for the functions it compiles natively, unless you suppress the bytecode compilation in project settings

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.

Re: Python 3.13 Gets a JIT

#59

Post by Scarblac »

jampekka wrote: post #49
JodieBenitez wrote: post #35

Earlier quoted context omitted.

Because it's already fast enough for most of us ? Anecdote, but I've had my share of slow things in Javascript that are not slow in Python. Try to generate a SHA256 checksum for a big file in the browser... Good to see progress anyways.

Python's SHA256 is written in C. And I'd quess Web Crypto API for JS is in the same ballbark. SHA256 in pure Python would be unusably slow. In Javascript it would be at least usably slow. Javascript is fast. Browsers are fast.

The point of Python is quickly integrating a very wide range of fast libraries written in other languages though, you can't ignore that performance just because it's not written in Python.
Post reply on HN