[Ecls-list] Some improvements

[Gabriel Dos Reis]

On Sun, Jul 5, 2009 at 2:04 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Sun, Jul 5, 2009 at 3:08 AM, Gabriel Dos
> Reis<gdr at integrable-solutions.net> wrote:
>>> - Function calls are very expensive.
>>
>> Do you mean 'C' function calls,
>
> Yes

Hmm.

I suspect it depends on the type of calls.

   (1) normal call in a PIC code is slightly slower than in non-PIC
code; but normally
        the difference is insignificant -- unless the function is
doing nothing and it
        called a gazillions of times in critical path.
  (2) indirect calls are slower than call in (1)
  (3) varargs calls are slower than (2), and C compilers traditionally
don't try to
       optimize them much -- probably because C programmers don't use varargs
       functions in performance-critical path  (you may call it
chicken-egg problem).

>> PIC is relatively slow compared to non-PIC; but that is the price one
>> pays for using dynamically linked objects...
>>> - SBCL can avoid these problems because it does not use PIC code: it
>>
>> Hmm, I'm not sure I understand that.
>
> I think I did not make my point clear by using too much jargon. SBCL
> knows the addresses of all functions and objects because it
> manipulates the whole memory and has explicit assumptions on where it
> is going to "live". Hence it does not use PIC for its own code: it
> calls its own functions directly by address or by locating them on a
> table whose address is also hard coded. Same goes for symbols: SBCL
> knows their address and can directly find the function objects in
> them.
>
> In contrast, C compiled code, at least on OS X, has to make a function
> call to find out where data and code lives. This is done only once per
> function, and only if we refer to the data segment (i.e. global
> variables),

Yes, that is the way ELF or similar technology (including MACH) work.

> or when we have switch statements, but it makes function
> calls, accessing data and other things slower.
>
> It seems that some of these problems do not exist on ELF platforms,
> but I will have to investigate that.

I'm familiar with the ELF technology, but much less with others.
I think the now defunct a.out format needs less indirections, at the expense
of making shared libraries hard and non-scalable.

>
> BTW, I think I have been able to hack a type inference pass into the
> old compiler. The advantage of the separate path is that it keeps
> track of the changes in the types of variables along different
> branches of code. I am doing tests right now and the code seems to be
> optimal for AREF/ASET and float operations -- the only things for
> which I had time to hand code the type inference routines --. I only
> hope I am not claiming victory too early :-)

:-)

-- Gaby