Hacker News Reader

Comment by igouy | Hacker News Reader

> There used to be more languages and runtimes shown.

True —

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/...

View on HN

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.

> 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://benchmarks...

https://web.archive.org/web/20150221172620/http://benchmarks...

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/...

    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/...

Reply on news.ycombinator.com