On 6/10/05, Isaac Gouy <igouy / yahoo.com> wrote:
> > Also, the tests must use the exact same algorithm, so this
> > disadvantages Ruby is some situations.  I say the test should compare
> > same algorithms, but also the one best suited to the language.
> Do this disadvantage Ruby more than PHP?
> Or more than Tcl, or more than GNU Smalltalk?

When the algorithm, as entered, won't complete, yes. When compared
against a language that has tail recursion optimisation, or a possible
situation where optimisation of the compiler deals with recursion
intelligently? Yes.

The definition of Ackermann numbers is, I presume, well known. Because
some platforms can't modify their stack level (Windows), and because
the stack level isn't modified in the runs for the benchmark, there's
going to be an issue with the deep recursion. In this case, it would
be appropriate to reduce the level of recursion. But given the rules
mentioned, this isn't acceptable.

What's the *purpose* of something like the Ackermann test? Is it to
see how quickly the environment winds and unwinds the stack? How much
state it carries around?

I personally think that most of the shootout items are bogus in just
about every way. Don't get me wrong -- I'm not at all suggesting that
Ruby couldn't be faster. I'm just saying that benchmarks, like
statistics, are lies.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca