doc/ideas.txt

   1 ######################################################################
   2 ##
   3 ##    Copyright (C) 2003-2004,
   4 ##    Department of Computer Science, University of Tromsoe, Norway.
   5 ##
   6 ##    For distribution policy, see the accompanying file COPYING.
   7 ##
   8 ## Filename:      ideas.txt
   9 ## Description:
  10 ## Author:        Frode Vatvedt Fjeld <frodef@acm.org>
  11 ## Created at:    Fri Dec 12 19:19:39 2003
  12 ##
  13 ## $Id: ideas.txt,v 1.4 2007/03/15 16:11:17 ffjeld Exp $
  14 ##
  15 ######################################################################
  16
  17 ** Symbols and global variables
  18
  19   - I'm starting to suspect that there should be no global
  20     symbol-value cell. I don't think they're required, and perhaps
  21     there's really no scenario where they're the adequate solution.
  22
  23 ** Method dispatch caching
  24
  25   - Can we make the cache per caller funobj? This should be possible
  26     if we add one cache slot to each (caller) funobj. In many cases
  27     this would allow for a cache-size of 1 or 2, say. And it'd be
  28     possible to determine these cases dynamically.
  29
  30   - It might be feasible to locate some specialization-tables directly
  31     in the instance structure. For example eql-specialized methods.
  32
  33
  34 ** Function calls via symbols
  35
  36   - It's a CPU-cache utilization problem that whenever a function is
  37     called via a symbol, the entire symbol is likely to be loaded into
  38     the cache (cache-lines are 32 bytes or more), whereas only the
  39     function-value cell is likely to be used. If symbols are assigned
  40     a small structure, like a cons cell, for holding their
  41     function-value, then funcalls can go via this cell rather than the
  42     symbol. If suchs cells are located cleverly wrt. CPU caching, a
  43     substantial improvement in cache performance might be feasible.
  44
  45   - The above idea can be taken one step further. Observe that a cons
  46     cell such as described above will represent a mapping from a
  47     symbol S to a function F. Now, we can represent this same mapping
  48     by a funobj FS which is a copy of the funobj F, and with the same
  49     code-vectors. This way, the entire indirect reference to get a
  50     symbol's function-value can be eliminated in the normal case. The
  51     cost is the space overhead of the funobj copies, and a somewhat
  52     more complicated (setf symbol-function). I.e. it would have to
  53     install in the old FS a code-vector that updates the caller
  54     function's references to the new FS, before trampolining to the
  55     new FS. The performance gain could be substantial.
  56
  57
  58 ** Caching strategies
  59
  60   - Might e.g. write-combining or other relaxed memory coherence
  61     models be used, e.g. within one "thread" area?