Thanks, Sam. That’s correct, the vast majority of my work has been with Embind. I want to understand when and how I am crossing the WASM boundary, and whether that even matters in practice. If I am iterating over an array that exists in JavaScript memory, cache locality still applies, and as long as the array is contiguous, it seems, naively, that it should not matter much whether the memory lives on the WASM heap or the JavaScript side.
What I do not understand is the access cost. How many function calls are involved, and are we likely to thrash the cache in the process? I honestly do not know. I do not expect anyone in the group to answer this in detail, but I anticipate using Emscripten far more often in the coming years, and these are things I will need to understand. I have looked at wire.h and tried stepping through some of the relevant functions. Learning this way, by reading source code, is always difficult, especially when heavy template logic is involved. I was really hoping for a Udemy course or something similar, but everything I have found so far is very surface level. A conference talk would work just as well. Anything where someone explains the concepts directly would be far more effective than me fumbling my way through source code :P On Monday, December 8, 2025 at 4:57:19 PM UTC-5 [email protected] wrote: > Your question seems to be specific to embind, which is specific optional > part of emscripten. > > While not an answer to your specific question perhaps searching asking > about embind specifically might yield better results in search engines etc. > > Ultimately, if you really want to understand how embind works you going to > want to dig deep in the `wire.h` and `bind.h` headers and the libembind.js > JS code: > https://github.com/emscripten-core/emscripten/blob/main/src/lib/libembind.js. > > Beware, there is heavy use of C++ template magic in there! > > cheers, > sam > > On Mon, Dec 8, 2025 at 12:20 PM chris goyette <[email protected]> > wrote: > >> I’ve been through the official API and documentation for Emscripten, but >> they don’t cover the things I’m really curious about. >> >> What I’m looking for are lower-level resources: explanations of how the >> memory model works, what’s actually happening when crossing the WASM/JS >> boundary, and how memory lifetimes are handled. >> >> For example, it’s still unclear to me exactly *when* the JS barrier is >> crossed or what guarantees exist around memory in cases like this: >> emscripten::val Float64Array = emscripten::val::global("Float64Array"); >> const double* src = reinterpret_cast<const >> double*>(someVectorOfDoubles.data()); >> emscripten::val view(emscripten::typed_memory_view(numDoubles, src)); >> jsArr.call<void>("set", view) >> >> If you’ve found blog posts, talks, deep dives, or even good discussions >> on this topic, I’d really appreciate any pointers. >> >> -- >> 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 visit >> https://groups.google.com/d/msgid/emscripten-discuss/45234e7e-43ad-4efd-b74d-17665a1e3cb1n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/45234e7e-43ad-4efd-b74d-17665a1e3cb1n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 visit https://groups.google.com/d/msgid/emscripten-discuss/f2da182f-9417-4458-ac70-f7efe3a650a1n%40googlegroups.com.
