3 ms·
Fair benchmarking is really hard. It is much better to compare languages on features, safety, programmer efficiency etc. But you can't boil that down to a singl
by dtech 6y ago
Fair benchmarking is really hard. It is much better to compare languages on features, safety, programmer efficiency etc. But you can't boil that down to a single number.
The most fair benchmarks I've seen are to implement strictly numerical algorithms, but that's not very userful because you're basically testing a small piece of compiler/VM optimization at that point. It also leads to unidiomatic code because it's faster, e.g. "C in Java".
The most useful benchmarks I've seen are exercises where programmers of different languages try their best to create as fast a program in their language as possible. It allows you to see idiomatic v.s. fast code in that language. Downside is you're testing for a large part which contributors you've managed to catch.
- craftinator 6y agoFair benchmarking is really hard! But I appreciate this style, because it shows two basic "real world" examples that you can extrapolate/estimate the results of. If Crystal is compiling to smaller binaries that run faster in a basic test without a lot of optimization and configuration tweaking, you can imagine that that relationship will hold true in larger codebases as well. Also very important is that the style, verbosity, and clarity of both examples showcase the differences in the languages on the programmer's side.
- pdimitar 6y ago> * If Crystal is compiling to smaller binaries that run faster in a basic test without a lot of optimization and configuration tweaking, you can imagine that that relationship will hold true in larger codebases as well.* Why would that be the case? I see no correlation. The two programs in the article were little more than glorified "hello, world" samples. For all we know, Crystal might accumulate binary code cruft much quicker than Go as the project grows.