Which programming language or compiler is faster

I am sure if someone contributed a million line project for every language they would be happy to benchmark it.

On a single core processor, obviously not, but massive C++ codebase are compiled with multicore CPU, and often distributed. The advantage of the header inclusion model is you get an bunch of independent compilation units, and so it's straight forward to parallelize.

A common way to speed things up even more is to merge some cpp file together, so each compiler thread is active for longer and common headers are compiled once.

With the new module feature of C++20, compilation is transformed into a DAG, and it is still unclear if it's really faster than just throwing a lot of cores at the problem.

I believe this is measuring how fast the binary produced by different compilers is, rather than how long the compilation takes.

I think the title might be misleading you, when it mentions compiler speed, it means, for the same language there are different compilers. It's about runtime speed of different languages and different compilers for those languages

In 2018 Debian Alioth hosting service reached EOL.

The same benchmarks game project moved to new hosting at:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I came here to ask the same. Pascal files are laid out in such a manner that the "implementation" section of the file is ready for compilation to bytes and any forward references just mean that it's code ends up later in the exe. Typical runtime speed has only ever been fractionally slower than c/c++.

I think founder effects. It started in the math and science community so that's where most of the library-writing energy has gone into.

I think it competes with R, which has a similar usage profile

Lack of integration with other massive libraries that Python, Java and C++ have. Lack of books, tutorials and extensive knowledge bases that Python, Java and C++ have.

Julia is incredibly slow to compile. Far worse than C++ last time I tried. For interactive notebooks, I found it’s common to have a single line take a couple minutes to compile - it’s simply not interactive in the way Python is, despite having good runtime performance once compiled.

The deal breaker for me is that its compiler is JIT based whether you want it or not. Code will hang at runtime for multiple minutes as it compiles all the library dependencies and specializes them to the given data types.

In addition to the other replies, the comparatively long startup time makes it unsuitable for short scripts, and with a few dependencies it becomes unsuitable for even medium length programs. The startup time is always coming down and there are ways to compile dependencies ahead of time though. The JIT compilation can be annoying for real-time applications too.

These are what i'd say, as someone who has tinkered with it a lot but uses python/C++ for $day_job:

- immature web/network services stack. For better or worse the lang seemed to focus on more number crunching throughput early than reliable distributed data processing, but the latter is a much larger market and what most enterprises care about.

It's the difference between a lang only having Matlab or R ceiling vs python-like ceiling.

- poor static compilation or static analysis story. this is what a lot of people needing to put code in production need.

It's also standard expectation now with a lot of dynamic language code (python or js) that aims to be in production.

- for certain types of realtime uses, more direct control of memory is doable, but you have to jump through hoops. Again, determinism is very important.

- historically, compile times were quite horrid. part of this was llvm, part of it was julia. It's gotten way better in 1.6 and 1.7, but compilation results need to be cached more than just precompilation.

however, all being said, I love the lang! There is a lot going for it especially how the package ecosystem works. There is also a lot of innovative projects.

Its ridiculously large memory usage might be a reason.

During it's development Julia was heavily promoted as a language for scientific computing.

Nowadays, the language is promoted as a general purpose language suitable for any task or domain.

However, the perception that Julia is primarily for scientific computing remains strong among many developers. Only time will tell if that perception changes.

Sbcl compiles itself in just a couple of minutes.

Webpack clean: 3 minutes

Incremental: 700ms

Esbuild clean: 100ms

The title is a bit misleading. Its not clear if the compiler times are included, but the numbers do include the benchmark. Thats why the exact same sbcl compiler has different times.

The benchmarks are mixed with some having simd and some using threads. It'd be helpful to be able to sort submissions by threaded/unthreaded as well.

Still kinda fun to read the different languages. I found Zig was very chatty and annoying to read even compared to the C versions. The common lisp was foreign. The Fortran 90 with openmp and Julia versions were pleasant to read. The Nim version was easy to read but lacks threading or simd.

Jonathan Blow's new language compiler does not do incremental builds yet builds large projects extremely quickly (a few seconds).

unison cheats at this by being interpreted, if it weren’t it would have the same build times as everyone else (I suppose caching would be better in some cases, but i’m not sure if they’d be much better than what you get with nix?)

That the same logical steps expressed in one language results in less computation time spent - when compiled or interpreted - than when expressed in another language. Seems a resaonable question to ask, given there's more to a language than how you express things. Like toolchain, library availability and community.

