Re: gc-phobia

[Michele Bini]

>>>>> "Thomas" == Thomas Bushnell, BSG <address@hidden> writes:
  
[...]

  Thomas> It's actually better to wait for gc than try to keep track
  Thomas> yourself.  Plus, the whole point of gc is to guarantee that
  Thomas> memory references are always good; if you go around freeing
  Thomas> cons cells, then you are breaking that promise.

  Thomas> Playing around with the free list is Strictly Forbidden.
  Thomas> Don't do it.

Okay, i trust you on this. ^^

While the inability to explicitly free a cons cell is irrelevant, as
you could eventually adapt your algorithm to reuse it, this seems not
to be possible with boxed data types, like floating point numbers.
(hmm, maybe i am missing something here).  During heavy numerical
processing a considerable amount of time may be spent gc'ing
expecially when the heap is large (not to mention when part of it lies
in a swap area).

It may perhaps sound heretical, but beyond having flonum- functions
(like MIT Scheme has) we could also have their destructive
counterparts, like abs!, floor!, *!, /! =)
For instance, a closure compiler could safely rewrite:
(< (+ (* a a) (* b b)) (+ (* c c) (* d d)))
into (< (+! (* a a) (* b b)) ...
or (let loop ((a 3.0)) (loop (* a 1.618)))
into (let loop ((a 3.0)) (loop (*! a 1.618)))
(and the latter example could run without waking up the gc).

  >> Implementation-wise, some changes i'd propose are: * to
  >> specialize the scm_call_* and scm_apply_* functions, which
  >> currently just build lists for the arguments and pass them to
  >> scm_apply.

  Thomas> This might be a reasonable optimization, but you haven't
  Thomas> said enough to say just what you have in mind.

My idea was to specialize the scm_call_0, scm_call_1 and such
functions in eval.c.
For instance if a closure is found to be a primitive function with a
prototype like SCM foo(SCM, SCM, SCM), scm_call_3 could detect it and
pass its arguments directly to it without any consing, while if a
another closure takes a 'rest' argument after other two arguments,
scm_call_4 would just have to call cons one or two times to form that
rest argument.
Probably adaptations in scm_ceval to make use of the specialized
functions would be required, also.

  >> * create C functions to free pairs and other boxed data
  >> explicitly, and eventually even create a scheme callable
  >> interface for them (this could be beneficial to number processing
  >> applications, when dealing with fixed matrices, complex or
  >> floating point numbers.

  Thomas> This is seriously misguided.  Bad enough to allow C to break
  Thomas> the gc abstraction, but advocating Scheme doing so?  No,
  Thomas> that's just a mistake on ten grounds.  It results in slower
  Thomas> programs with more bugs.

(BTW, i am just not authoritative enough to advocate anything, :) i am
actually trying to figure out the viability of different approaches)
This was actually meant to be used only in performance critical
code sections, but now i see that you can just reuse allocated objects
by employing destructive functions instead, if you really want to.

  >> * reimplement some function that apply a variable number of
  >> arguments to other functions, (like call-with-values, map,
  >> for-each), and specialize the case in which the closure to be
  >> called takes a fixed number of arguments.

  Thomas> Again, this is a reasonable optimization strategy.  (It's
  Thomas> not particularly related to GC.)  I'm sure work on this
  Thomas> would be appreciated.

Thank you.  About call-with-values, i am not sure that this can be
implemented anymore, since you cannot detect, except in trivial
cases, to what consumer the return value of 'values' is going to
get applied.  Making map and for-each call the specialized scm_call_*
functions should not pose particular problems, though.  I will try to
integrate these changes as i get more acquainted with the evaluator
internals (and the various closure types).

                                Michele