when dealing with JSON in cpython, I always use msgspec, performance gains is huge
Python: The Optimization Ladder
91–100 of 154 posts
Re: Python: The Optimization Ladder
#92 nbody spectral-norm
C 2100ms 400ms
Graal 211ms 212ms
PyPy 98ms 1065ms
Edit: looking at [1] the top C version uses x86 intrinsics, perhaps the article's writer had to find a slower implementation to have it running natively on his M4 Pro? It would be good to know which C version he used, there's a few at [1]. The N-body benchmark is one where they specify that the same algorithm must be used for all implementations.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: Python: The Optimization Ladder
#93> The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize. ... > 4 bytes of number, 24 bytes of machinery to support dynamism. a + b means: dereference two heap pointers, look up type slots, dispatch to int.__add__, allocate a new P…
The dynamism exists to support the object model. That's the actual dependency. Monkey-patching, runtime class mutation, vtable dispatch. These aren't language features people asked for. They're consequences of building everything on mutable objects with identity. Strip the object model. Keep Python. You get most of the speed back without touching a compiler, and your code gets easier to read as a side effect. I built…
[deleted]
Re: Python: The Optimization Ladder
#94Significant AI smell in this write up. As a result, my current reflex is to immediately stop reading. Not judgement on the actual analysis and human effort which went in. It’s just that the other context is missing.
I had the same reflex. I just can't read AI redacted stuff. I don't know why it just reads very hollow and 'icky'
Re: Python: The Optimization Ladder
#95nbody spectral-norm C 2100ms 400ms Graal 211ms 212ms PyPy 98ms 1065ms Seeing Graal and Pypy beat the gcc C versions suggests to me there's something wrong with the C version. Perhaps they need a -march=native or there's something else wrong. The C version would be a different implementation in the benchmark game, but usually they are highly optimised. Edit: looking at [1] the top C version uses x86 intrinsics, perhap…
The language itself is not the issue, the implementations are wildly different in other ways
Re: Python: The Optimization Ladder
#96>The usual suspects are the GIL, interpretation, and dynamic typing. All three matter, but none of them is the real story. The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize. ok I guess the harder question is. Why isn't python…
> ok I guess the harder question is. Why isn't python as fast as javascript? Actually there is a pretty easy answer: worldwide, the amount of javascript being evaluated every day is many orders of magnitude higher than the amount of python. The amount of money available for optimizing it has thus been many orders of magnitude higher as well.
I mean the technical reasons. Because every reason stated in my quote is applicable to JavaScript as well.
Re: Python: The Optimization Ladder
#97Earlier quoted context omitted.
I've always thought the flexibility should allow python to consume things like gRPC proto files or OpenAPI docs and auto-generate the classes/methods at runtime as opposed to using codegen tools. But as far as I know, there aren't any libraries out there actually doing that.
Generating code at runtime is often an anti-goal because you can’t easily introspect it. “Build-time” generation gives you that, but print often choose to go further and check the generated code to source control to be able to see the change history.
But for things like e.g. DAG systems, it would be great to be able to upload a new API definition and have it immediately available instead of having to recompile anything in the backend.
Re: Python: The Optimization Ladder
#98Significant AI smell in this write up. As a result, my current reflex is to immediately stop reading. Not judgement on the actual analysis and human effort which went in. It’s just that the other context is missing.
I have the same issue now. It's especially annoying when it happens while reading a "serious" publication like a newspaper or long form magazine. Whether it was because an AI wrote it or "real" writers have spent so much time reading AI slop they've picked up the same style is kinda by the by. It all reads to me like SEO, which was the slop template that LLMs took their inspiration from, apparently. It just flattens…
[deleted]
Re: Python: The Optimization Ladder
#99I wish there were more details on this part. > Missing @cython.cdivision(True) inserts a zero-division check before every floating-point divide in the inner loop. Millions of branches that are never taken. I thought never taken branches were essentially free. Does this mean something in the loop is messing with the branch predictor?
From when I was working on optimizing one or two things with Cython years ago, it wasn’t per-se the branch cost that hurt: it was impeding the compiler from various loop optimisations, potentially being the impediment from going all the way to auto-vectorisation.
Re: Python: The Optimization Ladder
#100>The usual suspects are the GIL, interpretation, and dynamic typing. All three matter, but none of them is the real story. The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize. ok I guess the harder question is. Why isn't python…
Beyond the economic arguments, there’s a lot in JS that actually makes it a lot easier: almost all of the operators can only return a subset of the types and cannot be overridden (e.g., the binary + operator in JS can only return a string or a number primitive), the existence of like string and number primitives dramatically reduce the amount of dynamic behaviour they can have, only proxy objects can exhibit the same amount of dynamism as arbitrary Python ones (and thus only they pay the performance cost)…