5 ms·

They also considered only Lua 5.1, when Lua is on 5.3 already (and soon to be 5.4).

by Zelizz 7y ago

MereInterest 7y ago
Lua 5.1 is the last version supported by LuaJIT, which is probably why they used it.
uep 7y ago
Lua 5.1 has LuaJIT, which is quite fast. Performance was obviously a priority, and since LuaJIT doesn't support newer than 5.1, that's probably why they used that as the point of comparison. https://luajit.org/performance.html 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/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/
- igouy 7y ago
  Please make specific criticisms. Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".
  - uep 7y ago
    That would be one reason, you could compare more language runtimes. I think the core of my issue is that it used to provide more data points, and give the user more power. I would think that the site is primarily targeted toward developers, and that we could handle a more data-heavy UI like it used to have. * 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.
    - 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/...
deleted 7y ago
[deleted]

They also considered only Lua 5.1, when Lua is on 5.3 already (and soon to be 5.4).

by Zelizz 7y ago

They also considered only Lua 5.1, when Lua is on 5.3 already (and soon to be 5.4).

MereInterest 7y ago

Lua 5.1 is the last version supported by LuaJIT, which is probably why they used it.

uep 7y ago

Lua 5.1 has LuaJIT, which is quite fast. Performance was obviously a priority, and since LuaJIT doesn't support newer than 5.1, that's probably why they used that as the point of comparison. https://luajit.org/performance.html 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/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/

igouy 7y ago
Please make specific criticisms. Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".
- uep 7y ago
  That would be one reason, you could compare more language runtimes. I think the core of my issue is that it used to provide more data points, and give the user more power. I would think that the site is primarily targeted toward developers, and that we could handle a more data-heavy UI like it used to have. * 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.
  - 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/...

deleted 7y ago

[deleted]