3 ms·

> There used to be more languages and runtimes shown. True — https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.h

by igouy 7y ago

> There used to be more languages and runtimes shown. True — https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#maintenance-burden https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > It used to be easier to compare arbitrary languages with each other. True; and a couple of years of Google Analytics showed that there were one or two people who did. The massive majority made the same comparisons, so it was made easier for them. > … "How many times slower?" graph on individual language pages… True; and intentionally removed to force a slower look at the measurements. > … single and multi-thread implementations of some programs… There still are — look at "busy" and "cpu load" instead of elapsed "secs". > …we could handle a more data-heavy UI … Open the data files in a spreadsheet: https://salsa.debian.org/benchmarksgame-team/benchmarksgame/tree/master/public/data https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

uep 7y ago
I was fully aware that my criticisms were unlikely to be taken seriously. Otherwise, why would the site have changed from what it was before? > > … single and multi-thread implementations of some programs… > There still are — look at "busy" and "cpu load" instead of elapsed "secs". I do want to clarify this point. I'm aware of the "cpu load" section of the results. That is not at all the same thing. I don't think this was necessarily even intentional before, but the fact that both systems existed, meant that contributors could explicitly optimize for either single-threaded or multi-threaded. A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core. It will also probably look completely different.
- igouy 7y ago
  I did take your comments seriously. Have you taken my point-by-point response seriously? I acknowledged your "criticisms" that "there used to be more languages and runtimes shown" and that "you used to be able to see examples of run-times on multiple machines". Do you acknowledge that those "criticisms" sound a lot like someone saying — give me more free stuff ? > …contributors could explicitly optimize for either single-threaded or multi-threaded… They still can; have you noticed that the Chapel programs are optimized for program size? > …single-threaded … will likely smoke a locking multi-threaded… Look at the programs — https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm-cpu.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... 15.82 (busy) Ada 2012 GNAT #3 (15.79 cpu) 15.89 (busy) Ada 2012 GNAT (15.69 cpu) 15.84 (busy) Free Pascal #2 (15.82 cpu) 16.15 (busy) Free Pascal (15.98 cpu) https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/fpascal.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- igouy 7y ago
  > A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core Do you claim the single-threaded program will speed-up on single-core? Do you claim the multi-threaded program will slow-down on single-core? We can look in the Internet Archive and see neither of those things happened — Free Pascal mandelbrot #4 program [multi threaded] 68.18 elapsed secs, 68.15 cpu secs [single core] 17.07 elapsed secs, 68.14 cpu secs [quad core] Free Pascal mandelbrot #3 program [single threaded] 75.47 elapsed secs, 75.43 cpu secs [single core] 75.47 elapsed secs, 75.44 cpu secs [quad core] https://web.archive.org/web/20150221165617/http://benchmarksgame.alioth.debian.org/u64/performance.php?test=mandelbrot https://web.archive.org/web/20150221165617/http://benchmarks... https://web.archive.org/web/20150221172620/http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot https://web.archive.org/web/20150221172620/http://benchmarks...

by igouy 7y ago

uep 7y ago

I was fully aware that my criticisms were unlikely to be taken seriously. Otherwise, why would the site have changed from what it was before? > > … single and multi-thread implementations of some programs… > There still are — look at "busy" and "cpu load" instead of elapsed "secs". I do want to clarify this point. I'm aware of the "cpu load" section of the results. That is not at all the same thing. I don't think this was necessarily even intentional before, but the fact that both systems existed, meant that contributors could explicitly optimize for either single-threaded or multi-threaded. A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core. It will also probably look completely different.

igouy 7y ago
I did take your comments seriously. Have you taken my point-by-point response seriously? I acknowledged your "criticisms" that "there used to be more languages and runtimes shown" and that "you used to be able to see examples of run-times on multiple machines". Do you acknowledge that those "criticisms" sound a lot like someone saying — give me more free stuff ? > …contributors could explicitly optimize for either single-threaded or multi-threaded… They still can; have you noticed that the Chapel programs are optimized for program size? > …single-threaded … will likely smoke a locking multi-threaded… Look at the programs — https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm-cpu.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... 15.82 (busy) Ada 2012 GNAT #3 (15.79 cpu) 15.89 (busy) Ada 2012 GNAT (15.69 cpu) 15.84 (busy) Free Pascal #2 (15.82 cpu) 16.15 (busy) Free Pascal (15.98 cpu) https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/fpascal.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
igouy 7y ago
> A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core Do you claim the single-threaded program will speed-up on single-core? Do you claim the multi-threaded program will slow-down on single-core? We can look in the Internet Archive and see neither of those things happened — Free Pascal mandelbrot #4 program [multi threaded] 68.18 elapsed secs, 68.15 cpu secs [single core] 17.07 elapsed secs, 68.14 cpu secs [quad core] Free Pascal mandelbrot #3 program [single threaded] 75.47 elapsed secs, 75.43 cpu secs [single core] 75.47 elapsed secs, 75.44 cpu secs [quad core] https://web.archive.org/web/20150221165617/http://benchmarksgame.alioth.debian.org/u64/performance.php?test=mandelbrot https://web.archive.org/web/20150221165617/http://benchmarks... https://web.archive.org/web/20150221172620/http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot https://web.archive.org/web/20150221172620/http://benchmarks...