131–140 of 154 posts
Earlier quoted context omitted.
The language itself is not the issue, the implementations are wildly different in other ways
The nbody sim at least is forced to use the same algorithm. It seems unlikely that an optimised pypy (non-BLAS) implementation beats an optimised C imp by 20x.
Earlier quoted context omitted.
Yeah that bothers me too, but it's damn hard to get away from these days. Most language projects have significant corporate involvement one way or the other. Go is criminally underrated in my opinion. It ticks so many boxes I'm surprised it hasn't seen more adoption.
It ticks many boxes for me on the surface, but I've read a few articles that critique some of its design choices. Rust really ticks the "it got all the design choices right" boxes, but fighting the borrow checker and understand smart pointers, lifetimes, and dispatch can be a serious cognitive handicap for me.
Go and Rust try to solve very different problems. Rust takes on a lot of complexity to provide memory safety without a garbage collector, which is fine, but also unnecessary for a lot of problems.
Earlier quoted context omitted.
The nbody sim at least is forced to use the same algorithm. It seems unlikely that an optimised pypy (non-BLAS) implementation beats an optimised C imp by 20x.
That's because you assume an algorithm implemented on top of the C implementation of python is equivalent to a C implemention of the algorithm. You don't understand how CPython works.
nbody 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…
Obviously the main point of the article is to compare different python optimisations, however "rewrite it in C/C++/rust/Go" is an option that should be considered, and none of his optimisations on his M4 Pro beat the C option on my 6-year old M1 mac mini.
The rest of the numbers in the blog post use a 500k iterations for the nbody simulation. Here's my numbers on the M1 mac using the default Clang installed with xcode:
Clang 17.0.0. 0.06s
python 3.12.11 1.59s
pypy 3.11.13. 0.23s
clang -O3 -march=native nbody-gcc-6.c -o nbody.clang6
Used the python version from [2].
[1] http://benchmarksgame-team.pages.debian.net/benchmarksgame/p...
[2] https://github.com/cemrehancavdar/faster-python-bench/tree/m...
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I don’t think the answer is that easy. Python is typically run on the server and JavaScript is client-side, which means that the incentives are aligned to optimize Python rather than JavaScript. I think investment in each follows and the difference is more that JavaScript runs in an isolated environment with a more flexible runtime.
Nah although his answer wasn’t exactly what I’m looking for he’s not wrong. Python is not optimized because on the backend you just switch to another language that’s faster. That’s the economically optimized thing to do. Can’t do that on the frontend.
Python is perfect as a "glue" language. "Inner Loops" that have to run efficiently is not where it shines, and I would write them in C or C++ and patch them with Python for access to the huge library base. This is the "two language problem" ( I would like to hear from people who extensively used Julia by the way, which claims to solve this problem, does it really ?)
This problem has been solved already by Lisp, Scheme, Java, .NET, Eiffel, among others, with their pick and choose mix of JIT and AOT compiler toolchains and runtimes.
They're only "fast" compared to slow interpreted languages like Python.
Earlier quoted context omitted.
This problem has been solved already by Lisp, Scheme, Java, .NET, Eiffel, among others, with their pick and choose mix of JIT and AOT compiler toolchains and runtimes.
No, those languages have not solved it. None of the languages you list there are actually as fast as C for tight inner loops, they sometimes get close under certain circumstances, but they're still very much 2nd class languages in terms of performance. They're only "fast" compared to slow interpreted languages like Python.
Earlier quoted context omitted.
No, those languages have not solved it. None of the languages you list there are actually as fast as C for tight inner loops, they sometimes get close under certain circumstances, but they're still very much 2nd class languages in terms of performance. They're only "fast" compared to slow interpreted languages like Python.
Yes they have, because those microbenchmarks are tailor made for the winner, using a very specific compiler implementation with language extensions, which apparently is only valid if the language happens to be "C".
Surprised Python is only 21x slower than C for tree traversal stuff. In my experience that's one of the most painful places to use Python. But maybe that's because I use numpy automatically when simple arrays are involved, and there's no easy path for trees.
Be careful with that, numpy arrays can be slower than Python tuples for some operations. The creation is always slower and the overhead has to be worth it.