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

231–240 of 330 posts

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

#231

Post by 1718627440 »

codesnik wrote: post #169
boxed wrote: post #164

Earlier quoted context omitted.

You think so but then you write a function with a default argument pointing to some variable that is a list and now suddenly the semantics of that are... what?

you could just treat argument initialization as an executable expression which is called every time you call a function. If you have a=[], then it's a new [] every time. If a=MYLIST then it's a reference to the same MYLIST. Simple. And most sane languages do it this way, I really don't know why python has (and maintain) this quirk.

What are the semantics of the following:

    b = ComplexObject (...)
    # do things with b

    def foo (self, arg=b):
        # use b

    return foo
Should it create a copy of b every time the function is invoked? If you want that right now, you can just call b.copy (), when you always create that copy, then you can not implement the current choice.

Should the semantic of this be any different? :

    def foo (self, arg=ComplexObject (...)):
Now imagine a:

    ComplexObject = list

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

#232

Post by eru »

PurpleRamen wrote: post #228
Tempest1981 wrote: post #123

Earlier quoted context omitted.

IBM shares fell 13% in a single day in last month: "IBM Sinks Most Since 2000 as Anthropic Touts Cobol Tool" https://finance.yahoo.com/news/ibm-sinks-most-since-2000-210... It may not be "cheap", but possibly cheaper than IBM's consulting.

Share-pricing operates on illusions. Just selling a plausible claim can influence the price. Whether they will deliver at the end, doesn't matter at that moment.

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

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

#233

Post by 1718627440 »

mattclarkdotnet wrote: post #132
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…

To clarify, it is nuts that in an object method, there is a performance enhancement through caching a member value. class SomeClass def init(self) self.x = 0 def SomeMethod(self) q = self.x ## do stuff with q, because otherwise you're dereferencing self.x all the damn time

This is not just a performance concern, this describes completely different behaviour. You forgot that self.x is just Class.__getattr__(self, 'x') and that you can implement __getattr__ how you like. There is no object identity across the values returned by __getattr__.

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

#234

Post by reinhash »

zarzavat wrote: post #61
oystersareyum wrote: post #2

> We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track. I recently read an interview about implementing free-threading and getting modifications through the ecosystem to really enable it: https://alexalejandre.com/programming/interview-with-ngoldba... The guy said he hopes the free-threaded build'll be the only one in "3.16 or 3.17", I wonder if that sh…

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.

I also wonder how many people actually need free-threading. And I wonder how useful it will be, when you can already use the ABI to call multi-threaded code.

I think the GIL provides python with a great guarantee, I would probably prefer single-thread performance improvements over multithreading in python to be honest.

Anyway if I need performance, Python would probably not be my first choice

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

#235

Post by codesnik »

1718627440 wrote: post #231
codesnik wrote: post #169

Earlier quoted context omitted.

you could just treat argument initialization as an executable expression which is called every time you call a function. If you have a=[], then it's a new [] every time. If a=MYLIST then it's a reference to the same MYLIST. Simple. And most sane languages do it this way, I really don't know why python has (and maintain) this quirk.

What are the semantics of the following: b = ComplexObject (...) # do things with b def foo (self, arg=b): # use b return foo Should it create a copy of b every time the function is invoked? If you want that right now, you can just call b.copy (), when you always create that copy, then you can not implement the current choice. Should the semantic of this be any different? : def foo (self, arg=ComplexObject (...)): No…

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 scope, it'd be still the same object.

it's a simple code transformation, very, very predictable behavior, and most languages with closures and default values for arguments do it this way. Except python.

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

#236

Post by coldtea »

mathisfun123 wrote: post #221
coldtea wrote: post #203

Earlier quoted context omitted.

The above is a very thick response that doesn't address the parent's points, just sweeps them under the rag with "that's just how it was designed/it works". "Did you miss the part where I explained to you there's no way to identify that it's a member variable?" No, you you did miss the case where that in itself can be considered nuts - or at least an unfortunate early decision. "this just how things are dunn around d…

> 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 it fails, it fails, like countless other things that can fail during runtime in Python today.

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

#237

Post by 1718627440 »

codesnik wrote: post #235
1718627440 wrote: post #231

Earlier quoted context omitted.

What are the semantics of the following: b = ComplexObject (...) # do things with b def foo (self, arg=b): # use b return foo Should it create a copy of b every time the function is invoked? If you want that right now, you can just call b.copy (), when you always create that copy, then you can not implement the current choice. Should the semantic of this be any different? : def foo (self, arg=ComplexObject (...)): No…

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?

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

#238

Post by fermigier »

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 have made some experiments with P2W, my experimental Python (subset) to WASM compiler. Initial figures are encouraging (5x speedup, on specific programs).

https://github.com/abilian/p2w

NB: some preliminary results:

  p2w is 4.03x SLOWER than gcc (geometric mean)

  p2w is 5.50x FASTER than cpython (geometric mean)

  p2w is 1.24x FASTER than pypy (geometric mean)

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

#239

Post by wolvesechoes »

wiseowise wrote: post #216
wolvesechoes wrote: post #209

Earlier quoted context omitted.

Maybe, but I quoted specific part I was replying to. TS has no impact on runtime performance of JS. Type hints in Python have no impact on runtime performance of Python (unless you try things like mypyc etc; actually, mypy provides `from mypy_extensions import i64`) Therefore Python has no use for TS-like superset, because it already has facilities for static analysis with no bearing on runtime, which is what TS prov…

What OP means is that they need to: 1) Add TS like language on top of Python in backwards compatible way 2) Introduce frozen/final runtime types 3) Use 1 and 2 to drive runtime optimizations

Still makes no sense. OP demands introduction of different runtime semantics, but this doesn't require adding more language constructs (TS-like superset). Current type hints provide all necessary info on the language level, and it is a matter of implementation to use them or not.

From all posts it looks like what OP wants is a different language that looks somewhat like Python syntax-wise, so calling for "backwards-compatible" superset is pointless, because stuff that is being demanded would break compatibility by necessity.

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

#240

Post by thunky »

bigstrat2003 wrote: post #172
thunky wrote: post #78

I always wanted this for Python but now that machines write code instead of humans I feel like languages like Python will not be needed as much anymore. They're made for humans, not machines. If a machine is going to do the dirty work I want it to produce something lean, fast, and strictly verified.

> now that machines write code instead of humans That is not remotely the case for anyone who produces quality work.

Look again.

If you care about quality you absolutely can guide a machine to produce that for you without writing a single line of code yourself.

And I expect the amount of guidance needed will continue to drop.

Post reply on HN