From: John Carter <john.carter@...>
Date: 2006-05-24T06:39:01+09:00
Subject: Re: How to Improve Performance Now. Re: Zed and Luis drop the 	bombonRuby's poor performance

On Tue, 23 May 2006, Austin Ziegler wrote:

> On 5/22/06, John Carter <john.carter@tait.co.nz> wrote:
>> Ruby is based on gcc, gcc has grown some nifty ways of speeding things
>> up.
>
> No. Ruby is *not* based on gcc. Ruby is based on ANSI C. Any
> GCC-specific performanced boosts would reduce Ruby's portability.

And so? Nothing I suggested would reduce Ruby's portability, and the
Function inlines is based on C99 standard and is available on
practically any compiler that also does C++.

> Be careful that those optimizations don't omit stack frames. You'll
> get an unusable Ruby.

By default it doesn't on x86 since that makes programs hard to debug.
But you can make that explicit with -fno-omit-stack-frames

>> Ruby is _not_ gcc warning clean. Some gcc warnings are actually performance 
>> related.
>
> Ruby should try to be clean on all compilers that don't try to give
> you warnings about compiler-specific things (like Visual Studio's new
> warnings about deprecated functions like printf).

Things like alignment and strict aliasing improve speed on most
compilers / platforms.

> All that said, the best thing one can do to improve the performance of
> one's Ruby script is to have hard numbers about where your script is
> performing poorly and being absolutely *certain* that it's Ruby and
> not your algorithm. (That is, I know exactly why PDF::Writer is as
> dramatically slow as it is; I just don't have a fix for it, yet.)

At no stage have I ever blamed Ruby for the slowness of my scripts, most
times Rubies power and flexibility has enabled me to use faster
algorithms.

The following items are each an order of magnitude less important in
matters of speed.
* Scope - Try doing less.
* Algorithm 
* Code Optimizations.
* Ruby Interpreter Optimizations.

Even though the Ruby interpreter optimizations are the least effective
optimization, they have the nice property of applying instantly and
cheaply to all scripts.

My aim is not to complain about the weather, but to suggest simple
concrete actions that can be taken by the Ruby community to improve the
speed of the _current_ Ruby interpreter for most applications.

* Provide a performance benchmarking suite that is relevant to the
   Ruby user community. 
* Adopt a file and make it -Wall -W (perhaps with a sprinkling of -Wno-)
   clean.
* Tweak the configure and automake to use profiling & coverage options in
   gcc to...
   - Give a coverage report on our test suite.
   - Give a profile report on the performance benchmark.
   - Perform profile based branch prediction.
* Provide instructions / and perhaps a ./configure --option to use
   -march= and/or -mtune
* Analyse the coverage report and generate new test cases to extend coverage.
* Analyse the profile report and contemplate performance tweaks.
* Produce cachegrind reports and contemplate performance tweaks. (eg. Simple one is
   sometimes -Os does better than -O3 for cache reasons!)

What I have proposed is ...
   * Concrete.
   * Simple to do.
   * Every Ruby user can pick an item on this list and contribute some small
     but meaningful thing.
   * It doesn't push the problem onto some magical someone or something else.
   * Much is reusable even if we do go to YARV or whatever.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.