Hacker News new | ask | show | jobs
by SwellJoe 3307 days ago
Hey, the benchmark game got a new website (at some point in the several years since I looked at it last)! Almost simplistic, but nice to read.

As someone that works predominantly in a language long considered passé (Perl), I always kinda relish seeing that it is still faster than Python and Ruby for many problems. As Python and Ruby have gotten faster, I'd sort of assumed they were both notably and clearly faster than Perl, by now, but that's not the case though the difference is now quite small and probably debatable.

3 comments

Python was never really designed for speed. It was designed for simplicity and clarity of behaviour. The beauty of the age we live in is that we have such a broad array of tools to apply to different problems. Performance is often not the problem that needs solving, but when it is, you've got many options too!
I'm not disparaging Python (or Ruby). Merely taking small pleasures where I find them. I work in Perl because of a huge array of existing code in Perl, not because I hate Python or Ruby (I've built stuff in Python and Ruby, too, and like them both).
Perl is only faster here in nbody because I tricked it. I used a tricky compile-time optimization for faster array index access. You wouldn't do that in the real world, and in the real world PHP, ruby and python are faster. cperl instead is only beaten by PHP. But the benchmark game is not open for faster alternate engines like luajit, nim, crystal, pypy, truffle-graal, ... or even slower ones like Perl6, which limits the impact of those better engines.

Decades ago it was open and written in Perl. Then it was rewritten in Python and closed down. Go figure.

>> a tricky compile-time optimization for faster array index access. <<

And you even comment on that usage in your code.

>> Decades ago it was open and written in Perl. Then it was rewritten in Python and closed down. Go figure. <<

At best your comment is disingenuous.

You can download the Python measurement scripts, use them with luajit, nim, crystal, pypy, truffle-graal or Perl6 programs and publish the measurements.

You don't. Go figure.

Perhaps this is merely a reflection of the difficulty of finding where to download the measurement scripts? I found them (here: http://benchmarksgame.alioth.debian.org/play.html ) but, it took some clicking. Maybe a github link on the front page, or similar, would alleviate some of the frustration the previous poster had about it.

I assumed the sources were available, somewhere, but until I went looking for it, I wouldn't have been able to say so with confidence. That's not an obligation, of course...volunteers should feel free to do whatever they want with their projects. But, if you wanted to keep the community involvement the game had historically, linking source in the lingua franca of the day (github or gitlab, or whatever, seems pretty standard today) would go a long way.

Perhaps, so I just googled "download benchmarks game scripts" -- 4th URL on first page of results.

Perhaps it's merely a reflection of wanting some one else to do work we choose not to do.

(You'll find that there already are duplicates of the benchmarks game repos on github).

"Perhaps it's merely a reflection of wanting some one else to do work we choose not to do."

Entirely valid position to take. There's only so many hours in a day, so many days in a year, and so many years in a life.

rurban (and frik and wulfklaue) do not seem to feel that it is a valid position for me to take.
If course I have the benchmarks, because that's how everybody benchmarks it. But rather with the old perl scripts, not with your new python scripts. They suck. Before it was trivial to bench, but not trivial to setup all the environments.

The problem is not that someone else can do it, the problem is YOU need to do it. You got the name reserved for it, you got the machines to do it, you decide to rewrite it and throw them out, no one is looking somewhere else for better and more benchmarks.

The big competitors with better and faster engines have no incentive to match performance when their name is not on the list, and they just publish their own results. Users don't look somewhere else.

>> Before it was trivial to bench, but not trivial to setup all the environments. <<

That's what it's like now -- trivial but time consuming.

There were pain-points with the old perl scripts (and nested make files) but I would have continued to put-up with the problems and would have continued to use the old perl scripts.

But (back in 2008) I couldn't see how to set-affinity with Perl and I could see how to do that with Python.

That's why I rewrote the measurement scripts in Python.

>> They suck. <<

https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writ...

>> You got the name reserved for it <<

Wow! Think-up a name!

>> you got the machines to do it <<

I have one too-old machine.

>> no one is looking somewhere else for better and more benchmarks <<

55% of page views are from "organic search".

Dude. What's up with attacking someone who does things voluntarily (I presume) for not doing them the way you want them to? That's pretty damned presumptuous.

Open Source stuff really only ever has one guarantee: If it breaks, you get to keep the pieces.

You can put it back together any way you want, but you can't demand they give you a new one that meets your expectations. Unless you want to pay them to do so, and they're willing to accept the money and terms.

>> new website <<

Dec 2015. Pleased you find it nice to read.

Are you the maintainer? Thanks for keeping it running all these years, if so.

I don't go there often, but it's nice to know there's a way to get a vague understanding of relative performance for languages for those occasions when one needs to know "is it fast enough?"

>> Thanks for keeping it running all these years <<

Thanks to all those who contribute their expertise and their programs.