[Ecls-list] Long time building of OpenAxiom with ECL 10.1.1

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> On Mon, Jan 18, 2010 at 7:49 AM, Yue Li <xyly781 at gmail.com> wrote:
> 
> > I'm a user of OpenAxiom computer algebra system. Today I used ECL cvs
> > version (10.1.1) with multithreads enabled to build OpenAxiom.[...]
> > It seems that by enabling multhreads gave a big slow down ;-(
> 
> 
> Yes, multithreading costs a huge factor because of several factors: binding
> of special variables, keeping an environment local to each thread, etc. For
> instance the lisp environment has to be stored in a thread-local storage and
> that costs _a lot_ to make in multiple systems -- it is absurd, but it is at
> least a function call for _every_ use of that storage in _every_ C function.
> Since we do not have the liberty to reserve a register for that purpose or
> having a hard-coded address for the translation table  (why the hell doesn't
> the ELF loaded do this?) the overal result is a slowdown of every function
> that uses resources such as the multiple values return array, the lisp
> stack, special variable bindings...
> 

There is no need to use function calls to access thread local storage,
at least on modern Linux (but I think that other systems borrowed the
method):

#include <stdio.h>

static __thread char *p;

void
foo(void)
{
    printf("p = %s\n", p);
}

generate:

foo:
.LFB13:
        subq    $8, %rsp
.LCFI0:
        movq    %fs:p at TPOFF, %rsi
        movl    $.LC0, %edi
        movl    $0, %eax
        call    printf
        addq    $8, %rsp
        ret

so access is just a single load (using segment register).
AFAICS on modern linux having:

extern __thread cl_env_struct * cl_env_key;

#define ecl_process_env() cl_env_key

should work and generate single instruction access to thread local
storage.

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl