Hi Andreas, > I don't understand yet though how you would like to integrate a compiled module cache for wasm. What kind of JavaScript code would a user write to access the cache? Would the user just write normal JavaScript code with `new WebAssembly.Module()` and `WebAssembly.compile()`, and we should do a cache lookup in that case? Or would there be explicit commands in the JavaScript code for serialization and deserialization?
While having implicit caching in `WebAssembly.compile()` would be super cool, it is probably not feasible, is it? What should the cache key be? A crypto digest would work, but that's slow. A non-crypto quality hash function would have security implications. Using the whole module as a key would require a database. The next best option is exposing serialisation and deserialisation, so that Node.js could implement a cache-enabled custom API, e.g. loadFromFileAndCompile(path). It would be nice if it was possible to disable Liftoff for a particular Module. Use case: a utility that's not supposed to run long enough, Turbofan burns CPU cycles but never completes. Also: AOT compilation. On Tuesday, 5 January 2021 at 17:14:21 UTC+3 ah...@google.com wrote: > Hi Nick, > > I agree with Clemens that this is definitely an API that we can add to > support your use case, and we don't have it yet because we don't have a > user for it yet. > > I don't understand yet though how you would like to integrate a compiled > module cache for wasm. What kind of JavaScript code would a user write to > access the cache? Would the user just write normal JavaScript code with > `new WebAssembly.Module()` and `WebAssembly.compile()`, and we should do a > cache lookup in that case? Or would there be explicit commands in the > JavaScript code for serialization and deserialization? > > As soon as we understand the use case, we can also work on an API to > support it. > > Cheers, Andreas > > On Tue, Jan 5, 2021 at 1:12 PM Clemens Backes <clem...@chromium.org> > wrote: > >> Yes, compileStreaming is the only API that supports deserialization, >> currently. But it sounds like you are not really doing streaming >> compilation, you just want to implement similar functionality for >> synchronous compilation. In that case, I would propose to extend the V8 API >> to support your use case, instead of using an existing but >> not-quite-fitting API. >> >> Maybe you just need to add two new methods: >> CompiledWasmModule::AddTopTierCompiledCallback and (static) >> CompiledWasmModule::Deserialize. >> Let me know if you need help adding those to V8. I could send you a patch >> for prototyping locally, to figure out if this approach works well for >> Node.js. >> >> On Tue, Jan 5, 2021 at 12:42 PM Nick Zavaritsky <mej...@gmail.com> wrote: >> >>> Hi Clemens, >>> >>> Thank you for the reply. I am reading your response as a confirmation >>> that indeed there is currently no other way to deserialise a WASM module >>> apart from using compileStreaming. >>> >>> I dunno if reviving the API you are referring to is enough. We need to >>> find out if the top-tier compiler has completed before serialising, don't >>> we? >>> >>> CompileStreaming handles that. It would be nice if it was possible to >>> invoke it giving a streaming callback as an argument via a C++ API. >>> >>> On Tuesday, 5 January 2021 at 14:01:08 UTC+3 Clemens Backes wrote: >>> >>>> V8 used to have an API to directly create a Wasm module from serialized >>>> bytes. It was removed in https://crrev.com/c/2033171. We could bring >>>> it back if there is use for it (it would need some tests then, which were >>>> missing before). >>>> >>>> On Thu, Dec 31, 2020 at 11:32 AM Nick Zavaritsky <mej...@gmail.com> >>>> wrote: >>>> >>>>> Forgot to mention that implementing a >>>>> standards-conforming WebAssembly.compileStreaming in Node.js is probably >>>>> not an option. There's no Request in Node.js to start with. The feature >>>>> is >>>>> covering local files only. Hence the proposal introduces a cache-enabled >>>>> loader as a custom api (e.g. require("wasm/cache").loadFile(path) ). >>>>> >>>>> The problem is that there's a single global WasmStreaming callback. >>>>> Hijacking it makes future implementation of the proper >>>>> WebAssembly.compileStreaming unnecessary cumbersome (if it comes to be). >>>>> Even though Node.js itself probably isn't going to need it in foreseeable >>>>> future, Node is often embedded in larger projects (e.g. Electron). >>>>> Barring >>>>> them from having this opportunity makes Node.js maintainers unhappy. >>>>> >>>>> Best, >>>>> N >>>>> >>>>> On Thursday, 31 December 2020 at 13:13:44 UTC+3 Nick Zavaritsky wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> There's currently no compiled module cache for WASM modules in >>>>>> Node.js. I've started an effort to make one ( >>>>>> https://github.com/nodejs/node/issues/36671). There's a POC already. >>>>>> >>>>>> The POC hijacks WebAssembly.compileStreaming. It uses >>>>>> v8::WasmStreaming::SetCompiledModuleBytes to deserialise a cached >>>>>> module. >>>>>> Please let me know if there's a cleaner approach. >>>>>> >>>>>> Best, >>>>>> N >>>>>> >>>>> -- >>>>> -- >>>>> v8-dev mailing list >>>>> v8-...@googlegroups.com >>>>> http://groups.google.com/group/v8-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "v8-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to v8-dev+un...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/v8-dev/9c27c1ec-61c7-486c-abb5-138a2d7feac4n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/v8-dev/9c27c1ec-61c7-486c-abb5-138a2d7feac4n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> >>>> Clemens Backes >>>> >>>> Software Engineer >>>> >>>> clem...@google.com >>>> >>>> Google Germany GmbH >>>> >>>> Erika-Mann-Straße 33 >>>> >>>> 80636 München >>>> >>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>> >>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>> >>>> Sitz der Gesellschaft: Hamburg >>>> >>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise >>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>> bitte >>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>> >>>> >>>> This e-mail is confidential. If you received this communication by >>>> mistake, please don't forward it to anyone else, please erase all copies >>>> and attachments, and please let me know that it has gone to the wrong >>>> person. >>>> >>>> -- >>> -- >>> v8-dev mailing list >>> v8-...@googlegroups.com >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-dev+un...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/5a2a2777-a5a5-436e-a20c-1aa7e2503376n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/5a2a2777-a5a5-436e-a20c-1aa7e2503376n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> Clemens Backes >> >> Software Engineer >> >> clem...@google.com >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> >> -- >> -- >> v8-dev mailing list >> v8-...@googlegroups.com >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-dev+un...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/CAGO%3DqhDAK8dokJ%3DQvdBLWkuAQv864iqr1gHXyKoqe6v6AE%3Dcrg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/v8-dev/CAGO%3DqhDAK8dokJ%3DQvdBLWkuAQv864iqr1gHXyKoqe6v6AE%3Dcrg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Andreas Haas > > Software Engineer > > ah...@google.com > > > Google Germany GmbH > > Erika-Mann-Straße 33 > > 80636 München > > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > > Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/6f405501-d906-4244-b418-80e12749966en%40googlegroups.com.
