Please test the new EVAL_CTORS
Hi everyone, https://github.com/emscripten-core/emscripten/pull/16011 has landed, which "reboots" the old EVAL_CTOR option. Until now that option has not been useful since we switched to the wasm backend, for several reasons. But all those issues have now been fixed. EVAL_CTORS basically tries to compile code at link time. If you have global constructors that do pure computation, or even parts of main(), then doing that work and then "snapshotting" the results (the state of wasm memory and globals) into the wasm can save time during startup. It may also decrease the wasm size, but it may also increase it depending on how many changes to memory the code does. More concretely, this will try to execute global constructors and main() and it will keep going until it reaches something it can't eval, which is typically a call to an import. To test it, get the latest tip of tree build emsdk install tot and then during link try to add -s EVAL_CTORS Some logging will show up saying what it managed to eval, or where it failed. If it managed to eval at least some things then you can see what effect that has on code size and startup speed for your project. If you try it out, let us know how it goes! - Alon Zakai P.S. See more details in that PR if you're curious. -- 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 emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRcTrORmEQOQKLOT%3DGnPBoZU6KpcBtApsk4wSegVaNF1A%40mail.gmail.com.
Re: Rust journey
On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов wrote: > Let's look closer to my case. I ported C++ game Vangers to the web ( > https://www.gamepix.com/play/vangers). Vangers community did big work to > integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It > works as follow: > 1. Vange-rs provide c ffi interface > 2. Vange-rs compiled with rust to static library > 3. Vangers linked with Vanger-rs to executable > > Now I want to port vangers + (vange-rs render) to the web. wgpu didn't > support wasm32-unknown-emscripten, I added experimental support for > emscripten and it works. BUT, wgpu is developing to fast, so my changes > become outdated very fast :) > > When I implement support for emscripten, I only disabling wasm32-unknown > rules and uses native code paths everywhere. So, it's little bit strange, > to work with emscripten you need to disable workarounds for wasm32. > emscripten emulates native platform, so code that correctly uses posix > system should work also in emscripten. > > Maybe there is any way to just use native static library and link it with > emscripten? Like this: > 1. Compile vange-rs static library (with native triple) > 2. Compile vangers project with emscripten > 3. Link 1+2 with emscripten > > (1) would compile to x86, though, I think? We have to have wasm to link with emscripten. > for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32 > target, they select wrong code path (non-native). > > Hmm, I don't know enough rust to know what fixing that would mean... Overall for an emscripten port I think we would want to use a native build as much as possible? That is, ideally you would *not* use vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to tell rust to use the emscripten triple while doing so. That should work, in theory. If it doesn't and Rust has some issues with how it invokes emcc to link, then the workaround could be what I mentioned for Zig and C before: get Rust to link to a static library, and then run emcc manually on that. (Alternatively, in theory someone could look into supporting wasm-bindgen + emscripten.) - Alon > пт, 14 янв. 2022 г. в 07:54, Alon Zakai : > >> Thanks, good to know at least 2 people would read a post about this :) >> I'll try to find time for it. >> >> About Rust, I haven't had time to look into it yet. My general hope is >> that the same model as for C and Zig could work: >> >> 1. Tell Rust to use the emscripten wasm triple. >> 2. Tell Rust to compile to object files (or a static library, basically), >> and *not* to link them. >> 3. The user runs emcc on those object files, linking them. >> >> The nice thing in this model is that C/Zig/Rust does not need to be aware >> of emcc at all here (aside from telling LLVM to use the emscripten triple). >> And it's easy to do this, at least in C and Zig (although there are some >> subtle ABI questions). >> >> This is actually the main thing I wanted to do before writing the post - >> ideally I'd have a Rust demo alongside C and Zig - so if someone figures >> that out, let me know! >> >> - Alon >> >> >> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов >> wrote: >> >>> +1 for blog post. Not clear how I can use it with rust, e.g. can I >>> compile static lib with target --wasm32-unknown-unknown and then link using >>> emscripten? The main problem with RUST is that it even can't compile with >>> --wasm32-unknown-emscipten (because of lib dependencies that not support >>> emscripten) >>> >>> чт, 13 янв. 2022 г. в 16:46, Floh : >>> That's a very useful gist, Alon! I think that blog post would be much appreciated by a lot of people who like to tinker with other languages :) On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote: > On Sat, Dec 25, 2021 at 6:02 AM Floh wrote: > >> Ah, language and toolchain interoperability, one of my favourite >> topics ;) >> >> Zig has nearly the same problems as Rust: it allows to compile to >> WASM, it has both a WASI and Emscripten target, with the WASI target >> working out of the box, but I gave up on the Emscripten target because I >> just couldn't get it to work. >> > > I wrote up a demo of Zig + Emscripten here: > > https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3 > > That uses GLES3 and Asyncify from Emscripten, so it's a small program > but it uses interesting features. > > The gist also shows using C in the same way, where Emscripten is just > the linker, not the frontend. > > I've been meaning to do the same with Rust and write a blogpost about > all 3 but haven't found the time... > > - Alon > > > >> >> IMHO it would be great if the Javascript shims and interop could be >> somehow split out of the Emscripten SDK into a separate, smaller
Re: typescripten: Type-safe JavaScript interop with complex types
That sounds great!
- Alon
On Sat, Jan 15, 2022 at 1:03 AM Sebastian Theophil
wrote:
>
> Am 12.01.2022 um 19:06 schrieb Alon Zakai :
>
>
> I just have some general thoughts at this point. Curious to hear your
> ideas and other people's.
>
> Maybe a nice starting point would be to make it easier for people to
> experiment with typescripten, to get feedback. Could we add minimal
> integration on the emscripten side to allow that, just a new option perhaps
> (marked experimental), and that uses a module from npm? (Or does this need
> more things than can be packaged in npm?)
>
>
> Sounds good to me. More practical experience is certainly needed most at
> this point. I could package typescripten for npm. Practically all
> TypeScript interface files are on npm as well. Maybe it would be convenient
> to have a command line argument to specify which type definitions to pull.
>
>
> A thought I had is whether we could eventually replace embind with
> typescripten (or at least the part of embind that supports calls from C++
> to JS). That is, if the core "JS object" class in typescripten had the same
> API as embind vals do (for accessing things in a *non*-type-safe way, using
> strings). Do you think that could work? If we could replace parts of embind
> it would strengthen the case for upstreaming, I think.
>
>
> I could try that out. I think it should work. The base js object already
> aggregates emscripten::val anyway.
>
> I hope to have some time in the coming weeks to work on typescripten and
> will hopefully send a PR on GitHub.
>
> Regards
> Sebastian
>
>
> - Alon
>
>
> On Fri, Jan 7, 2022 at 6:01 AM Sebastian Theophil
> wrote:
>
>> Hi Alon,
>>
>> thank you very much and it's great to hear that you find this
>> interesting. I would be very interested in integrating this with emscripten
>> of course. How should we start this process? There are probably a few
>> things that still need to be implemented for a good MVP, so to speak.
>>
>> Regards
>> Sebastian
>>
>> Am Do., 6. Jan. 2022 um 21:59 Uhr schrieb Alon Zakai > >:
>>
>>> Hi Sebastian,
>>>
>>> This is really nice! I watched your talk as well at CppCon (
>>> https://www.youtube.com/watch?v=CLuhogat6aY), very interesting.
>>>
>>> For a while it's seemed like we need something in this general area, so
>>> it's great to see it happen! I think this is a very good design, too (the
>>> performance issue with strings is the one concern I have, but as you say in
>>> the talk, that can be optimized - I'd use EM_JS for that probably).
>>>
>>> Did you have ideas about integrating this with upstream Emscripten? I
>>> think that might make sense to do, although maybe as part of a larger
>>> conversation on our bindings story (atm we have embind and the WebIDL
>>> binder, which already have some overlap).
>>>
>>> - Alon Zakai
>>>
>>> On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil
>>> wrote:
>>>
Hi,
I wanted to plug my own project for some time here on the mailing list
because it also handles JavaScript - C++ interop and now wajic came up so I
thought I pitch in.
My project https://github.com/think-cell/typescripten produces
type-safe C++ interfaces to JavaScript standard libraries or third-party
libraries. It reads TypeScript interface definition files and transforms
them into C++ shims based on emscripten.
The resulting C++ code is often a straight-forward port from
TypeScript/JavaScript, e.g.,
JavaScript:
var elem = document.createElement("p")
elem.innerText = "Hello CppCon 2021"
elem.style.fontSize = "20.0"
document.body.appendChild(elem)
C++:
auto elem = js::document()->createElement(js::string("p"));
elem->innerText(js::string("Hello CppCon 2021"));
elem->style()->fontSize(js::string("20vh"));
js::document()->body()->appendChild(elem);
No macros and the C++ functions return typed JavaScript objects!
Because we use the TypeScript interface definitions, the C++ code is
typechecked. Passing a number to fontSize will create a compiler error.
The project is not yet meaningfully complete but it bootstraps
successfully, i.e., the compiler understands the interface definition file
for the TypeScript compiler and parser API that it uses itself. TypeScript
generic constraints are not yet supported, for example, but should be.
Maybe somebody else finds this useful. We have used it internally for a
small web app already that needed to call the tableau.com JavaScript
API.
Regards
Sebastian
--
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 emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
