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

261–270 of 330 posts

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

#261

Post by LtWorf »

anematode wrote: post #186
LtWorf wrote: post #184

Earlier quoted context omitted.

But what if whatever you call is also accessing and changing the attribute?

If what you call gets inlined, then the compiler can see that it either does or doesn't modify the attribute and optimize it accordingly. Even virtual calls can often be inlined via, e.g., class hierarchy analysis and inline caches. If these analyses don't apply and the callee could do anything, then of course the compiler can't keep the value hoisted. But a function call has to occur anyway, so the hoisted value wil…

Another thread can access it and do that, how could the compiler possibly know about it?

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

#262

Post by NetMageSCW »

coldtea wrote: post #236
mathisfun123 wrote: post #221

Earlier quoted context omitted.

> considered nuts - or at least an unfortunate early decision Please explain to us then how exactly you would infer a variable with an arbitrary name is actually a reference to the class instance in an interpreted language .

>Please explain to us then how exactly you would infer a variable with an arbitrary name is actually a reference to the class instance in an interpreted language. Did I stutter when I wrote about "an unfortunate early decision"? Who said it has to be "an arbitrary name"? Even so, you could add a bloody marker announcing an arbitrary name (which 99% would be self anyway) as so, as an instruction to the interpreter. If…

But now you are no longer talking about the way Python works, but the way you want Python to work - and that has nothing to do with Python.

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

#263

Post by coredog64 »

giancarlostoro wrote: post #255
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…

IronPython -> TitaniumPython?

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

#264

Post by NetMageSCW »

rich_sasha wrote: post #136
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 think sadly a lot of Python in the wild relies heavily, somewhere, on the crazy unoptimisable stuff. For example pytest monkey patches everything everywhere all the time. You could make this clean break and call it Python 4 but frankly I fear it won't be Python anymore.

Perl 6 showed what happens when you do something like that.

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

#265

Post by bloppe »

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.

Me too, but changing the referential semantics would be a massive breaking change. That doesn't qualify as "without changing much of a codebade". And tacking on a giant new orthogonal type system to avoid breaking existing code would be akin to creating a new language. Why bother when you can just write Python modules in Rust.

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

#266

Post by LtWorf »

BerislavLopac wrote: post #245
wiseowise wrote: post #217

Earlier quoted context omitted.

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.

Any program written in Python of any significant size is literally a soup of multiple languages.

There's no project that isn't like that.

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

#267

Post by LtWorf »

BerislavLopac wrote: post #246
mattclarkdotnet wrote: post #142

Earlier quoted context omitted.

Performance is one part of the discussion, but cleanliness is another. 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.

> 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.

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

#268

Post by LtWorf »

20k wrote: post #122
smcl wrote: post #117

Earlier quoted context omitted.

I cannot believe people are still acting like Python 2->3 was a huge fuck-up and an enormous missed opportunity. When in reality Python is by most measures the most popular language and became so AFTER that switch. Since the switch we have seen enormous companies being built from scratch. There is no reason for anyone to be complaining about it being too hard to upgrade in 2026

It took a long time for python 3 to add the necessary backwards compatibility features to allow people to switch over. Once they did it was fine, but it was a massive fuck up until then. The migration took far longer than it should have done Its widely regarded as a disaster for good reason, that forced some corrections in python to fix it. Just because its fine now, does not mean it was always fine

Now they just break stuff every release so we never relax.

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

#269

Post by LtWorf »

IshKebab wrote: post #58
froobius wrote: post #54

Earlier quoted context omitted.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

Python does not take backwards compatibility very seriously at all. Take a look at all the deprecated APIs. I would say it's probably worth it to clean up all the junk that Python has accumulated... But it's definitely not very high up the list of languages in terms of backwards compatibility. In fact I'm struggling to think of other languages that are worse. Typescript probably? Certainly Go, C++ and Rust are signif…

They don't just deprecate APIs, they remove them completely to make sure you really stop using them.

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

#270

Post by superbatfish »

zadikian wrote: post #145
zarzavat wrote: post #61

Earlier quoted context omitted.

I continue to believe that free-threading hurts performance more than it helps and Python should abandon it. Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

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, code that was correct before will still be correct in the free threaded build, and code that was incorrect before will still be incorrect.

Post reply on HN