[Shootout-list] Faster Ruby nbody benchmark

[Dave]

----- Original Message ----- 
From: "Isaac Gouy" <igouy2@yahoo.com>
To: "Brent Fulgham" <bfulg@pacbell.net>; "Jabari Zakiya" <jzakiya@mail.com>; 
<shootout-list@lists.alioth.debian.org>
Sent: Monday, March 21, 2005 1:34 PM
Subject: Re: [Shootout-list] Faster Ruby nbody benchmark


>> > No, to manually unrolling loops!
>> >
>> > (Doug Bagley explicitly stated that manually
>> > unrolling loops wasn't
>> > interesting, I guess we need to add the same
>> > exclusion.)
>>
>> I've been adding these approaches as "interesting
>> alternatives", which I guess flies in the face of
>> Doug's statement ;-)
>
> Ho ho :-)
>
> The Ruby program showed up as an 'accepted' program - not as an
> alternative.
>
>
>> Manually unrolling loops == more LOC, so perhaps
>> we should allow them (or as 'interesting
>> alternatives' and let the LOC metric start to
>> be taken into account?
>
> LOC isn't even a good indicator of concise syntax!
>
> For Shootout to work as some-kind-of comparison between language
> implementations (rather than programmer effort or skill), the programs
> need to be plain vanilla comparable.
>
> Yes many languages have optimising compilers which will unroll loops -
> the language implementation is doing the work, that's the point!
>
>

I have to agree with that based on what I've seen out in the "real world", 
and the time-critical code I've done myself. Very rarely will I unroll a 
loop because generally either the compiler optimizes the need away or there 
are other more expensive dependencies in the loop (other than loop control 
conditionals).

I can't recall any (even time-critical) Open Source code where I've seen 
loops being unrolled other than for maybe numerics, so I think that allowing 
loop unrolling would make the Shootout code further deviate from being 
applicable to the way most people write most software.

Let's keep the pressure on the compiler/runtime developers to figure out 
if/when/how loops should be unrolled, or at least let them try <g>

MHO.

- Dave