ke 19. toukok. 2021 klo 18.03 'Sam Clegg' via emscripten-discuss ([email protected]) kirjoitti: > > Jukka, I wonder what you think about making `-Wl,-stack-first` the default > for non-optimizing builds? This will allow stack overflow to instantly > wrap/trap rather than corrupting static data first. It does mean the opt > builds will have a different memory layout, but this doesn't seem > particularly different to all the other things that are already different > with opt builds. Floh too, any thoughts on that?
In non-optimized builds, those are not the tradeoffs: the difference is not to trap vs corrupt static data, but to trap vs give a stack overflow error, since we do have stack checks? (have had for a long time, in two different performance modes even?) Nevertheless, that would be fine for non-optimized builds. I do think having the global data first is useful for code size for optimized builds. Pthreads and PROXY_TO_PTHREAD won't be able to benefit from this, but it would give some added guard at least. > > On Wed, May 19, 2021 at 4:18 AM Jukka Jylänki <[email protected]> wrote: >> >> +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. > > -- > 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/CAL_va29xhZYBDKbV__4u%2Bi%2BRfte7kMZuy-n%2BNX6AKCQynTx8cA%40mail.gmail.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-1Dqr8a5RFDhiSMNWzApVrmDgYxCQb5VEdcKz5rzE_-5g%40mail.gmail.com.
