On Sun, Jul 5, 2009 at 2:04 AM, Juan Jose
> On Sun, Jul 5, 2009 at 3:08 AM, Gabriel Dos
> Reis<gdr@...> wrote:
>>> - Function calls are very expensive.
>> Do you mean 'C' function calls,
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
>> 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
> 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
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 :-)