Hi, I added a patch to suggest a new environment variable.
GUILE_STACK_SIZE_NSCM If this is defined and setted to a reasonable number then this will be the number of SCM (8 byte on a 64bit arch or 4 on a 32 bit arch) to allocate to the VM stack. The naming might not be the best, we might want to name it VM_STACK in stead of stack. anyway here is a patch. I tested it to the example in the beginning of this thread and it seams to work just fine. The intention is for this to be enough to close the bug. /Stefan On Wed, Dec 12, 2012 at 9:33 AM, <[email protected]> wrote: > -[ Tue, Dec 11, 2012 at 11:29:31PM +0100, Stefan Israelsson Tampe ]---- > > Anyway in vm.c I changed the > > #define VM_DEFAULT_STACK_SIZE (64 * 1024) > > > > to > > #define VM_DEFAULT_STACK_SIZE (64 * 1024 * 64) > > > > and recompiled! > > Oh, I hadn't realized you were speaking about the VM's stack. It all makes > sense now. > Any inconvenient to set this stack even bigger ? How many such stacks do we > have in a running environment ? One per thread ? > > > Then I can compile to tree-il. Compiling all the way does not work well, > > But if you enter > > scheme@(guile-user)> (compile program #:to 'value #:opts > '(#:partial-eval? > > #f #:cse? #f)) ;;NO OPTIMIZATION PASSES > > > > It will compile to. > > > > $7 = #<procedure 3708400 (proto server-port client-zone server-zone > > signature-id)> > > Yes, I did this and as a result the compiled function was... 20% faster !? > (note that my bench exclude the compilation time, and uses > get-internal-run-time > as a clock source). > > Thank you very much for all these advices. > As usual, support from free software community is much better than it is > from > any business I've seen :-) > >
stack-size.patch
Description: Binary data
