[Ecls-list] Some improvements

[Gabriel Dos Reis]

On Fri, Jul 3, 2009 at 8:03 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> I have been optimizing ASET / AREF (actually the C versions
> ecl_aref/aset which are used in compiled code) and learned a few
> things.
>
> - Function calls are very expensive. Currently ecl_aset still has an
> additional function call that involves the unchecked version, and a
> function call to create integers/floats from the array data.

Do you mean 'C' function calls, or ecl function calls (using ECL's calling
convention)?

>
> - PIC code is also horribly slow. This kills us sometimes when we use

PIC is relatively slow compared to non-PIC; but that is the price one
pays for using dynamically linked objects...

> constants, or when a function has a call to an error function. In this
> case the function will call a library function to find out the data
> segment address even if the data is _never_ used.

Is that something that can be inferred from the ECL intermediate
representation?

>
> - SBCL can avoid these problems because it does not use PIC code: it

Hmm, I'm not sure I understand that.  It does look to me that SBCL
generates PIC code (for instance they support FFI only through shared objects
and they fiddle a lot with the GOTs).

> knows the address of everything. Of course, that makes it harder for
> SBCL to cooperate with the OS.

Hmm, I don't understand what you mean.  SBCL offers one of the best
FFI among free Lisp implementations (except on Windows, of course).

>
> - Use GCC >= 4.2. The GCC 4.0 shipped with OS X sucks.

I cannot comment on that.

>
> - GCC refuses to optimize tail calls to neighboring functions with the
> same # of arguments. I do not know why. Perhaps because of the
> debugging flags.

Hmm, normally -foptimize-sibling-calls is automatically enabled at
optimization levels 2 or higher.  If you can show a relatively self-contained
testcase, then should fill a GCC bug report.

>
> - Order of IF/ELSE branches in C code matters.

As on most compilers :-)

If you have an idea about the branch prediction, you can use
(when compiling with GCC) __builtin_expect.

>
> Some of these things can be circumvented. For instance ecl_aref() has
> now decreased a 25% execution time, based on some trivial benchmarks,
> just from removing a branch jump and reorganizing the error signalling
> code.


-- Gaby