[drujensen]

ok, owner of the repo here. So this project was purely to show the macro differences between interpreted ruby and compiled crystal to beginner ruby devs at a meet up.

I decided to add the top languages on github to help give some idea of how crystal performed against them.

I'm happy to see so much discussion about it and was taken by surprise when my inbox was full this morning. Thanks @anonfunction. ;-)

The breaking benchmark examples were just that, examples of how to break the benchmark. I didn't expect to get a memoized version of every language and really don't think comparing them from a performance benchmark makes much sense. Let me know if i'm wrong about that.

I am fine adding all of your change requests and will try to keep the benchmarks up to date.

[HankB99]

Breaking benchmarks... Is that like the time I fiddled with the corresponding C program trying to get it to run at least in the same ballpark as the Rust version? That was until I determined that the Rust optimizer noted that the results of the 'meat' of the test were never used so it just optimized the whole thing away. :) (I thought it was a little disingenuous for the Rust folks to use this as an example of how performant Rust was.)

[petre]

I used to benchmark using fibonacci, but the recursive method is just awful because it does a lot of function calls and you're essentially benchmarking that. Then I switched to finding primes using the Sieve of Sundaram. It uses arrays, hashes/maps/dicts and two loops. Also wastes a lot of memory if you don't split your search domain into ranges. The surprise was that Go and D (in that order) turned out to be faster than Rust mainly due to Rust's HashMap SipHash algorithm. I gave up trying to use other hash libraries (SeaHash specifically) that are not part of the standard lib, because it was quite frustrating compared to D.

[igouy]

> gave up trying to use other hash libraries

fwiw a Rust k-nucleotide program using indexmap:

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

[igouy]

> really don't think comparing them from a performance benchmark makes much sense

No, it really doesn't — but if you provide times we all know that's exactly what people will do.

That's why the same comparison was removed from the benchmarks game and replaced with tasks that were still toy but more than a dozen lines.

> adding all of your change requests

These are the programs that were replaced:

https://salsa.debian.org/benchmarksgame-team/archive-alioth-...

https://salsa.debian.org/benchmarksgame-team/archive-alioth-...