chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] two minor tweaks to runtime.c


From: Alex Shinn
Subject: Re: [Chicken-users] two minor tweaks to runtime.c
Date: Thu, 29 Sep 2011 10:30:00 +0900

On Wed, Sep 28, 2011 at 4:29 AM, Alan Post <address@hidden> wrote:
>
> I don't have enough data to say that it matters in this case, but in
> principle it surely does.

"In theory, theory and practice are the same.  In practice,
they're different."

The problem here specifically is the lack of data.  Why even
bother with a change like this without benchmark results to
prove it's worth it (preferably tested across all the variety
of platforms Chicken compiles on, with wildly differing branch
prediction features)?

The proper way to optimize is:

1) DON'T!  Just write an application.  If it's too slow
for your purposes, then move on to

2) Profile.  Find out where all the time is being spent.
There's no point in optimizing something if it's not a
significant factor in you performance.

3) Of the code sections you've determined the most
time is being spent in, choose the one with the best
estimated speedup-to-effort ratio.  You should have
an intuition that the code in question can be improved,
either algorithmically (potential huge speedup) or by
tuning (smaller speedup, usually uglier code, but
may be less effort).  Making this choice is something
of an art, but is completely impossible without 2.

4) Write benchmarks that isolate what you want to
optimize.  Measure how fast the current solution is,
if possible compared to alternative implementations
or equivalent tasks in other languages.

5) If you don't already have a test suite, write one
now that verifies the code used in the benchmark.
It's too easy to write an optimized version of something
that performs better initially, but worse once you fix
the bugs in it.

6) Try one or more optimizations, and measure them
compared to the result in 4 once they've passed the
tests in 5.  Iterate as often as you have time/ideas.

7) Of the best results in 6, determine if the speedup
they introduce is worth the complexity they introduce.
Keep in mind the maintenance cost will persist long
term, and be shared by other people who want to
work on the code.

8) Document what you tried regardless so people
don't waste the same effort again!  Include a one-line
comment in the code itself with a link to more info
if needed, e.g.

  ;; The following is a little ugly, but performs best in
  ;; practice - see benchmarks/widget-hack.scm.

9) Send a patch to the list with the benchmarks
and tests as proof that the optimization is worth it.
If you've come this far, the maintainers will almost
certainly accept it.

-- 
Alex



reply via email to

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