这是一个创建于 1888 天前的主题，其中的信息可能已经有所发展或是发生改变。
WASMan （ WebAssembly Manager ）简单来说就是个基于纯 golang 的 wasm(v1) binary 解释器。
制作原因
迫于先技术选型了 go，又迫于 wasmtime-go 内存（ bytes ）操作不友好，wasmer-go 不支持 win，wagon 停止维护且使用手感不咋样，gasm 往 gojs 方向跑远了，且个人需要类似 eth 的 gas cost 等非主流设计。
制作过程
作为菜鸡，先是试图加入 wasmtime 结果被 memory 绕的一脸懵逼，又把时间都浪费在 docstring 和 bazel support 上了，结果发现加非主流设计改动太大。
然后自己开始制作，边翻译 wasm 的 spec 边参考 wagon，gasm，wasmtime-go，wasmer-go 慢慢写了一个月。
因为初始是从 gasm 改的所以 license 也保留了原作者。
现状
当前 WASMan 基本上算是w3c的最简化可实行产品，此外添加了类似 gas cost 的 toll-station 和与 host 之间的 string 交互方案（这也是基本上每个同类产品 issue 里的常客，然而基本上没人清楚告知 issue author 该怎么做，只说参数只能 i32/64 f32/64 ）。
当前的运行速度正常来说应该是不如 wasmtime 、wasmer 的，基本上 go 的都没法和 rust 打，况且人家还 JIT 优化。
TODO
当前还在增加新的 features，例如 validator 和标准 wasi 。
因为这些我暂时用处不大所以动力不是很足……
 | 1 missdeer 2020-10-15 08:32:22 +08:00 其实现在比较想要一个 framework |
 | 2 c0mm4nd OP @missdeer 面向 web 的 wasm framework 其实挺多的，尤其是 rust 上的。 其实 wasm 本身就是你把编译目标调整到 wasm32 之后只要语言支持就能直接编译，框架什么的就一些常用操作的 wrapper 。 https://www.reddit.com/r/golang/comments/ddyja9/canonical_go_wasm_framework_blazor_for_go/ 原生 go 上因为现在是靠个写死的 wasm_exec.js 所以基本上可以认为是顶多就能用……基本上只要引入第三方包就肯定需要像 tidb 那样排雷 https://pingcap.com/blog-cn/tidb-wasm-introduction/ 不过个人更喜欢面向 server 的……老实交代就是拿来当智能合约引擎，所以也就和这些 framework 反着跑了…… |
 | 3 charten 2020-10-15 12:37:24 +08:00 方向错了吧？ webassembly 要的不是解释器，而是编译器呀，把它那串 wasm 字节码编译成目标机器码，然后直接跑机器码速度才上去的呀。相当于 js 在 v8 内 jit 的水平，v8 的 jit 也是对于固定类型频繁执行的函数，从解释执行变为编译后跑机器码执行，速度才上去的。 |
| 5 c0mm4nd OP @charten 的确是这样的。 但是如果追求速度那还是应该去怀抱 rust （ wagon 就做编译做到弃疗了），用 wasmtime-go 和 wasmer-go 也是很香的。 wasmer-go 和 wagon 速度和是一个天一个地。 https://github.com/wasmerio/wasmer-go#benchmarks 纯 go 这边需要做到的只是最基础的可运行和 go 环境中易适配易魔改（就那一大堆 proposal，还有像 ewasm，cosmwasm 这种第三方针对智能合约引擎方向的魔改）。 当然也因为我菜写不动…… @DoctorCat 是有需求才撸的……不然也不会做那么多~市场~issue 研究…… |
Select Language