[REBOL] Re: RFC: Cross-language benchmark proposal
From: joel:neely:fedex at: 7-Nov-2002 16:38
Hi, Jan,
Jan Skibinski wrote:
> I do not mind such classification and I do not particularly care
> that much about it. You are the boss in this project, so go
> ahead, set the rules and I will comply. :-)
>
Heavens to Murgatroyd, no! ;-) I'm just contributing my opinion
and everyone else is free to do so as well!
> I was just fiddling with something else and it suddenly appeared
> to me that I could reuse it in Ackerman. I'll post that little
> gadget separately.
>
I'm eager to see it.
> However I do not understand your quotation marks around my
> 'transformation word.:-)
>
Only because I was quoting it, not taking credit for the idea! ;-)
> A technique of program transformation is considered to be
> a good thing, since it quite often offers a refreshing view.
>
I completely agree, especially if we're talking about computing and
programming in general. But when we're comparing implementations
of programming languages, I think it's reasonable to put the focus
on what the *implementations* can do with the same design, rather
than how clever different *programmers* can be at coming up with
variations on the design.
> As long as two things are equal they are "referentially
> transparent". This is what Haskell is all about (aside from the
> laziness): you can always substitute LHS by RHS _everywhere_
> in your program and you do not have to worry about side effects
> and changes to semantics. I took great care to comply with this
> principle in the example posted.
>
We're emphatically in agreement here about the desirability of
referential transparency as a principle of programming and language
design. (In the past I think I offended some people by pointing
out lapses of ref. trans. in REBOL.) But, again, that was in a
different context than the present discussion of benchmarking how
well different implementations of different languages handle a
high-level description of an algorithm.
> And here is a fine line: if a compiler did exactly what I have
> done you would not complain, would you?
>
No. And let me give a concrete example. Suppose I wanted to test
how efficiently some language handled looping and simple arithmetic,
and so wrote something like the following:
loop-and-add: func [n [integer!] /local t i sum] [
t: now/time/precise
i: sum: 0
loop n [
sum: sum + i: i + 1
]
t: to-decimal now/time/precise - t
print [n sum t]
]
I might also want to test how efficiently the language handled
recursion, and so might write something like this:
recur-and-add: func [n [integer!] /local t sum] [
t: now/time/precise
sum: _recur-and-add 0 n
t: to-decimal now/time/precise - t
print [n sum t]
]
_recur-and-add: func [t [integer!] n [integer!]] [
either n = 0 [t] [_recur-and-add t + n n - 1]
]
If another programmer came along and observed, "You know that
you can perform the computation of both of these functions faster
with this:
triangle-sum: func [n [integer!]] [print [n n + 1 * n / 2 0]]
so why not use that instead?", then I'd have to respond, "Because
I want to see how smart the compiler/interpreter is, not test my
own abilities."
OTOH, if the compiler/interpreter had an optimizer that could
accept the sources for LOOP-AND-ADD and RECUR-AND-ADD and auto-
matically transform either/both into TRIANGLE-SUM, then I'd be
very happy indeed with the implementation!
Same issue as with tail-recursion-elimination (an issue which
comes up on the list every so often). As human programmers go,
it should be old news, but it's still significant to know
whether a given language implementation can do it automatically.
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
