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

[Alan Post]

Will you show me this data for the current implementation?

-Alan

On Thu, Sep 29, 2011 at 10:30:00AM +0900, Alex Shinn wrote:
> 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
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users

-- 
.i ma'a lo bradi cu penmi gi'e du