This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: interface reductions


On 25 May 2000, Mikael Djurfeldt wrote:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > > SCM_FAST_FLUID_REF    --> scm_fluid_ref
> > > SCM_FAST_FLUID_SET_X  --> scm_fluid_set_x
> 
> These were provided from the start.  As explained in the commentary in
> fluids.h, the purpose is to provide a fast fluid access method.  This
> is also reflected in the names.
> 
> Q: Why would you need fast access to fluids?
> 
> A: The aim is of course that *all* thread-local SCM-type state
>    information in Guile should be represented by fluids.  Currently
>    time-critical such information is stored in the root state, but
>    we plan to remove the root state.  Then SCM_FAST_FLUID_REF will
>    probably be needed.
> 
> My guess is that the original motivation for providing them was to
> encourage people to use fluids instead of adding things to the root
> state.
> 
> I don't think these macros restricts the implementation of fluids.  I
> think they are pretty OK.

But, then we should at least also provide SCM_FLUID_REF.  Currently to
have fast access to a fluid, you have to do:
  SCM_FAST_FLUID_REF (SCM_FLUID_NUM (x))
i. e. you can't even avoid to work with the implementation detail that
fluids are stored in a vector.  Thus, to at least remove this problem a
bit, I suggest:
  #define SCM_FLUID_REF(x)  (SCM_FAST_FLUID_REF (SCM_FLUID_NUM (x)))
  #define SCM_FLUID_SET_X(x, v)  (SCM_FAST_FLUID_SET_X (SCM_FLUID_NUM (x), (v)))
Then, the difference between SCM_FLUID_REF and SCM_FAST_FLUID_REF is, that
the first requires one additional memory access, namely to the CDR of the
fluid.  However, it's still faster than calling the scm_fluid_* functions.

(I think it's still questionable to keep the _FAST_ variants, since it's
somewhat unlikely that people will store the fluid number for longer
times.  And, if they do, it's even probable that later accesses to that
number will also cause a memory access.  In contrast, in a more local
context the compiler should be able to eliminate redundant accesses to the
CDR of the fluid.)

Best regards
Dirk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]