On Oct 2, 2009, at 1:42 PM, Andreas Rottmann wrote:
The only little problem that I see is that making many BLAS vectors
quickly could potentially run out of memory before the GC triggers.
(because a BLAS vector of N bytes will only use fixed few bytes of
Scheme data, and it will take lots of these to cause a GC) I don't
have a clean solution to this problem. Any ideas?
Guile approaches this problem by having API that allows informing
the GC
about potentially collectable memory, see
scm_gc_register_collectable_memory() and
scm_gc_unregister_collectable_memory() in the manual[0].
[0]
http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Memory-Blocks.html#Memory-Blocks
I don't see how this solves the same problem (it appears that this
actually solves the problem that you already solved by using a
guardian and a gc hook).
A hack around the problem above is to create a bytevector of size
N every time you malloc a BLAS vector of size N, and that ensures
that the GC will trigger at the same frequency as before; but this
is not clean since it's adding needless garbage. All the other
pages that I've read so far seem to be variants of the same hack
(I mean technique).
Aziz,,,
