[CM] Idea: using handles instead of pointers, s7_clone

bil at ccrma.Stanford.EDU bil at ccrma.Stanford.EDU
Fri Sep 23 13:06:10 PDT 2022

To expand a bit on Elijah's note:

I don't think this will reduce cache misses or make objects smaller.
To evaluate anything, you have to access the things being evaluated.
Most of the points in the article you mention do not apply to s7 --
s7 manages its own memory, the cells are already packed tightly, etc.
In your s7_clone example, having two s7's call a function from one
of the s7's is dangerous because you might call s7_free on the source 
I actually don't know if this would work at all currently.

You can't use the s7 heap itself (which seems redundant because
the handle is just a pointer to the s7_pointer into the heap),
because cells can be removed from the heap (to reduce pointless GC 
The article thinks it can save space by using 32-bit handles, but
I have run with 2 billion cells, and if I had a machine with enough 
I could overflow 32-bits.

Newer chips have larger caches -- I've seen 256 MBytes, so
cache misses might be solved by newer hardware.  When I ran
cachegrind, I didn't get the impression that cache misses
were a huge problem -- the bigger cache was about 15-20% faster
in the cases where it mattered at all.  Perhaps you could
run with a smaller heap.

Why do you need s7_clone?  I can call s7_init, load and evaluate
some stuff, then s7_free in about 1/2 millisecond.  Perhaps
you could keep a sort of history in scheme, then evaluate that
in the subsequent s7.  Or get the functions for the clone
from the files loaded in the current s7, and any computed
stuff might be passed via the "readable" object->string

More information about the Cmdist mailing list