Nicolas,
I agree that the shootout benchmarks are often so small as to be
pointless, and also that the design of the benchmarking system is
definitely not tuned to lisp/scheme style. Nevertheless, I do think it
would be a useful optimization to have some sort of immediate
double-float representation, at least for purely local functions.
(Maybe I'm just coming from a scheme background and thinking of loops
this way, but it seems to me that there are plenty of times when I
would love to have a functional approach -- i.e. composition -- where
intermediate doubles are not boxed yet the functions are not suitable
for inlining.)
However, I can understand wanting more than my desire before making a
significant change to sbcl internals :).
Will
On 23 Feb 2005, at 4:24 AM, Nicolas Neuss wrote:
> "Will M. Farr" <farr@...> writes:
>
>> Hello,
>>
>> Just for fun, I was trying to speed up the SBCL implementations of
>> some of
>> the short benchmarks on the Computer Language Shootout page
>> (http://shootout.alioth.debian.org ). The takfp benchmark, in
>> particular,
>> is one where the SBCL implementation seems needlessly slow.
>
> Hmm. This shootout is getting worse and worse. Why does this guy
> include
> such completely useless test functions? Why not computing integer
> factorial(1000)? (Answer: because C and C++ cannot do this easily.)
> This
> would at least have a little sense behind it...
>
> Yours,
> Nicolas.
>
> P.S.1: Don't understand me wrong: having float values returned in
> registers
> would be nice, of course, but the TAKFP function does not at all
> convince
> me of the necessity for this feature. And number crunching
> applications
> avoid such functions anyway and operate destructively on arrays of
> floats
> instead.
>
> P.S.2: I have commented on this shootout some time ago in cll, see
>
> http://groups.google.com/groups?q=g:
> thl410376093d&dq=&hl=de&lr=&selm=87isdsj5ak.fsf%40ortler.iwr.uni-
> heidelberg.de
> It may be worthwile to read this message (and also the whole thread).
|