Alex Crichton (Mar 09 2021 at 15:59): Alex Crichton (Mar 09 2021 at 15:59):@Yury Delendik I was reading over your patch this morning, overall I think it's roughly in the right direction but I think we'll ideally want to structure things differently
Alex Crichton (Mar 09 2021 at 16:00):I think one of the first things we'll want to land is the ability to build the wasmtime crate without the cranelift jit, that's a refactoring which is needed no matter what the AOT world shapes up to be
Alex Crichton (Mar 09 2021 at 16:00):I'm imagining that in the wasmtime-without-cranelift world we wouldn't give you Module::new (and friends) and you would only have Module::deserialize to create a module you could then instantiate.
Alex Crichton (Mar 09 2021 at 16:01):I think next what might be good is to change your PR to add a new API like Module::from_wasm2obj (or sometehing like that) where it takes a *const u8 which is the metadata symbol created by wasm2obj for now.
Alex Crichton (Mar 09 2021 at 16:02):Basically that would be a different way of saying "here's a precompiled object, give me the module"
Alex Crichton (Mar 09 2021 at 16:02):that should vastly simplify integration work and everything else because at that point it's just "use the wasmtime crate"
Alex Crichton (Mar 09 2021 at 16:03):if you want to make an issue that's ok, but I'm not sure that it's necessarily required here
Yury Delendik (Mar 09 2021 at 16:04):I can create issue a meta issue that outlines the patch action items
Alex Crichton (Mar 09 2021 at 16:04):refactoring to be able to compile without cranelift is mostly just a given, and then something like Module::from_wasm2obj could ideally be maintained as a pretty small patch for now while we figure out what best for rfcs and such
Alex Crichton (Mar 09 2021 at 16:04):The peformance numbers y'all get will I think heavily influence what the action items are
Alex Crichton (Mar 09 2021 at 16:05):I think that's the main next step because we'll need feedback for what performance aspects are required
Alex Crichton (Mar 09 2021 at 16:05):e.g. static calls and such if necessary
Alex Crichton (Mar 09 2021 at 16:06):If you can use the wasmtime-crate roughly as-is today and are happy with the performance that's naturally the ideal (maybe a patch or two of course), but something where you want static calls to static symbols for either imports or exports (or both) will significantly change the design I think
Yury Delendik (Mar 09 2021 at 16:06):I did not see performance numbers, but I assume they are connected with heavy use of function wrappers and trampolines
Alex Crichton (Mar 09 2021 at 16:06):right yeah, I just want to make sure we're looking at concrete numbers and we're in a position where literally everything is optimal except for the static vs indirect function call
Alex Crichton (Mar 09 2021 at 16:08):also though, another possible work item, it seems reasonable to make Module::serialize basically the exact output of wasm2obj perhaps
Alex Crichton (Mar 09 2021 at 16:08):(or at least more similar than it is today)
Yury Delendik (Mar 09 2021 at 16:08):the risk is creating valid native object files
Alex Crichton (Mar 09 2021 at 16:09):there's some trickery involved yeah where the formats are slightly different but I think that's ok
Yury Delendik (Mar 09 2021 at 16:09):for now, Module::serialize uses okay format
Alex Crichton (Mar 09 2021 at 16:09):like for wasm2obj we'll need to implement most of that anyway
Alex Crichton (Mar 09 2021 at 16:10):I'm basically trying to see if there's stuff to land immediately which is just internal refactorings/etc which makes the final patch to land this feature smaller
Alex Crichton (Mar 09 2021 at 16:10):along the lines of "wasmtime should have a build mode without cranelift"
Alex Crichton (Mar 09 2021 at 16:10):there's no need to delay that work until this feature lands
Yury Delendik (Mar 09 2021 at 16:12):I agree. I'll try to extract that piece from WIP
Shravan Narayan (Mar 09 2021 at 20:14):@Alex Crichton a quick question about "building wasmtime without the cranelift jit" --- Still a bit confused by this. Could you clarify if this is referring to a step that occurs when I run cargo build in the wasmtime git repo or something to do with instantiating a wasm instance during runtime?
Shravan Narayan (Mar 09 2021 at 20:17):If it helps, I think the former is largely not a blocker for a v1. The latter would be important to address :+1:
Yury Delendik (Mar 09 2021 at 20:26):There is a great deal of coupling between environment, runtime, and, JIT, also, cranelift. this step will allow to clarify the boundary between runtime and JIT/cranelift
Alex Crichton (Mar 09 2021 at 21:01):@Shravan Narayan ah this is largely about the internal organization of wasmtime itself, this wouldn't be a blocker for gaming anything out or taking a look at numbers. I'm assuming though that the final embedding within rlbox would ideally not like to pull in cranelift at runtime, and this is what would enable that
Shravan Narayan (Mar 09 2021 at 21:30):I think that makes sense. Ideally yes, we would like to be able to exclude that. I'll go further and say this shouldn't block shipping a v1 of RLBox+wasmtime to Firefox's pre-release channels as well since Firefox would already ship the cranelift package for wasm's web use case. So the memory footprint of the cranelift package is already present
Alex Crichton (Mar 09 2021 at 21:36):ah ok, then I think the next step is to look at benchmark numbers and see what needs to be optimized yet. In parallel perhaps we could add something like Module::from_wasm2obj which does everything internally to handle the precompilation part, but this shouldn't affect much of the performance measurement
Bobby Holley (Mar 10 2021 at 19:06):To clarify, I don't believe we are currently shipping runtime cranelift to most of our users
Shravan Narayan (Mar 10 2021 at 21:29):@Bobby Holley oh sorry. I thought I saw cranelift was in the src tree already, but perhaps it doesn't get included in the actual build which gets shipped. From a shipping standpoint, are we safe to assume the memory footprint of a few additional MB of unused code (cranelift-jit) wouldn't be a blocker for us.
Till Schneidereit (Mar 10 2021 at 22:03):From a shipping standpoint, are we safe to assume the memory footprint of a few additional MB of unused code (cranelift-jit) wouldn't be a blocker for us.
Having been part of the multi-year discussions about shipping the JS Intl API and the associated multiple MBs of locale data, I'm pretty sure that the answer will be "no".
I also would hope that it wouldn't be too hard to create a build config that doesn't include the JIT, but obviously others might know better. At the very least this should be perfectly parallelizable with a lot of the other work, and not preclude experimentation
Last updated: Dec 23 2024 at 13:07 UTC