Ha, yes ...

Also 64K

Oh, and as one random data point, emcc reduced the stack size by a lot a few years back, making this a lot riskier. We did get an uptick in reports, but quite small

(again, not conclusive, jut saying where my intuition here comes from)

Definitely, yeah, most users never report. Most open source users never interact at all with upstream...

Still, while we can't tell the absolute numbers, I hope (but could be wrong!) that the reports we do get, on issue trackers and elsewhere, hint at the relative importance of problems

Yeah, good points. I wish this was simpler. Emcc and Rust etc can do stuff like this in their compiler driver logic, but wasi-sdk alone needs another solution...

I think if stack overflow problems were a major issue, those things would have been a higher priority.

But also, wasi-sdk is mostly used off the web, where code size matters less, so again I agree with you on the new default, and maybe most wasi-sdk users just don't need anything else, yeah

True that while the Binaryen pass can run on wasi-sdk output, it lacks docs, yeah.

But porting sanitizers would not be too hard, I think. Can base off of Emscripten's, and replace/remove the stack trace logic.

I didn't mean to equate those, no.

(But I do sort of collect data for both, in that I follow both issue trackers and listen to users of both elsewhere as well.)

Given those tools, my sense from user reports is that weird stack-related crashes are not a significant problem

And there are users that do care about every percent of binary size on the web

(though, again, I agree with you on the right defaults here)

Fair enough, though I'd say there are good mitigations for those crashes:

1. Stack overflow checks can be added in production: github.com/WebAssembly/...

2. During development there are also sanitizers: emscripten.org/docs/debuggi...

This might be the right default, but it does have a size downside?

If you don't compress LEBs then I guess not, but if you do, it can be significant: some codebases have lots and lots of references to global data, and making those e.g. 3 bytes instead of 2 can add up.

Sounds like that was "fun", heh...

I did get lucky here... after getting those huge files, validation checks pointed to the breaking one, and then wasm-reduce quickly found a small testcase. The fix was simple:

github.com/WebAssembly/...

good thing storage is measured in TB these days

"what if it doesn't continue to get better?" is actually something I am certain is false.

It might approach a limit in theory, but to literally stop, when computers keep getting faster? Almost all cognitive tasks benefit from more resources, more attempts, more effort.

+

"Intelligence doesn’t come as a quantity you can just ratchet up and up. Smart people may be brilliant in one area and not in others. Some Nobel Prize winners are really bad at playing the piano or caring for their kids."

Not a *great* rebuttal, ofc

Doesn't it rebut it at the very end?

"But set aside the technical objections—what if it doesn't continue to get better?—and you’re left with the claim that intelligence is a commodity you can get more of if you have the right data or compute or neural network. And it’s not."

+

Interesting, yeah, that makes sense. So it is not a perfect indicator, but might be a good hint sometimes.

...how does it compute "microarchitecture usage", do you know?

(I mean, is it literally how much CPU hardware is used vs idle, or is it comparing vs the theoretical maximum of existing SIMD instructions, etc.?)

Docs for wasm-reduce:

github.com/WebAssembly/...