chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Chicken-users Digest, Vol 149, Issue 2


From: F. Rafael Leon
Subject: Re: [Chicken-users] Chicken-users Digest, Vol 149, Issue 2
Date: Tue, 7 Apr 2015 09:33:49 -0400

On Tue, Apr 7, 2015 at 7:00 AM,  <address@hidden> wrote:
> But I'm sick and tired of people throwing badly written code into the
> net and making gross assumptions about implementation performance. The
> possible options, the search-space available is massive and a little
> difference in programming style can make a vast difference in
> performance.

This is even true when benchmarking code fragments written in
different styles and run on the same implementation.

The performance variation is so severe that I write my inner loops for
numerics in C.

For an n-dimensional array, the infamous "innermost loop" is 1-dimensional.
The C code condenses down to a single "for" loop of maybe 10 lines in length.

The speed problem has thus been easily converted into a Scheme-to-C
interfacing problem.
Using chicken, I find that interfacing Scheme and C is not really much
of a problem at all.

The rest of the program is then written in chicken scheme in an
arbitrary style with no consideration of performance.
The emphasis for the scheme code is readability/maintainability etc.

Incidentally, this approach works perfectly on Android using the NDK
and some custom make files.
Even when editing the C code, I wrap it in chicken and dynamically
load it over and over again as I refine the inner loop.

No implementation is as fast as 10 lines of hand-optimized C.

After using this technique, I feel that the debate over implementation
performance seems rather silly, especially when discussing actual
numerical algorithms.  For recursion over arbitrary data structures,
another optimization approach might be needed.

In the old days, people would write inner loops in assembly.

     -Rafael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]