Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

421–430 of 553 posts

Re: Python 3.13 Gets a JIT

#421
post #416
post #411

Earlier quoted context omitted.

JIT compilation is rare in Common Lisp. I wouldn't think that Dylan implementations used JIT compilation. Apple's Dylan IDE and compiler was implemented in Macintosh Common Lisp (MCL). MCL then was not a part of the Dylan runtime. I would think that Open Dylan (the Dylan implementation originally from Harlequin) can also generate LLVM bitcode, but I don't know if that one can be JIT executed. Possibly...

are there any cl implementations that use jit? there are a lot of cl implementations so i assumed there must be one

ABCL runs on the JVM. It generates JVM byte code, which then can be JIT compiled by the JVM.

CLISP has a byte code machine, for which a JIT can be used.

There might be others.

Re: Python 3.13 Gets a JIT

#422
post #201

Earlier quoted context omitted.

Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x

This can have substantial performance implications, not to mention DX considerations.

Of course, this is not a good example of good, high-performance code, only an answer to the specific question... the questioner certainly also knows MyPy.

Re: Python 3.13 Gets a JIT

#423

How do you access optimizations such as dead code removal and constant propagation using this technique?

I believe a JIT using this technique could eliminate dead code at the Python bytecode level, but not at the machine code level. That seems pretty reasonable to me.

Not sure, these optimizations multiply in power when used together. Propagate constants and fold constants, after that you can remove things like "if 0 > 0", both the conditional check and the whole block below it, and so on.

Re: Python 3.13 Gets a JIT

#424

Earlier quoted context omitted.

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

What! Why? (I couldn’t figure it out from your link)

The link seems fairly clear to me - One explanation given is that python3 represents all integers in a "long" type, whereas python2 defaulted to small ints. This gave (gives?) python2 an advantage on tasks involving manipulating lots of small integers. Most real-world python code isn't like this, though.

Interestingly they singled out pyaes as one of the worst offenders. I've also written a pure-python AES implementation, one that deliberately takes advantage of the "long" integer representation, and it beats pyaes by about 2000%.

Re: Python 3.13 Gets a JIT

#425
post #395
post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

> Does this still mean you have to restart your local web application after any change you made to it? I heard that some developers automate that, so that everytime they save a file, the web application is restarted. That seems pretty expensive in terms of resource consumption. All of the popular frameworks automatically reload. It’s not instantaneous but with e.g. Django it was less than the time I needed to switch…

With `reload(module)` you don't even have to restart the server if you structure it properly.

Think server.py and server_handlers.py, where server.py contains logic to detect a modification of server_handlers.py (like via inotify) and the base handlers which then call the "modifiable" handlers in server_handlers.py.

This is not limited to servers (anything that loops or reacts to events) and can be nested multiple levels deep and is among the top 3 reasons of why i use Python.

Reloading is instantaneous and can gracefully handle errors in the file (just print an err messge or stack trace and keep running the old code)

Re: Python 3.13 Gets a JIT

#426
post #201

Earlier quoted context omitted.

Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x

Surely this is the job for a linter or code generator (or perhaps even a hypothetical ‘checked’ mode in the interpreter itself)? Ain’t nobody got time to add manual type checks to every single function.

Of course not. That's what MyPy is for. It was only about the answer to exactly this question in this function.

Re: Python 3.13 Gets a JIT

#427
post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

Python is amazing and shines for Web development. I'd recommend taking a look at https://www.tornadoweb.org/en/stable/index.html . I use this in production on my pet project at https://www.meecal.co/ . Put Nginx in front and you're golden. Definitely take a look, it's come a long way from ten years ago.

[dead]

Re: Python 3.13 Gets a JIT

#428
post #422

Earlier quoted context omitted.

This can have substantial performance implications, not to mention DX considerations.

Of course, this is not a good example of good, high-performance code, only an answer to the specific question... the questioner certainly also knows MyPy.

I actually don't know anything about MyPy, only that it exists. Does it run that example correctly, that is, does it print "nopenope"? Because I think it's the correct behaviour, type hints should not actually affect evaluation (well, beyond the fact that they must be names that are visible in the scopes thay're used in, obviously), altough I could be wrong.

Besides, my point was that one of the reasons why languages with (sound-ish) static types manage to have better performance because they can omit all of those run-time type checks (and the supporting machinery) because they'd never fail. And if you have to put those explicit checks, then the type hints are actually entirely redundant: e.g. Erlang's JIT ignores type specs, it instead looks at the type guards in the code to generate specialized code for the function bodies.

Re: Python 3.13 Gets a JIT

#429
post #381

Earlier quoted context omitted.

5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?

Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.

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

Re: Python 3.13 Gets a JIT

#430

Earlier quoted context omitted.

I think python is very well suited to people who do computation in Excel spreadsheets. For actual CS students, I'd rather see something like scheme be a first language (but maybe I'm just an old person)

Its even in Excel nowadays!!

and in Postgres UDFs
Post reply on HN