+1 for a lower default. 64KB would be fine for me. The rationale for that is that it should be a good practice for developers to be aware that the stack length is fixed during runtime. Assuming we do have good stack checkers enabled by default by now, then we should be very good here.
It is good to note that 64KB wasm stack is not the same as a 64KB native stack, because in wasm, function call stack and non-struct&non-array arguments are not part of the Emscripten-compiled stack. So if one has deep nested calls or recursion, that will not consume the wasm stack. I'd expect that a 64KB Wasm stack will be like a 128KB native stack, though of course varies on the application. Btw, Floh in that code snippet, it would be good to change the 'vertices' and 'indices' arrays to be 'const' so that the compiler will have an easy time to avoid placing them on the stack. That would be excess work if it did, since it would need to memcpy a new memory block copy every time the function is entered (to prepare for changes in the values). Instead, when the compiler knows the values will not be modified, it can retain a single copy of the data in the global data section, avoiding use of the stack. It might do that already if it can reason about the values not being modified, but that probably depends on what the signature of sg_make_buffer() function is. Back in 2019 in https://github.com/emscripten-core/emscripten/pull/10019 I wanted to reduce it to 512KB as the default, but that was a bit objectionable then. Hopefully the issues have been resolved now, I'd love to see a 64KB default stack. It would be nice to be conservative by default, and have developers have to ask to get more, versus by default consuming more, and have developers need to gain awareness in order to optimize to less. The latter leads to suboptimal code being distributed on the web (probably 99% of Emscripten compiled pages out there are running with a 5MB stack), the first leads to developer either being happy with 64KB since most really don't use that much, or crashing once, and then bumping the size (or changing their algorithms to avoid as much of the stack). Imo having devs crash once to educate is better than by-default suboptimal code. Also a middle ground - "let's be a little suboptimal but not by much" feels like it could be a worst of both worlds: it causes excess memory usage on deployed pages still, but still won't probably save devs from crashing once to learn. So super constrained seems like the nicest default to me. ke 19. toukok. 2021 klo 11.27 Floh ([email protected]) kirjoitti: > > My C coding style is a bit stack heavy because it heavily prefers using the > stack instead of heap allocations. > > Example: > > https://github.com/floooh/sokol-samples/blob/b7f8968f6dfd223a80b5ce9f50c40c2b79492403/sapp/cube-sapp.c#L19-L105 > > 1 MB is quite certainly ok (but might be a problem for code with lots of > recursions?), but I think 64 KByte is asking for trouble ;) > > As long as there are clear runtime error messages which indicate stack > overflow I'm fine with any size though, what would suck is random memory > corruption caused by an overflowing stack. > > Cheers, > -Floh. > On Tuesday, 18 May 2021 at 22:21:01 UTC+2 [email protected] wrote: >> >> I have an open PR to reduce the default stack size in emscripten from 5Mb to >> 1Mb, and we are also considering reducing it even furthur (possibly to 64Kb >> which is the wasm-ld default, or to 128Kb, which is the musl default): >> https://github.com/emscripten-core/emscripten/pull/14177. >> >> How many folks out there have run into stack limits with the current limit >> of 5Mb? How many folks are worried they would run into limits if we reduce >> the default to 1Mb, 128Kb or 64Kb? Would those who feel they need more >> stack be OK adding `-sTOTAL_STACK` to their link command to request a higher >> limit? (feel free to respond there, or on the issue above). >> >> cheers, >> sam > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/0ef02392-4a8b-4442-a48c-957570977659n%40googlegroups.com. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-0Pd9WYDd95jnXFEONgfySWYUK5vVOCneTyFOo42c6C_Q%40mail.gmail.com.
