3 ms·
(2021) - rehashing a paper published in 2017... I think I still remember the discussion from back then, and it centered (as usual) around doubts if samples fro
by rob74 3y ago
(2021) - rehashing a paper published in 2017...
I think I still remember the discussion from back then, and it centered (as usual) around doubts if samples from Computer Language Benchmarks Game are really representative, and if some of the differences aren't due to the different levels of polish that the solutions in some languages have vs. others.
- nsajko 3y agoWhy would you think the Benchmarks game is relevant in any way?
- igouy 3y agoWhy would you think measurements of a tiny tiny number of tiny tiny programs have something definitive to say about the immense variety of software in-use?
- bayindirh 3y agoComputers are simple machines. The simpler your output assembly is, your code will be faster. The less safeguards your language or compiler forces on your output assembly, your code will be again faster. C has the least number of safeguards, and most foot-guns by default, unless you opt-in to more. Same is for C++. There are very legitimate reasons where you don't want bound checking in your arrays in some applications, and you can realize these in C and go really fast if you need to. Tangentially, FORTRAN is a "FORmula TRANslator", so it's good and fast at math too. Because it is designed to do that. If you think FORTRAN and C are obsolete. Come to HPC domain, where you push languages and hardware to the limits without leaking memory and crashing randomly.
- igouy 3y agoWhat could possibly be "really representative" of the immense variety of software in-use?