Python 3.13 Gets a JIT

Post by pjmlp » Tue, Jan 09, 2024, 1:27 PM UTC

andrewaylett wrote: post #165

pjmlp wrote: post #145

Earlier quoted context omitted.

Sure, for UNIX scripting, for everything else it is plainfully slow. I know Python since version 1.6, and is my scripting language in UNIX like environments, during my time at CERN, I was one of the CMT build infrastructure build engineer on the ATLAS team. It was never been the language I would reach for when not doing OS scripting, and usually when a GNU/Linux GUI application happens to be slow as mollasses, it has…

A Python web service my team maintains, running at a higher request rate and with lower CPU and RAM requirements than most of the Java services I see around us, would like a word with you.

Post by Joker_vD » Tue, Jan 09, 2024, 1:30 PM UTC

guenthert wrote: post #171

a-french-anon wrote: post #146

Earlier quoted context omitted.

Isn't CL a good counter-example to that "dynamism inherently stunts performances" mantra?

To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.

    def twice(x: int) -> int:
        return x + x

    print(twice("nope"))

Post by JodieBenitez » Tue, Jan 09, 2024, 1:36 PM UTC

jampekka wrote: post #138

masklinn wrote: post #116

Earlier quoted context omitted.

It absolutely is relevant to the "python is slow reee" nonsense tho, which is the subject. Python-the-language being slow is not relevant for a lot of the users, because even if they don't know they use Python mostly as a convenient interface to huge piles of native code which does the actual work. And as noted upthread that's a significant part of the uptake of Python in scientific fields, and why pypy despite the h…

Python is slow, reee. This is a major problem in scientific fields. Currently there are sort of "two tiers" of scientific programmers: ones who write the fast binary libraries and ones that use these from Python (until they encounter e.g. having to loop and they are SOL). This is known as the two language problem. It arises from Python being slow to run and compiled languages being bad to write. Julia tries to solve…

Post by IggleSniggle » Tue, Jan 09, 2024, 1:42 PM UTC

andrewaylett wrote: post #165

pjmlp wrote: post #145

Earlier quoted context omitted.

Sure, for UNIX scripting, for everything else it is plainfully slow. I know Python since version 1.6, and is my scripting language in UNIX like environments, during my time at CERN, I was one of the CMT build infrastructure build engineer on the ATLAS team. It was never been the language I would reach for when not doing OS scripting, and usually when a GNU/Linux GUI application happens to be slow as mollasses, it has…

A Python web service my team maintains, running at a higher request rate and with lower CPU and RAM requirements than most of the Java services I see around us, would like a word with you.

Post by amelius » Tue, Jan 09, 2024, 1:46 PM UTC

Difwif wrote: post #169

guenthert wrote: post #108

Earlier quoted context omitted.

Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code. That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more…

AFAIK good JITs like V8 can do runtime introspection and recompile on the fly if types change. Maybe using the type hints will be helpful but I don't think they are necessary for significant improvement.