Programming language speed comparison using Leibniz formula for π (niklas-heer.github.io)

- C++ unsurpassable king.

- There's a stark jump of times going from ~200ms to ~900ms. (Rust v1.92.0 being an in-between outlier.)

- C# gets massive boost (990->225ms) when using SIMD.

- But C++ somehow gets slower when using SIMD.

- Zig very fast*!

- Rust got big boost (630ms->230ms) upgrading v1.92.0->1.94.0.

- Nim (that compiles to C then native via GCC) somehow faster than GCC-compiled C.

- Julia keeps proving high-level languages can be fast too**.

- Swift gets faster when using SIMD but loses much accuracy.

- Go fastest language with own compiler (ie not dependent to GCC/LLVM).

- V (also compiles to C) expected it (appearing similar) be close to Nim.

- Odin (LLVM) & Ada (GCC) surprisingly slow. (Was expecting them to be close to Zig/Fortran.)

- Crystal slowest LLVM-based language.

- Pure CPython unsurpassable turtle.

Curious how D's reference compiler (DMD) compares to the LLVM/GCC front-ends, how LFortran to gfortran, and QBE to GCC/LLVM. Also would like to see Scala Native (Scala currently being inside the 900~1000ms bunch).

* Note that uses `@setFloatMode(.Optimized)` which according to docs is equivalent to `--fast-math` but only D/Fortran use this flag (C/C++ do not).

** Uses `@fastmath` AND `@simd`. The comparison supposedly is for performance on idiomatic code and for Julia SIMD is a simple annotation applied to the loop (and Julia may even auto do it) but should still be noted because (as seen in C# example) it can be big.

In my opinion, the comparisons could be better if the file I/O and console printing were removed.

I did the same sort of thing with the Seive of Eratosthenes once, on a smaller scale. My Haskell and Python implementations varied by almost a factor of 4 (although you could argue that I changed the algorithm too much on the fastest Python one). OK, yes, all the Haskell ones were faster than the fastest Python one, and the C one was another 4 times faster than the fastest Haskell one... but they were still over the place.

  ᐅ time uv run -p cpython-3.14 leibniz.py
  3.1415926525880504
  
  ________________________________________________________
  Executed in   38.24 secs    fish           external
     usr time   37.91 secs  158.00 micros   37.91 secs
     sys time    0.16 secs  724.00 micros    0.16 secs
  
  ᐅ time uv run -p pypy leibniz.py
  3.1415926525880504
  
  ________________________________________________________
  Executed in    1.52 secs    fish           external
     usr time    1.16 secs    0.25 millis    1.16 secs
     sys time    0.02 secs    1.29 millis    0.02 secs

But this is a good benchmark results that demonstrate what performance level can you expect from every language when someone not versed in it does the code porting. Fair play

When you put these programs into Godbolt to see what's going on with them, so much of the code is just the I/O part that it's annoying to analyze

> Why do you also count reading a file and printing the output?

> Because I think this is a more realistic scenario to compare speeds.

Which is fine, but should be noted more prominently. The startup time and console printing obviously aren't relevant for something like the Python run, but at the top of the chart where runs are a fraction of a second it probably accounts for a lot of the differences.

Running the inner loop 100 times over would have made the other effects negligible. As written, trying to measure millisecond differences between entire programs isn't really useful unless someone has a highly specific use case where they're re-running a program for fractions of a second instead of using a long-running process.

Swift: 3.7

Python: that's incorrect!

Swift: yeah, but it's fast!

There is very little superfluous or that cannot be inferred by the compiler here: https://github.com/niklas-heer/speed-comparison/blob/master/...

    public static void main(String[] args) throws FileNotFoundException {
        Scanner s = new Scanner(new File("rounds.txt"));
        long rounds = s.nextLong();
        s.close();

        double sum = 0.0;
        double flip = -1.0;
        for (long i = 1; i <= rounds; i++) {
            flip *= -1.0;
            sum += flip / (2 * i - 1);
        }

        System.out.println(sum * 4.0);
    }

            sum += flip / (2 * i - 1); 
            flip *= -1.0;

   #   Language          Accuracy
  14   Swift (SIMD)          8.69
   9   Fortran 90            9.44
   2   C# (SIMD)             9.49
   .   [All the others]      9.50

I’m genuinely blown away by all the interest in what started as a silly little experiment. The project grew way beyond its original scope. My initial curiosity was simply: how could you set up a pipeline to do automatic speed comparisons? I was less interested in the results as a definitive measure and more in the infrastructure challenge itself.

But then the interest kept growing. I tried to modernize things, but one thing became quite notable: the difference between a language that gets actively optimized by its community (like Julia) versus one that just sits there unoptimized is striking.

Honestly, I got overwhelmed. Managing all those implementations, keeping versions up to date, reviewing contributions—it was a lot. I basically tapped out for about a year.

Now I’m back, and with AI assistance, maintaining this has become much more realistic—updating versions, helping optimize implementations, etc. That said, I’m always happy to accept contributions from folks who know their languages better than I do.

Thank you all for your interest and the thoughtful discussion!