Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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