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

511–520 of 553 posts

Re: Python 3.13 Gets a JIT

#511

Post by hyperman1 »

rpeden wrote: post #417
PeterisP wrote: post #358

Earlier quoted context omitted.

TIL! I had used qbasic back in school, but I somehow always assumed that these basics were interpreters.

QBasic was a slightly cut down version of Quickbasic that didn't include the compiler, so your assumption was correct in that case. QBasic was bundled with DOS but you had to buy Quickbasic.

I always assumed, because they where so similar, that they both were compilers, generating executable code in memory. qbasic just had the option to write a standalone .exe removed. I just saw the quickbasic compiler output, though, no idea if this guess is true. Now I wonder if a compiled executable was faster than an in-memory application.

Re: Python 3.13 Gets a JIT

#512

Post by nerdponx »

[deleted] wrote: post #507

[deleted]

Indeed, this is exactly the kind of workload where PyPy historically outperformed CPython by a long shot.

I think there have been incremental optimizations in the bytecode interpreter for things like this in recent versions, but a JIT is going to be a real game-changer.

It will be interesting to see what happens to the PyPy project after this, as well as the HPy C API effort.

Re: Python 3.13 Gets a JIT

#513

Post by vips7L »

guappa wrote: post #497
oblio wrote: post #489

Earlier quoted context omitted.

I haven't written Java as my day to day for about 5 years. Instead I write... Python :-) It's just that I recognize disingenuous comments. Java is perfectly adequate as a language for writing command line tools. You're likely using one of them weekly and don't even know it. Just don't write your Java CLIs using Spring or DI frameworks in general :-)

> You're likely using one of them weekly and don't even know it. doubtful, since I don't have jre installed. I had to install it just to run that benchmark.

Modern Java tools bundle the runtime.

Re: Python 3.13 Gets a JIT

#514

Post by edgyquant »

girvo wrote: post #420
nextaccountic wrote: post #376

Earlier quoted context omitted.

This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)

It's fascinating to me that this process seems to rhyme with that of the path PHP took, with HHVM being built as a second implementation, proving that PHP could be much faster -- and the main project eventually adopting similar approaches. I wonder if that's always likely to happen when talking about languages as big as these are? Can a new implementation of it ever really compete?

Probably. Without a second implementation proving it out the bureaucracy can write it off as not possible and the demand may be less just because users don’t know what they’re missing

Re: Python 3.13 Gets a JIT

#516

Post by Twirrim »

nextaccountic wrote: post #466
remram wrote: post #448

Earlier quoted context omitted.

Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.

The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard) I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy

It's fine with C packages these days, it's increasingly rare to find libraries that it won't work with.

That said, it has happened often enough I'm cautious about where I use it. It would suck to be dependent on pypy's excellent performance, and then find I can't do something due to library incompatibility.

Re: Python 3.13 Gets a JIT

#517

Post by robertlagrant »

fnord123 wrote: post #97

This could be headed for another dead end imo. Context: I use python for data processing and webdev. When doing data processing, Python is merely glue for libraries in compiled languages. When doing webdev, I mostly use python itself. First, any numbers regarding benchmarks need to be treated with contempt. JITs are unbenchmarkable. No matter what you do, someone says you do it wrong. Warmed up the JIT? You did it wr…

> So why not make this AOT so I can add it to a docker build step and get all the benefit without the complications of tracing jits.

I've also thought this. If you're pre-baking your software, why not do this step as well?

Re: Python 3.13 Gets a JIT

#518

Post by remram »

nextaccountic wrote: post #493
eyegor wrote: post #481

Earlier quoted context omitted.

In my experience, pypy works with basically everything these days. I remember having some struggles with a weird fortran based extension module a few years ago, but it might work now too. Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible). https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...

The point of using C extensions is to have better performance. Python is already slow in general; code that use such extensions typically depend on this performance to not be unbearable (such as data science) People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting. I was speculating that in the future, C extensions in pypy would be fast…

C extensions are fast if you use cffi. It's when it has to emulate CPython to run extensions written against CPython, that it is slow.

Please do not phrase that as a failure of Pypy. That is so weird.

Re: Python 3.13 Gets a JIT

#519

Post by mattip »

t43562 wrote: post #343

I wish the money could be spent on PyPy but pypy has its problems - you don't get a big boost on small programs that run often because the warmup time isn't that fabulous. For larger programs like you sometimes it some incredibly complicated incompatibility problem. For me bitbake was one of those - could REALLY benefit from pypy but didn't work properly and I couldn't fix it. If this works more reliably or has a fas…

PyPy dev here. A little money could go along way to speeding up the PyPy base interpreter. Right now PyPy has no active income.

Re: Python 3.13 Gets a JIT

#520

Post by baja_blast »

treyd wrote: post #441
politelemon wrote: post #333

Earlier quoted context omitted.

Javascript, if it becomes viable for web development?

It already is as viable for web development as JS is.

Javascript works in browsers though, and it's a better async language that makes javascript APIs superior to Python.
Post reply on HN