3 ms·

nbody spectral-norm C 2100ms 400ms Graal 211ms 212ms PyPy 98ms 1065ms Seeing Graal and Pypy beat the gcc C versions suggests to me

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, 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/performance/nbody.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

mkoubaa 7mo ago
The language itself is not the issue, the implementations are wildly different in other ways
- kristianp 7mo ago
  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.
  - mkoubaa 7mo ago
    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.
    - kristianp 7mo ago
      Try to explain the 20x without resorting to personal attacks on me.
kristianp 7mo ago
I've checked some run times on my M1 mac mini, and have realised the C run time of 2.1s for n-body is the figure from the benchmark game itself, which is 50 million iterations on a very old i5. It would have made sense if they'd run the C version on their M4 pro and used the same number of iterations to get a true comparison there. 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 I used the fastest C code that doesn't use intrinsics at [1] and compiled with 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/program/nbody-gcc-6.html http://benchmarksgame-team.pages.debian.net/benchmarksgame/p... [2] https://github.com/cemrehancavdar/faster-python-bench/tree/main/pypy_benchmark https://github.com/cemrehancavdar/faster-python-bench/tree/m...
- igouy 7mo ago
  Here are a few naive un-optimised single-thread #8 programs transliterated line-by-line literal style into different programming languages from the same original. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

mkoubaa 7mo ago

The language itself is not the issue, the implementations are wildly different in other ways

kristianp 7mo ago
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.
- mkoubaa 7mo ago
  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.
  - kristianp 7mo ago
    Try to explain the 20x without resorting to personal attacks on me.

kristianp 7mo ago

I've checked some run times on my M1 mac mini, and have realised the C run time of 2.1s for n-body is the figure from the benchmark game itself, which is 50 million iterations on a very old i5. It would have made sense if they'd run the C version on their M4 pro and used the same number of iterations to get a true comparison there. 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 I used the fastest C code that doesn't use intrinsics at [1] and compiled with 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/program/nbody-gcc-6.html http://benchmarksgame-team.pages.debian.net/benchmarksgame/p... [2] https://github.com/cemrehancavdar/faster-python-bench/tree/main/pypy_benchmark https://github.com/cemrehancavdar/faster-python-bench/tree/m...

igouy 7mo ago
Here are a few naive un-optimised single-thread #8 programs transliterated line-by-line literal style into different programming languages from the same original. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...