https://luajit.org/performance.html
There used to be some great benchmark comparisons including luajit on the programming language benchmark site[1], but I swear that site has gotten worse as time has gone on.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/
Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".
* There used to be more languages and runtimes shown.
* The site makes decisions for you about which languages you want to compare, whereas before it used to give the user more power. It used to be easier to compare arbitrary languages with each other. I think you could see the "How many times slower?" graph on individual language pages, but it has been a long time since that was on there.
* Related to above, it seems like it changed to be a more mobile-friendly format. I'm not inherently against that, but if it means I get less points of comparison, I am.
* You used to be able to see examples of run-times on multiple machines. It's less relevant now since everything is multi-core, but it did mean that there would be single and multi-thread implementations of some programs, and you could see how they were written and performed differently.
There are other reasons. Most of these are related to each other, and to be clear, I still like that the site exists, and that it provides useful metrics.
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/...
> > … 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.
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)
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/20150221172620/http://benchmarks...