Same idea as comparing different compilers for the same language. Some algorithms can be expressed in some languages in an essentially identical way. For example, various sorting algorithms look pretty much the same in Fortran, Pascal and C. Only surface syntax differs. Assuming this is done fairly with each implementation being properly equivalent, it's a way to compare the speed of the languages, at least for that algorithm.

Not sure how technically accurate it is, but "language" usually implies more than just the syntax. I hear and say things like "compiled language", "interpreted language", "language VM", "garbage collected language", "dynamically typed language" and so on. Those things all say something about development speed and runtime speed.

A lot. Semantics that can be made fast (e.g. C vs Python) with little effort.

(Some languages with bad semantics for that might still get fast, but the language itself isn't designed to help that. JS for example was made fast, but with tons of effort but with tons of money and man-centuries thrown in by Google, Apple, Mozilla, MS, not the kind of recources available to most languages. So, I'd call a language whose semantics afford optimization a fast language).

Runtime complexity (e.g. "zero overhead" vs "lotsa overhead" features).

Also, I find the "language vs compiler" dicthotomy pedantic and tedious. For most languages and most use cases, there's a single dominant canonical version, e.g. CPython, Matz's Ruby, Oracle's Java.

Just because there are niche other implementations all 10 people use doesn't change the fact that 90% of users will be on the canonical implementation, and for them, THAT's synonymous with the language, not just some abstract spec.

Strictly speaking it's meaningless, since a language is a set of syntax and semantics. Pragmatically though, when people talk about the speed of a language they actually mean the typical performance of processes defined by programs written in that language, which of course depends on the code generator and runtime, among other things.

There's nothing stopping anyone from writing a fully standards compliant C interpreter that will have considerably slower process execution after all. In fact, a quick search shows that it's been done many times, for example this[1].

[1] https://github.com/jpoirier/picoc

Maybe we mean programs, not languages; maybe we mean programming language implementations, not languages —

"How many times slower, the fastest benchmark programs for selected programming language implementations are, compared to the fastest written in any of the programming languages."

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Not the Ocaml ones either. Not sure this makes for a fair comparison.

Perhaps suggest PHP to the website author.

Meanwhile —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Don't you want to know what the performance difference is?

Don't you have the opportunity to compare user time as-well-as wall clock time?

( The benchmarks game does provide that sort --https://benchmarksgame-team.pages.debian.net/benchmarksgame/... )

Manual memory management a la C, and easy access to custom allocation (arenas, etc) that usually aren't used in most C code (and C doesn't offer as allocators by default).

Add compile time processing which can get pretty far into reducing all kinds of otherwise runtime ops...

I was curious too and found this:

https://stackoverflow.com/questions/2513741/c-vs-c-for-perfo...

from which I gather that if you're using an allocator function that zero's out memory then it will be slower of course.

I think the C code in the benchmarks are not really efficient. An experienced C programmer does not simulate C++ style memory management if speed matters.

C++ is just a stricter C - if you write proper C, it will be a correct C++ program, therefore it would run at the same speed. There's no way C can be other than marginally faster than C++ - if you write C and compile it with a C++ compiler.

Then you have various optimizations that come from things like templates, constexpr. Look at the qsort method - to have a modicum of genericity you need to pass a function that will be invoked. Instead, a C++ version would be able to be optimized to compare the elements directly, without calling a function, avoiding a big number of function calls.

There's no way to make C faster than well written C++. But C++ is complex and a lot of people write bad C++, that's why it has developed a bad reputation. It's really undeserved.

There is no reason, the fasted C++ code is actually C - I really don't know why somebody wrote that as C++.

https://github.com/hanabi1224/Programming-Language-Benchmark...

https://github.com/hanabi1224/Programming-Language-Benchmark...

Because it's not C++ code: https://github.com/hanabi1224/Programming-Language-Benchmark...

...I wish this were true. I'm back writing JavaScript/Typescript. The new build tools are great. Perhaps in the new year I'll convert some of these repos to build with esbuild or swc... or vite.

No matter how good you are at Python, if you need to build an SPA, it'll be far faster to go with Javascript. This is true even if you have to learn Javascript from scratch. If you're an expert at Pascal, good luck trying to use it on the Arduino.

The hardest part of learning a second and third programming language is overcoming your own frustration. Yes there are some pretty gnarly concepts in languages like Haskell. However, most mainstream programming languages are very similar to each other.

This is almost never the criteria people use as it is often not that important. Productivity is often a bigger factor. Security and Robustness is another factor. Libraries is another, portability, Platform limitations, Domain problem to be solved. Most software these days isn't really constrained by speed, if the software ran 10x faster, you'd only get marginal gains.