Re: Threads and asyncs

[Tom Lord <lord@regexps.com>]

      > The problem with this is that it requires really fast garbage collection.

Again -- I'll point at the substantial (from vague recollection: 20%?)
speedup SCM got from generationally collecting environments.  The 
common case pattern of how environments are used makes this a really
excellent choice.

There's also Stallman's ancient spaghetti-stack approach -- which is
kinda close to what SCM is doing.

You can view Guile's use of the C stack for eval as a way to trick the
C compiler into doing most of the most-common-case of
spaghetti-stacks.   Then you can ask: is bending over backwards for
that trick *really* worth it?   Screw-it: compilers for C-like
languages *aren't that hard* (in spite of the cultural machismo of the
GCC group).



      > Guile's commitment to conservative collection can present a serious
      > problem in this regard.   

As with calling conventions, I think there is room for a two-level
approach.   Precise GC in the core -- conservative GC for
"non-primitive foreign functions".   In the very long term we can
talk the rest of the world into using some language other than C: in
which case the entire issue may very well simply disappear.

I'm not sure (aside from 1-3 year political reasons) why such care for
C should be so important.  For example, 5 years ago or so, I wrote a
low-level buffer implementation and redisplay algorithm in Guile with
the result being smaller, simpler, more general code, compilable by
hobbit to produce acceptable performance on hardware that was (already
by that time) a bit behind the curve (thank Cygnus-cum-Red-Hat for its
non-release/stalled development).  There is no performance critical
code in Emacs (for example) that couldn't be usefully rewritten in
Scheme.

And, again, I'm talking a little bit pie-in-the-sky.  Should Guile
never undertake to change its core away from (for example)
conservative GC, if it converges on a nice API, then it is simply an
implementation optimized for that particular API.  #f/() is the only
irreconcilable issue I know of in this regard.  (Please, tb, spare us
a rehearsal of jimb's design -- we all either agree with me, know i'm
wrong, or already know the arguments.  Ok, now, please say something
argumentive *anyway*.)

In Emacs-of-the-future, where the "market" for extensions heats up
quite a bit, I think conservative, incremental GC is essential to
robust operation.


       > Now that I think about it [...]

you lost me with the rest of that, in case you want to clarify.


       > Is all the thread hair in SCM as well?

Grr.  We need a wiki to sort that out.  No, I don't (recall that) it's
in SCM -- but then I also think Guile is dead-ending in this regard.

It's freekin hard.   I tend to think of implementations in terms of
some data structures in the heap.   You want those to be really fast.
Any kind of global locking makes them horribly slow.   So, threads
_suck_ for Scheme.

But then on the other hand, it makes sense to put multiple CPUs on a
bus, sharing memory.   So, what is the right abstraction to take
advantage of that?   I keep coming back to the idea that, for multiple
Scheme threads, each thread gets its own separate universe -- no `eq?'
sharing at all.  

But I want a wiki -- it's just intuitive speculation, at this point --
and the issues are large enough that one can easily wind up going in
circles out of shear confusion.




	>> One language implementor I met made a big fuss over amdhal's law --
	>> which has the implication for Guile that cleaning up various apis
	>> (internal and external) should be a big priority.

        > Ok, I give up, how do the two relate exactly?


Am I misunderstanding the referent of "the two"?   amdhal's law talks
about the impact of optimizing components on the performance of a
system that incorporates those components.   Clean APIs can enable
swappable components.

If the FFI/GC-interface don't overdetermine the implementation of
eval, gc, etc....then there's room to change strategies.

If the interfaces are _too_ general, then you can swap components, but
you can never implement the good ones in a reasonable way.

-t



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel