Thanks for your reply,
On Friday, February 13, 2015 at 6:21:48 PM UTC+1, jj wrote:
>
> The numbers for the available stack size that you print out look very odd
> to me. At recursion level 4, it is stating that it has 17300 bytes(?) of
> stack space left.
>
Not bytes. Recursion levels until "Maximum call stack size exceeded" for a
trivial javascript function. I posted the code, here is it again:
EM_ASM_({
var i = 0;
function stackExplorer() { i++; stackExplorer(); }
try { stackExplorer(); } catch (e) { console.log("--> recursion level: " +
$0 + ", free stack: " + i); }
}, recursion_counter);
Each recursion level of stackExplorer() increases the variable i until the
call stack is exceeded and a "Maximum call stack size exceeded" exception
is thrown. This exception is caught and "i" is printed. I don't know of any
method to measure the available or used size on the stack in bytes. But I
can do it this way.
I have added another call like that to my main function:
--> main, free stack: 20946
--> recursion level: 1, free stack: 18221
--> recursion level: 2, free stack: 16463
--> recursion level: 3, free stack: 14700
--> recursion level: 3, free stack: 14700
--> recursion level: 2, free stack: 16463
--> recursion level: 3, free stack: 14700
....
--> recursion level: 8, free stack: 5876
--> recursion level: 9, free stack: 4112
--> recursion level: 9, free stack: 4112
--> recursion level: 8, free stack: 5876
--> recursion level: 9, free stack: 4112
--> recursion level: 10, free stack: 2347
--> recursion level: 11, free stack: 583
/home/clifford/Work/handicraft/2014/verilearn/yosys/yosys.js:84
throw ex;
^
RangeError: Maximum call stack size exceeded
So all the stuff in the stack trace I posted above the first call to
AstNode::simplify() takes up as much space on the call stack as 2725
recursions of stackExplorer(); lets call it Stack Explorer Units (SEU). I
count 13 C functions in the JavaScript stack trace I posted. So that's 209
SEU avg. per C function. This is already interestingly high. But
for AstNode::simplify() I get 1765 SEU and thus my stack of initially 20946
SEU is exhausted after only a few recursions.
> Assuming that you have not changed the default Emscripten stack size
> during compilation, which is 5MB (see here:
> https://github.com/kripken/emscripten/blob/master/src/settings.js#L54
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fkripken%2Femscripten%2Fblob%2Fmaster%2Fsrc%2Fsettings.js%23L54&sa=D&sntz=1&usg=AFQjCNGmHlJXNBJ10_JHbPpDogNPtDhA9Q>
>
> ),
>
Changing this parameter has no effect. (I have tried that already and now I
have tried again just to be sure.)
In my understanding this is the size of the data stack. But I am running
out of space on the call stack of the JavaScript virtual machine. (I would
not know how emscripten could have a parameter for that. To the best of my
knowledge there is no interface to manipulate the VM call stack size from
JavaScript..)
void foo()
> {
> int localTempArray[1024*1024]; // Consumes 4MB of stack space.
> // ...
> }
>
But this consumes 4MB on the _data_ stack. For example:
#include <emscripten.h>
void test(int i, char *p)
{
EM_ASM_({
var i = 0;
function stackExplorer() { i++; stackExplorer(); }
try { stackExplorer(); } catch (e) { console.log("--> recursion level: " +
$0 + ", free stack: " + i); }
}, i);
char *stuff[256*1024];
stuff[i] = p;
test(i+1, p);
}
int main(int, char **argv)
{
test(1, 0);
return 0;
}
Compile and run:
$ emcc test.cc
$ node a.out.js
--> recursion level: 1, free stack: 20940
--> recursion level: 2, free stack: 20937
--> recursion level: 3, free stack: 20933
--> recursion level: 4, free stack: 20930
/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:84
throw ex;
^
abort() at Error
at jsStackTrace
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:987:13)
at stackTrace
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:1004:22)
at abort
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:8711:25)
at __Z4testiPc [test(int, char*)]
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5085:70)
at __Z4testiPc [test(int, char*)]
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5098:2)
at __Z4testiPc [test(int, char*)]
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5098:2)
at __Z4testiPc [test(int, char*)]
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5098:2)
at __Z4testiPc [test(int, char*)]
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5098:2)
at _main
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:5110:2)
at Object.asm._main
(/home/clifford/Work/handicraft/2014/verilearn/yosys/a.out.js:8491:19)
Notice how this error differs from the error I posted above?
This program runs out of data stack. But on the call stack it has plenty of
space left and only takes 3-4 SEU per recursion. My program runs out of
call stack. But not because of the number of recursion levels but because
of the large number of SEUs that each recursion level costs.
I would like to know how I can reduce the number of SEUs that my function
takes on the call stack (I would assume that on the JavaScript side it has
to do with the number of local variables or something like that) and how
this relates to the C++ code that I feed into emcc, so I know how I have to
refactor my function to make it work.
..or if it turns to be something like the number of local variables, maybe
there is something that emcc can do to automatically encapsulate them and
put them on the heap or something to reduce the SEU of the generated
function. That would be awesome.
Thanks for reading all the way to the end. Help is very appreciated.
regards,
- clifford
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
