5 ms·

Is this a language benchmark or a programmer benchmark? Usually these differences come down to the specific implementation more often than the language used.

MrBuddyCasino 5y ago
Those are related tho! If I had a tough problem to solve, I would tend to give it to the "average Rust" rather than the "average PHP" programmer. Language difficulty and the surrounding culture act as a filter.
galangalalgol 5y ago
Since much of the implementation is in available libraries, this is a comparison of those too, which is an important consideration. There are language features that slow things down too. The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most real world experience (and also that we don't always care about that hit). It also makes it clear that being dynamically typed and interpreted is a huge penalty in performance. I.e. python. But again, development speed can be more important than that throughput hit. Benchmarks can help us decide which tools we like for which tasks.
- gmfawcett 5y ago
  > no language with GC gets closer than a 2-3x the time of a non-GC language I think you're saying that no GC language gets withing 2-3x of the fastest non-GC language. There are slow non-GC languages.
  - galangalalgol 5y ago
    very fair, swift is pretty bad
- igouy 5y ago
  > … no language with GC gets closer than a 2-3x … No doubt I misunderstood what you meant, so 2.13s n-body C gcc #9 program 3.18s n-body C# .NET #9 program Is it just that I'm reading your "2-3x" literally, and you also meant 1.5x? :-)
  - galangalalgol 5y ago
    You know I did see that the other day and forgot! C# is quite impressive in general. The intrinsic support really helped in that one. Thanks for keeping the thing going. Its cool to see someone follow your advice and benchmark a language not on the site.
    - igouy 5y ago
      > Its cool to see… Finally! :-)
- tsoj 5y ago
  > no language with GC gets closer than a 2-3x the time of a non-GC language This is wrong. At least, it is not true generally. I wrote a 1:1 port of my C++ chess engine, and after a bit of fiddling with compiler options the Nim version was faster. In fact, when using a delayed garbage collector, the program was even faster than when using reference counting.
- mratsim 5y ago
  > The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most real world experience (and also that we don't always care about that hit). It also makes it clear that being dynamically typed and interpreted is a huge penalty in performance. It makes it clear that some people have most time to optimize for a benchmark than others. This benchmark on state-of-the-art cryptography shows that GC-ed languages including Go and Nim can be 2x faster than Rust: - https://hackmd.io/@gnark/eccbench#Pairing https://hackmd.io/@gnark/eccbench#Pairing (old benchmarks, in particular Nim had a parameter passing issue/bad copy behavior on large types) Furthermore, Nim GC/memory management is type-dependent, only seq/string (which use malloc/free) and `ref T` type (which use refcounting) involves some runtime. So Nim devs can choose to opt-in in GC or use manual memory management depending on their priorities.

MrBuddyCasino 5y ago

Those are related tho! If I had a tough problem to solve, I would tend to give it to the "average Rust" rather than the "average PHP" programmer. Language difficulty and the surrounding culture act as a filter.

galangalalgol 5y ago

Since much of the implementation is in available libraries, this is a comparison of those too, which is an important consideration. There are language features that slow things down too. The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most real world experience (and also that we don't always care about that hit). It also makes it clear that being dynamically typed and interpreted is a huge penalty in performance. I.e. python. But again, development speed can be more important than that throughput hit. Benchmarks can help us decide which tools we like for which tasks.

gmfawcett 5y ago
> no language with GC gets closer than a 2-3x the time of a non-GC language I think you're saying that no GC language gets withing 2-3x of the fastest non-GC language. There are slow non-GC languages.
- galangalalgol 5y ago
  very fair, swift is pretty bad
igouy 5y ago
> … no language with GC gets closer than a 2-3x … No doubt I misunderstood what you meant, so 2.13s n-body C gcc #9 program 3.18s n-body C# .NET #9 program Is it just that I'm reading your "2-3x" literally, and you also meant 1.5x? :-)
- galangalalgol 5y ago
  You know I did see that the other day and forgot! C# is quite impressive in general. The intrinsic support really helped in that one. Thanks for keeping the thing going. Its cool to see someone follow your advice and benchmark a language not on the site.
  - igouy 5y ago
    > Its cool to see… Finally! :-)
tsoj 5y ago
> no language with GC gets closer than a 2-3x the time of a non-GC language This is wrong. At least, it is not true generally. I wrote a 1:1 port of my C++ chess engine, and after a bit of fiddling with compiler options the Nim version was faster. In fact, when using a delayed garbage collector, the program was even faster than when using reference counting.
mratsim 5y ago
> The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most real world experience (and also that we don't always care about that hit). It also makes it clear that being dynamically typed and interpreted is a huge penalty in performance. It makes it clear that some people have most time to optimize for a benchmark than others. This benchmark on state-of-the-art cryptography shows that GC-ed languages including Go and Nim can be 2x faster than Rust: - https://hackmd.io/@gnark/eccbench#Pairing https://hackmd.io/@gnark/eccbench#Pairing (old benchmarks, in particular Nim had a parameter passing issue/bad copy behavior on large types) Furthermore, Nim GC/memory management is type-dependent, only seq/string (which use malloc/free) and `ref T` type (which use refcounting) involves some runtime. So Nim devs can choose to opt-in in GC or use manual memory management depending on their priorities.