Austin said:Okay, to be completely fair: yes, the GCLS is presented as "purely for
entertainment purposes only." At least that's what is said on the GCLS
website, which makes it the operating theory, at least.
In practice, though, the Alioth shootout is heavily promoted by the
people what run it and others, and there are comparisons between
different languages and little is done to make sure that the various
languages don't cheat (I found a cheat in the Perl implementation of the
Ackermann and a sort-of-cheat in the Python implementation).
There's a
whole veneer of respectability about this particular set of tests,
complete with the encouragement to "make your language perform better."
In other words, for something that's "for entertainment purposes only,"
there's a lot of time spent making it look "legitimate."
When the people who run it are confronted with this, they fall back on
the "it's not serious" line ... while very shortly after doing something
that suggests that it is, indeed, serious.
The Alioth shootout is dishonest in its presentation and purpose. It
does *more* than place "performance" numbers on the screen; it offers an
interpretation of those numbers ... all the while pretending not to
offer said interpretation.
Austin said:The best option for this shootout is to NOT implement anything for it.
The people running it don't know the first thing about what they're
doing and won't take responsibility for the errors in methodology and
the fact that their presentation encourages bad interpretation. The
Alioth shootout is dishonest to its core.
This is baseless abuse.
Lothar Scholz is demonstrably correct - some pure Ruby programs will
be hundreds of times slower than optimized compiled code, and some
programs will be as little as 1.5x slower.
Whether that matters or not depends on what we're trying to
accomplish.
Austin said:Incorrect. This is not baseless abuse. It is accurate based on numerous
discussions in which you have been involved. You refuse to acknowledge
that the shootout encourages bad interpretation (e.g., the whole "lang
v. lang" comparisons, the graphs, etc.), and you refuse to modify the
way that the whole idiotic enterprise works to discourage such bad
interpretation.
That's actually an irrelevancy and, itself, is a bad interpretation.
Hand-tuned assembler will often be much faster than even optimized
compiled code. Do you want to write everything in assembler? I thought
not.
And what I'm trying to accomplish is to convince people to stop using
your stupid project, because your project is based on dishonest
pseudo-statistical comparisons and idiotic "benchmarks." At least have
the honesty and decency to start admitting you don't know what you're
doing and start *removing* some things from the web pages that encourage
bad interpretation.
As to your other post,
http://groups.google.com/group/comp.lang.ruby/msg/696a3b04c450815c?hl=en&
I haven't submitted a bug because I think that
the whole project is a waste. The only bug report that I'd submit would
be "shut the whole damned things down." Of course, you'll ignore it.
There is also the point that while your pages may not explicitly state
that one should improve the performance of one's own language,
there is
strong implicit encouragement toward such, and the blind acceptance of
tests that are on the verge of cheating (e.g., the Perl Ackermann; the
Python Ackermann isn't far off, either, given that it won't run at all
without one particular non-algorithmic line, while not running the Ruby
Ackermann with OS configurations that *will* let it run) indicate that
you really are as clueless as I think you are.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.