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

521–530 of 553 posts

Re: Python 3.13 Gets a JIT

#521

Post by baja_blast »

MBCook wrote: post #471
Sohcahtoa82 wrote: post #335

Earlier quoted context omitted.

I'd love to see it eat JavaScript and Java for back-end code. But I doubt that's going to ever happen.

Despite the existence of WebAssembly, which some have suggested to be able to run a non-JS language, I just have a hard time seeing anything non-JS get popular for the web. The in browser debug/development environment just works too well. Short of Google implementing something if Chrome hits 85-90% of all use in an attempt to dump JS it just doesn’t seem like something that would happen. I doubt any browser team woul…

For Python to work in the browser via WebAssembly you'd need to have python itself compiled and running to execute python. It would consume a lot of energy and be much slower, I see no upsides. WebAssembly is meant to have lower level languages and programs run in the browser, not so Python devs do not have to learn a second language.

Plus Python is not suited for event driven systems.

Re: Python 3.13 Gets a JIT

#522

Post by zelphirkalt »

SJetKaran wrote: post #431
girvo wrote: post #420

Earlier quoted context omitted.

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?

similar with vim vs neovim as well

There is a significant portion of NeoVim users though.

Re: Python 3.13 Gets a JIT

#523

Post by monocasa »

bonzini wrote: post #360
vanderZwan wrote: post #82

I think it's really cool that Haoran Xu and Fredrik Kjolstad's copy-and-patch technique[0] is catching on, I remember discovering it through Xu's blog posts about his LuaJIT remake project[1][2], where he intends to apply these techniques to Lua (and I probably found those through a post here). I was just blown away by how they "recycled" all these battle-tested techniques and technologies, and used it to synthesize…

Copy and patch is a variant of QEMU's original "dyngen" backend by Fabrice Bellard[1][2], with more help from the compiler to avoid the maintainability issues that ultimately led QEMU to use a custom code generator. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu... [2] https://review.gerrithub.io/plugins/gitiles/spdk/qemu/+/5a24...

Which itself is how I understand the compilation step of quaject code in the synthesis kernel to have worked. Ie. do constant propagation and dead code elimination on the input format, and use a simple template driven backend to dump out native machine code.

In fact I wouldn't be surprised if the earliest compilers were template based, as that's about the only implementation that would fit in a RAM as a compiler pass.

Re: Python 3.13 Gets a JIT

#524

Post by IshKebab »

soulbadguy wrote: post #403
IshKebab wrote: post #179

Earlier quoted context omitted.

Two reasons: 1. Javascript is a less dynamic language than Python and numbers are all float64 which makes it a lot easier to make fast. 2. If you want to run fast code on the web you only have one option: make Javascript faster. (Ok we have WASM now but that didn't exist at the time of the Javascript Speed wars.) If you want to run fast code on your desktop you have a MUCH easier option: don't use Python.

> Javascript is a less dynamic language than Python I have seen this mentioned multiple times, someone as a good reference explaining what makes python more dynamic than JS ?

It just has many features that can be overridden with Python code so they can have any behaviour at runtime. For example when you access an object attribute it can literally do anything: https://docs.python.org/3/reference/datamodel.html#customizi...

You could probably optimistically optimise some code, assuming it doesn't use any of the dynamic features of Python. You're going to get crazy performance cliffs though.

Re: Python 3.13 Gets a JIT

#525

Post by pletnes »

matt_trentini wrote: post #474
systems wrote: post #204

Earlier quoted context omitted.

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

Python disliked? That doesn't resonate with my experience or repeated Stack Overflow surveys where Python is often near the top in admired and desired languages: https://survey.stackoverflow.co/2023/#section-admired-and-de...

At the same time, if 1% of python programmers dislike it, then there are more dissatisfied python programmers than there are programmers in total for most other languages.

Re: Python 3.13 Gets a JIT

#527

Post by cycomanic »

hartator wrote: post #369
EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being significantly faster. Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...

The reference really doesn't say what you posted. It just says that python 3.6 was up to 45% faster than 2.7 on some benchmarks and up to 54% slower on some others (which the author of the suite considered largely unrealistic).

Where is the evidence that before python 3 was significantly slower than 2.7 before 3.6?

Re: Python 3.13 Gets a JIT

#528

Post by kaashif »

moomin wrote: post #442
ummonk wrote: post #429

Earlier quoted context omitted.

Not if “faster” refers to computation rate rather than runtime, in which case it becomes 100/81 i.e. 23% faster.

Yes, but I’ve literally never heard anyone say that.

It's not really possible to tell if someone saying "50% faster" means a 50% speed increase or a 50% time decrease.

Even in other contexts it can be ambiguous.

Yesterday I drove 60mph, today I drove 50% faster.

Yesterday I got there in 1 hour, today I got there 50% faster.

It's not really possible to tell them apart without looking at the numbers.

Re: Python 3.13 Gets a JIT

#530

Post by kstrauser »

onetoo wrote: post #390
edgyquant wrote: post #388

Earlier quoted context omitted.

I hate this argument that “most web apps don’t need that kind of performance.” For one thing, with responsive apps that are the norm it wouldn’t be surprising for a session to begin with multiple requests or to even have multiple requests per second. At that point all it takes is a few hundred active users to hit that 1k limit. But even leaving that aside, you never know when your application will be linked somewhere…

I didn't say python can handle =1K. I feel confident that I am orders of magnitude off the real limit you'd meet. The specifics of that aside, any unprepared application is going to buckle at a sudden mega-surge of users. The solution remains largely the same, regardless of technology: Make sure everything that can be cached is cached, scale the hardware vertically until it stops helping, optimize your code, scale ho…

At one shop, our load tests targeted 300,000 POST requests per second with a relatively small number of load balanced servers.

You wouldn’t want to have a long, complex call path through that code, but just parsing the body and adding it to a Celery queue before returning a 201 Created was perfectly manageable.

Post reply on HN