I think one way to deal with the problem of high speed but ugly code
would be to change the acceptance criterion. Instead of just keeping
the fastest solution (and sometimes some novel ones), keep the best
implementation based on a weighted average of the two factors (code
size and speed). Of course that still requires that the communities
submit new solutions.. and care about more than being speed kings.

As for the restrictions on implementations, they can always be argued,
it's a fine line.. but the problem they are trying to solve is the use
of language tricks that circumvent solving the problem.. such as a
language that offers a method in the languages standard library that
says "solve benchmark" and it's written in assembly in the library.
There were specific cases in older versions that really skewed
results. But as I said originally.. you have to be careful there.

Alan

On Tue, Jun 2, 2009 at 6:50 AM, Brandon Van Every <bvanevery@...> wrote:
>
>
> On Tue, Jun 2, 2009 at 1:53 AM, Jonathan Leonard <johanatan@...>
> wrote:
>>
>> Yes, but look good in terms of performance or code size? I'd prefer
>> shorter easier to maintain codes with bottlenecks optimized away where
>> required.
>
> The benchmarks seem to be saying that some bottlenecks are not going
> to be optimized away, at least not in the languages themselves. I
> guess if one accepts a "drop to C" mentality for everything and
> anything, it's not such a big deal, but the pain of debugging 2
> languages has been noted by some.
>
> Cheers,
> Brandon Van Every
>
>