Closed tshort closed 1 year ago
Cool!
Is this the most promising way of compiling for WASM right now? (As opposed to seemingly abandoned https://github.com/Keno/julia-wasm)
I am wondering what kind of error you had without this option ( remove address spaces) ? I am asking because I did not use any special flag myself. Maybe you are able then to use julia 64-bit for compilation?
I am curious to see the Lorenz System using Julia/WASM :-)
@Alexander-Barth, your conversion to WebAssembly didn't give an error because it uses GPUCompiler's default optimization pipeline. That removes address spaces here. StaticCompiler uses an optimization pipeline from Enzyme (I'm not sure why--Mason would know). The Enzyme pipeline doesn't remove address spaces, and without that, the compilation failed. I don't remember what the error was. Your code helped me figure this out, because your code worked, and this didn't without that change.
I hope to get the DiffEq demo running online this weekend.
Is this the most promising way of compiling for WASM right now? (As opposed to seemingly abandoned Keno/julia-wasm)
Keno managed to compile most of Julia, so you get a complete interactive environment. That's impressive. It's also a rather large download. So while it's great for interactivity, it's not great for focused web apps.
StaticCompiler can compile select methods to WebAssembly, so the result is a small WebAssembly file. That's nice for web apps. But, you can only compile a subset of Julia code. Hopefully, it's enough to be valuable for a lot of scientific code.
@Alexander-Barth, on the 64-bit compilation, I've used 64-bit Julia to compile to wasm32. I don't think the address spaces impact that. There are some places where you end up with 64-bit integers because of the use of Int
or from integer constants. It can still be okay for a lot of code. Those 64-bit integers just take up more space, but WebAssembly can still handle them. It's probably safer to use 32-bit Julia, and the code will be a bit smaller.
One issue is that it conflicts with pointer patching stuff here.
The whole pointer patching code path should only be hit when you're using compile
to pull the compiled code into a running julia session anyways, so I think there's no problem there.
StaticCompiler uses an optimization pipeline from Enzyme (I'm not sure why--Mason would know).
If I remember correctly, it basically came down to the fact that the julia pipeline wasn't modular enough for me when I was trying to avoid certain code transformations the compiler does when it generates code that's meant to be run in-session.
Thanks a lot for these explanations, Tom !
@tshort Thank you for the explanation! I'm fairly new to Julia and this is a bit above my head.
Here's my DiffEq web app using the newly merged and tagged WebAssembly support:
Very cool Tom!
Inspired by @Alexander-Barth's FluidSimDemo-WebAssembly.
I'm working on an example here.
This code adds the option to remove address spaces. Compilation to WebAssembly requires that (LLVM's driver for wasm32 doesn't like those). One issue is that it conflicts with pointer patching stuff here. So, code that needs pointer patching won't compile to WebAssembly.