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

251–260 of 330 posts

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

#251

Post by codesnik »

1718627440 wrote: post #237
codesnik wrote: post #235

Earlier quoted context omitted.

I wonder, why that kind of ambiguity or complexity even comes to your mind at all. Just because python is weird? def foo(self, arg=expression): could, and should work as if it was written like this (pseudocode) def foo(self, arg?): if is_not_given(arg): arg=expression if "expression" is a literal or a constructor, it'd be called right there and produce new object, if "expression" is a reference to an object in outer…

What you want is for an assignment in a function definition to be a lambda. def foo (self, arg=lambda : expression): Assignment of unevaluated expressions is not a thing yet in Python and would be really surprising. If you really want that, that is what you get with a lambda. > most languages with closures and default values for arguments do it this way. Do these also evaluate function definitions at runtime?

yes they do. check ruby for example.

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

#252

Post by eru »

kelipso wrote: post #241
eru wrote: post #232

Earlier quoted context omitted.

Feel free to correct the market and make oodles of money.

Risk my money based on a bunch of wallstreetbets idiots yoloing their money using a random number generator and seeing the word AI on twitter posts, sure lol. I’ll let you play in that cesspool.

I am!

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

#253

Post by drob518 »

oblio wrote: post #248
BerislavLopac wrote: post #244

Earlier quoted context omitted.

> python code could be so much faster if it didn't have to assume everything could change at any time Definitely, but then it wouldn't be Python. One of the core principles of Python's design is to be extremely dynamic, and that anything can change at any time. There are many other, pretty good, strictly dynamically typed languages which work just as well if not better than Python, for many purposes.

I feel that this excuse is being trotted out too much. Most engineers never get to choose the programming language used for 90% of their professional projects. And when Python is a mainstream language on top of which large, globally known websites, AI tools, core system utilities, etc are built, we should give up the purity angle and be practical. Even the new performance push in Python land is a reflection of this.…

You’re always free to create your own Python-like language that caters more toward your goals. No excuses, then.

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

#255

Post by giancarlostoro »

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…

I went sort of this route in an experiment with Claude.. I really want Python for .NET but I said, damn the expense, prioritize .NET compatibility, remove anything that isn't supported feasably. It means 0 python libs, but all of NuGet is supported. The rules are all signatures need types, and if you declare a type, it is that type, no exceptions, just like in C# (if you squint when looking at var in a funny way). I wound up with reasonable results, just a huge trade of the entire Python ecosystem for .NET with an insanely Python esque syntax.

Still churning on it, will probably publish it and do a proper blog post once I've built something interesting with the language itself.

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

#256

Post by oblio »

drob518 wrote: post #253
oblio wrote: post #248

Earlier quoted context omitted.

I feel that this excuse is being trotted out too much. Most engineers never get to choose the programming language used for 90% of their professional projects. And when Python is a mainstream language on top of which large, globally known websites, AI tools, core system utilities, etc are built, we should give up the purity angle and be practical. Even the new performance push in Python land is a reflection of this.…

You’re always free to create your own Python-like language that caters more toward your goals. No excuses, then.

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

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

#257

Post by quietbritishjim »

a3w wrote: post #254

Over 100% speedup sound like "the code compiled before you asked the compiler to start working". `from future import time_travel`

If the speed of a car increases by 100% does that mean that it arrives at its destination before it left? No, it just means it took 50% of the time it would have otherwise.

But I do agree that it would be a bit clearer to talk in terms of time taken rather than speedup % i.e. instead of "20% slowdown to over 100% speedup" it's clearer to say "takes between 50% and 125% of the original time". (Especially since people very often say things like "3 times faster", which technically means 4 times as fast, when they should say "3 times as fast"; "takes 1/3 of the time" is unambiguous.)

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

#258

Post by drob518 »

wiseowise wrote: post #217
bloppe wrote: post #135

Earlier quoted context omitted.

But that's just not what python is for. Move your performance-critical logic into a native module.

I’ll be happy if over night all Python code in the world can reap 10-100x performance benefits without changing much of a codebase, you can continue having soup of multiple languages.

I’d like to be good looking and drive a Ferrari. But that probably isn’t going to happen, either.

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

#259

Post by kenjin4096 »

kenjin4096 wrote: post #229
adrian17 wrote: post #7

I'm been occasionally glancing at PR/issue tracker to keep up to date with things happening with the JIT, but I've never seen where the high level discussions were happening; the issues and PRs always jumped right to the gritty details. Is there anywhere a high-level introduction/example of how trace projection vs recording work and differ? Googling for the terms often returns CPython issue tracker as the first resul…

> I've never seen where the high level discussions were happening Thanks for your interest. This is something we could improve on. We were supposed to document the JIT better in 3.15, but right now we're crunching for the 3.15 release. I'll try to get to updating the docs soon if there's enough interest. PEP 744 does not document the new frontend. I wrote a somewhat high-level overview here in a previous blog post ht…

Update: I put up a PR to document the trace recording interpreter https://github.com/python/cpython/pull/146110

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

#260

Post by drob518 »

oblio wrote: post #256
drob518 wrote: post #253

Earlier quoted context omitted.

You’re always free to create your own Python-like language that caters more toward your goals. No excuses, then.

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. It’s not fun. It’s ironic that open source often brings out both the best and the worst in people. Suggesting changes and new features is fine, even critical to a strong roadmap. But we all need to realize that maintainers may have other goals and there’s no obligation on their part to implement anything. The beauty of open source is that you can customize or fork as much as you want to match your goals. But then you’re responsible for doing the work and if your changes are public you may have your own set of users demanding their own favorite changes.
Post reply on HN