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

Python 3.15's JIT is now back on track

fidget-spinner.github.io

Post reply on HN
Print view View original

311–320 of 330 posts

Re: Python 3.15's JIT is now back on track

#311

Post by coldtea »

mathisfun123 wrote: post #305
coldtea wrote: post #274

Earlier quoted context omitted.

"The way our economy works is bad" "That's how it's been since forever, it's an essential part of country X" "Yes, and it's a badly designed part". "But now you are no longer talking about the way country X works, but the way you want country X to work - and that has nothing to do with country X." See how the argument quickly degenerates?

ok then be the change you want to see in the world and send a PR instead of just proclaiming things lololol

A, the idiotic "it's FOSS, send a PR" argument, lololol

Re: Python 3.15's JIT is now back on track

#312

Post by BerislavLopac »

LtWorf wrote: post #267
BerislavLopac wrote: post #246

Earlier quoted context omitted.

> A Python4 that actually used typing in the interpreter, had value types, had a comptime phase to allow most metaprogramming to work (like monkey patching for tests) would be great! It would be faster, cleaner, easier to reason about, and still retain the great syntax and flexibility of the language. And what prevents someone from designing such a language?

PSF has full time employees. If someone else does it as a personal project it would remain a personal project and we'd never hear about it.

Python, Linux and most other great open source projects we all use today started as personal projects.

Re: Python 3.15's JIT is now back on track

#313

Post by 3form »

teleforce wrote: post #283
rtpg wrote: post #159

Earlier quoted context omitted.

In Python attribute access aren't stable! `self.x` where `x` is a property is not guaranteed to refer to the same thing. And getting rid of descriptors would be a _fundamental change to the language_. An immeense one. Loads of features are built off of descriptors or descriptor-like things. And what you're complaining about is also not true in Javascript world either... I believe you can build descriptor-like things…

>Remember, this is a scripting language, not a compiled language This is the fundamental issue and "elephant in the room" that everyone is seems to be overlooking, and putting under the carpet. The extreme compiled type language guys going gung-ho with very slow to compile and complicated Rust (moreso than C++), while the rest of the world gladly hacking their shiny ML/AI codes in scripting language aka Python "the g…

> In ten years time people will most probably look in horror at their python software stacks tech debt that they have to maintain for the business continuity

Yes, like they did for JavaScript!

Re: Python 3.15's JIT is now back on track

#314

Post by bjourne »

anematode wrote: post #166
dekelpilli wrote: post #149

Earlier quoted context omitted.

Java also has a performance cost to accessing class fields, as exampled by this (now-replaced) code in the JDK itself - https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/...

Any decent JIT compiler (and HotSpot's is world class) will optimize this out. Likely this was done very early on in development, or was just to reduce bytecode size to promote inlining heuristics that use it

Untrue. Objects and attributes may be shared by threads so attribute accesses can't in general be localized.

Re: Python 3.15's JIT is now back on track

#315

Post by oblio »

drob518 wrote: post #260
oblio wrote: post #256

Earlier quoted context omitted.

If you're a contributor to Python, my apologies.

I’m not a Python contributor, so no need to apologize to me. But if you have strong ideas about what Python should be, perhaps you should step up and contribute that code rather than saying that others are offering excuses for why they won’t deliver what you want. I have worked on other open source projects where users were very entitled, to the point of demanding that the project team deliver them certain features.…

This comment said it best: https://news.ycombinator.com/item?id=47428341

Re: Python 3.15's JIT is now back on track

#316

Post by 7bit »

0xffff2 wrote: post #286
phkahler wrote: post #275

Earlier quoted context omitted.

>> Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Then it wouldn't be Python any more.

Fine by me. I don't particularly like Python, but it's the defacto standard in my field so I have to use it (admittedly this is an improvement over a decade ago, when MATLAB was the defacto standard). I don't care about preserving the spirit of Python, I just care that the thing that bears the name Python meets my needs.

If that's fine by you, maybe just pick another language instead of having a unqualified opinion.

Re: Python 3.15's JIT is now back on track

#317

Post by drob518 »

oblio wrote: post #315
drob518 wrote: post #260

Earlier quoted context omitted.

I’m not a Python contributor, so no need to apologize to me. But if you have strong ideas about what Python should be, perhaps you should step up and contribute that code rather than saying that others are offering excuses for why they won’t deliver what you want. I have worked on other open source projects where users were very entitled, to the point of demanding that the project team deliver them certain features.…

This comment said it best: https://news.ycombinator.com/item?id=47428341

I get the motivation. Nothing wrong with that. Like I said, input is valuable for roadmaps. Just be respectful of the people who are working for FREE on Python. Unless you’re paying them, they don’t owe you anything, and saying that your dev team is already using Python and it would be difficult to change doesn’t really change that. They still don’t owe you anything.

Re: Python 3.15's JIT is now back on track

#318

Post by zadikian »

superbatfish wrote: post #270
zadikian wrote: post #145

Earlier quoted context omitted.

Pure Python code always needed mutexes for thread safety with or without ol' GIL. I thought the difficulty with removing the GIL instead had to do with C extensions that rely on it.

This is accurate and the parent commenter here seems to be echoing a common misconception. Either they are confused or they need to elaborate more to demonstrate that they have a valid complaint. For instance, this would have been a valid complaint: "Users who don't need free threading will now suffer a performance penalty for their single-threaded code." That is true. But if you are currently using multiple threads,…

I got it wrong too, even after reading the docs, until I just tried it for myself. Intuitively, why would Python have threads that can't run fully in parallel but also create race conditions? Seems like the worst of both worlds, and it almost is, except you can still speed up io-bound or even GIL-releasing CPU-bound C calls this way.

Some also mix it up with async JS which also can't use multiple CPUs and guarantees in-order execution until you "await" something. Well now that's asyncio in Python. Doesn't help that so much literature uses muddy terms like "async programming."

Re: Python 3.15's JIT is now back on track

#319

Post by oblio »

drob518 wrote: post #317
oblio wrote: post #315

Earlier quoted context omitted.

This comment said it best: https://news.ycombinator.com/item?id=47428341

I get the motivation. Nothing wrong with that. Like I said, input is valuable for roadmaps. Just be respectful of the people who are working for FREE on Python. Unless you’re paying them, they don’t owe you anything, and saying that your dev team is already using Python and it would be difficult to change doesn’t really change that. They still don’t owe you anything.

> They still don’t owe you anything.

1. I doubt that many Python devs are reading my random comments on a random site.

2. I doubt that those Python devs that stumble upon my comments care about them.

I'm a nobody on the internet. In the past I would have commented that maybe I'm a dog, but now it's fashionable to be an AI agent.

Re: Python 3.15's JIT is now back on track

#320

Post by mattclarkdotnet »

dobremeno wrote: post #219
mattclarkdotnet wrote: post #125

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax. Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e…

SPy [1] is a new attempt at something like this. TL;DR: SPy is a variant of Python specifically designed to be statically compilable while retaining a lot of the "useful" dynamic parts of Python. The effort is led by Antonio Cuni, Principal Software Engineer at Anaconda. Still very early days but it seems promising to me. [1] https://github.com/spylang/spy

Thank you! Spy looks brilliant, especially the comptime-like freezing after import.
Post reply on HN