This benchmark seems irrelevant (devclass.com)
from RealBot@lemmy.world to programming@programming.dev on 05 Jan 2024 12:36
https://lemmy.world/post/10345403

The benchmark with 1B rows in this blogpost seems irrelevant for comparing performance of different programming languages.

It seems like the execution time of a program would be dominated by loading data from the file. And a lot of people posted solution with specs of cpu but not specs of disk (hdd, ssd, raid) although that seems more relevant.

Why would they compare languages and solutions in this way?

#programming

threaded - newest

killeronthecorner@lemmy.world on 05 Jan 2024 12:52 next collapse

To answer your question about environmental and hardware factors - from the repo:

Results are determined by running the program on a Hetzner Cloud CCX33 instance (8 dedicated vCPU, 32 GB RAM). The time program is used for measuring execution times, i.e. end-to-end times are measured.

AlphaAutist@lemmy.world on 06 Jan 2024 05:07 collapse

That seems to only be for the Java code

How fast though is Java versus other languages? A show and tell page has submissions in Rust, C#, Go, Python, PostgreSQL, Python, C, C++, and more. These are hard to compare with one another since they have been run on different hardware, but there are some impressive results, including one under 5 seconds done with C on an AMD laptop, and a C# solution that runs in 5.3 seconds on a Core i5-12500 with 6 cores.

killeronthecorner@lemmy.world on 06 Jan 2024 12:21 collapse

The show and tell page is exactly that, show and tell; not a scientific or balanced comparison.

The original challenge only compared JDK solution in this way. Further down there is a link to another repo that does that same across many languages, and uses the same M1 MacBook Pro to run the tests.

orhtej2@eviltoast.org on 05 Jan 2024 13:30 next collapse

I would assume they want to factor in startup time as well as IO handling overhead - raw disk IO should be the same given programs are run in the same environment.

aubeynarf@lemmynsfw.com on 05 Jan 2024 13:57 collapse

For most organizations, the cost of paying programmers far exceeds the cost of CPU time; benchmarks really should include how long the solution took to envision/implement and how many follow up commits were required to tune it.

aluminium@lemmy.world on 06 Jan 2024 00:50 collapse

Also big “enterprise” Software usually becomes slow due to fundamental issues or issues in the architecture.

For example I worked on maintaining an old Java EE project and people there constantly made multiple sequencial HTTP requests despite the requests not being dependent on one another.