[Shootout-list] Stuff (benchmark design)
Bengt Kleberg
bengt.kleberg@ericsson.com
Wed, 27 Apr 2005 12:42:52 +0200
skaller wrote:
> On Wed, 2005-04-27 at 16:09, Bengt Kleberg wrote:
>
>
>>if the design of the benchmark allows something, then this solution
>>should be allowed to be the ''real'' solution. it should not be judged
>>unfit, becuse it is different to how other languages have solved the
>>design requierments.
>
>
> Which is of course impossible in principle for
> any 'same way' tests because the whole purpose
> of the Shootout is to measure the differences
> between languages that necessarily do NOT do
> things the 'same way'.
i apologise, but i do not follow your reasoning here.
do you mean that it is impossible (in principle) to allow a solution to
be the ''real'' solution even if it obeys the constraints of the
benchmark, but does something different than the other solutions?
why?
> So benchmarks should not be allowed to 'allow' or 'disallow'
> anything. They should simply specify the inputs and outputs
> required and perhaps constraints on resource usage:
> what happens in the 'black box' in between is up to the
> test implementor and should be judged entirely on the
> basis of whether it produces the correct result (whilst
> limiting its resource usage as required).
>
> This kind of condition is easy to measure mechanically
> without too much argument.
i see a danger here. the shootout exels in very few inputs. it is even a
''pride'' thing. (narrow focus, etc). take fannkuch. input is 7, 8 and 9.
Correct output N = 7 is:
Pfannkuchen(7) = 16
i could make a very simple black box that handles input/output correctly
amd that is about as fast as ''hello, world''.
so only input/output and black box is not sufficient test design. imho.
bengt