Austin Huang (Nov 16 2020 at 13:06): Austin Huang (Nov 16 2020 at 13:06):Hi everyone. Have been following wasm for a while (since the asm.js days), but am new to working with it hands on.
I am a co-author on the hasktorch (torch-based NN) library for Haskell https://github.com/hasktorch/hasktorch and am keen to get machine learning capabilities into wasm and wasi, starting with the C++ library that PyTorch (and hasktorch) uses.
(not directly related to wasi-nn but once i get more familiar with the basics and design I hope to contribute in some way there too)
So far we've have had some success - thanks to help from my hasktorch collaborator Junji Hashimoto, am able to get libtorch built and running a small program.
Screen-Shot-2020-11-16-at-8.04.02-AM.png
Austin Huang (Nov 16 2020 at 13:07):However, trying to get the same .wasm binary to run in wasmtime, I get the following error:
Any ideas/pointers?
Dan Gohman (Nov 16 2020 at 13:56):If WebAssembly is an ISA, Emscripten and WASI are a little like two different operating systems which can run on it.
Dan Gohman (Nov 16 2020 at 13:58):Emscripten's compiler produces code which relies on JS support code and is designed to run in a JS engine, such as in a browser or Node
Dan Gohman (Nov 16 2020 at 13:59):Pure-Wasm engines like Wasmtime don't have JS, and in general aren't able to run code which depends on it.
Dan Gohman (Nov 16 2020 at 14:00):So today, the main way to compile C++ code to run in non-Web non-JS WebAssembly engines is to compile it with wasi-sdk
Austin Huang (Nov 16 2020 at 18:39):Thanks for the background @Dan Gohman, that's very helpful. emscripten has an emcmake tool that's a drop-in replacement for cmake. Is there an equivalent in wasi-sdk? Or what would you recommend for migrating a cmake build system to use wasi-sdk?
Austin Huang (Nov 16 2020 at 22:10):related basic question - emscripten produces javascript scaffolding for execution, that makes sense... does the lack of compatibility include to a library builds as well? or is there some way of calling out to emscripten-built library object files from a wasi-sdk built executable? thanks for bearing with me on this simple stuff.
Dan Gohman (Nov 16 2020 at 22:57):Nothing official yet, though you may find the scripts here helpful: https://github.com/bcoin-org/libtorsion/tree/master/scripts
Dan Gohman (Nov 16 2020 at 23:01):There are ways to make library use cases like what you mention work, though they're not very ergonomic right now.
Austin Huang (Nov 19 2020 at 01:18):To clarify re: emscripten and wasi, from this article https://v8.dev/blog/emscripten-standalone-wasm it seems like emscripten should be capable of generating standalone wasm builds that can run in wasmtime just using the extension - "Another nice thing about standalone Wasm files is that you can run them in Wasm runtimes like wasmer, wasmtime, or WAVM."
Is this article incorrect? Or maybe I'm not understanding something?
Dan Gohman (Nov 19 2020 at 01:22):It's partly true. If you use Emscripten and limit yourself to the features that Emscripten can implement with WASI calls and nothing else, then it works.
Dan Gohman (Nov 19 2020 at 01:22):But, Emscripten doesn't offer any help and will happily mix in calls to its own runtime which aren't present in all non-Web wasm runtimes.
Dan Gohman (Nov 19 2020 at 01:23):And, wasi-sdk has several compatibility features, such as allowing functions like open to work using WASI. In Emscripten, if you call open, you get a call to an Emscripten-specific library function.
Dan Gohman (Nov 19 2020 at 01:25):wasi-sdk is dedicated to the non-Web use case. Emscripten treats the non-Web use case as an awkward subset of its main functionality.
Last updated: Dec 23 2024 at 12:05 UTC