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, <rixed@happyleptic.org> 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 :-)
>
>