We have been working hard on this release that adds support for ARM64 and Apple M1 chipsets in Singlepass (our compiler, mostly used in Web3/Blockchain environments).
In Wasmer we aim to make software universally available (regardless programming languages, operating systems or chipset used), by leveraging on WebAssembly.
Let me know if you have any questions, I'd be very happy to answer them!
I think WebAssembly is going to play a key role in Universal Computing. In my impression, the pace for moving some Wasm specs forward could be improved, but there are big players that need to be aligned and that has a cost.
On the other hand, the ecosystem is really picking up a good pace and there are new players and tools being launched everyday. I'm personally very excited to know where we are heading as a community!
EDIT: I did tested in Safari and Chrome (iOS) and things are working properly there. Do you have JS enabled? Could you provide more details that will help reproducing the issue? Thanks!
I was confused what you could possibly mean by that but then I read the opening paragraph:
> The Wasmer 2.2 release features significant advancements shaping up to impact our Web3 and blockchain community in a big way. Wasmer is reintroducing Aarch64 compatibility for our Singlepass compiler. With the newly overhauled Singlepass, Web3 and blockchain developers can efficiently run Wasmer Runtime with Singepass on Windows, Linux, and macOS. The new release also fully supports the much anticipated Apple M1 processor.
And since the rest of the post doesn't mention anything more, I share your curiosity.
Several blockchains like NEAR are using WASM, but I could only find these resources about blockchains using Wasmer:
https://wasmer.io/case-studies/confiohttps://cosmwasm.com/
"CosmWasm is supporting fourteen different Cosmos projects, including Terra, Regen Network, and Crypto.com"
> Confio's smart contracts allow blockchain developers to add new functionality to their blockchain at runtime. The engineering team at Confio quickly realized that some containerization and sandboxing technology were required to ensure the host machine's safety. WebAssembly was a natural choice since one of its core features is default sandboxing. WebAssembly applications require explicit permission and interfaces to access host machine data and resources.
Wasmer has not invented the wheel here nor we were the first ones to create a Wasm runtime for the server-side (WAVM should probably have an honorific mention somewhere!).
All our work has been based in some way or another on the shoulders of previous projects from great developers and ecosystems, and for that we will be eternally grateful <3 (examples of this are WAVM, cervous, nebulet, perlin's life and many more!)
It seems like the whole point of the "singlepass" compiler is to avoid "JIT bombs", which in the context of compiling WASM in a smart-contract blockchain solution, could be a vector for a DOS attack.
If you aren't compiling maliciously crafted WASM programs, then the runtime performance of the cranelift or LLVM compilers would appear to be generally more desirable.
Wasm is a sandbox first off. Any situation where you want to isolate a computation is an application suitable for wasm. Browser is just one instance of that
I'm a Python developer. Two needs I have for WASM are:
- I want to use libraries like ffmpeg without first figuring out how to compile them and talk to them through Python bindings. If the JavaScript community have already done the work to compile ffmpeg to WASM then I can use it from Python too - on any platform that has a Python WASM runtime.
- I want a safe sandbox for executing untrusted code - for example, I'd like to build a plugin system for one of my projects where the users of that project can execute code they find on the internet without fear of it 0wning their computer. Sandboxing Python scripts (and Sandboxing for most other languages) is notoriously hard to do safely. WASM offers a rock-solid, widely tested sandbox mechanism.
Pretty impressed with the performance of the cranelift and singlepass backends. They've come a long way.
I am wondering why the LLVM backend takes so long to compile the TiDb Wasm. Presumably it doesn't take >3 days to compile TiDb from source with llgo and rustc. Why would compiling it to Wasm first make it take way longer to compile than from source?
LLVM compilation times can be for sure improved further, although to be honest we haven't focused on it yet (as this long compilation times are more like an edge case atm).
In general, compiling to Wasm gives you the universality over a chipset or OS. Imagine that you compile TiDB today to Wasm, tomorrow you will be able to run it in chipsets or platforms where it was not available today (RISC-V, for example), without the need of installing a toolchain to rebuild the binary... just with a small runtime like Wasmer.
It is one thing that 2.2 is 5x or 10x faster than 1.0, but without some well known / understood figures; C, Java or LuaJIT. It is hard to judge the relative performance. I know a lot of these are not fair comparison, but ( as Benedict Evans likes to put it ), relevant comparison. As I would like to know the cost of abstraction and isolation.
30 comments
[ 3.0 ms ] story [ 78.7 ms ] threadWe have been working hard on this release that adds support for ARM64 and Apple M1 chipsets in Singlepass (our compiler, mostly used in Web3/Blockchain environments). In Wasmer we aim to make software universally available (regardless programming languages, operating systems or chipset used), by leveraging on WebAssembly.
Let me know if you have any questions, I'd be very happy to answer them!
I've got excited about WebAssembly and used it with C#'s Blazor
but I feel like it moves incredibly slow, especially things like GC / DOM Access, etc.
It feels like we're getting closer and closer to half of the decade
How do you see it?
On the other hand, the ecosystem is really picking up a good pace and there are new players and tools being launched everyday. I'm personally very excited to know where we are heading as a community!
This is across the entire site.
EDIT: I did tested in Safari and Chrome (iOS) and things are working properly there. Do you have JS enabled? Could you provide more details that will help reproducing the issue? Thanks!
> The Wasmer 2.2 release features significant advancements shaping up to impact our Web3 and blockchain community in a big way. Wasmer is reintroducing Aarch64 compatibility for our Singlepass compiler. With the newly overhauled Singlepass, Web3 and blockchain developers can efficiently run Wasmer Runtime with Singepass on Windows, Linux, and macOS. The new release also fully supports the much anticipated Apple M1 processor.
And since the rest of the post doesn't mention anything more, I share your curiosity.
So the reality is, its just and WASM and lots of people trying to build stuff on WASM.
https://github.com/search?q=org%3Aspacemeshos+wasmer&type=co...
https://github.com/search?q=org%3Acosmos+wasmer&type=code
And a case study: https://wasmer.io/case-studies/confio
> Confio's smart contracts allow blockchain developers to add new functionality to their blockchain at runtime. The engineering team at Confio quickly realized that some containerization and sandboxing technology were required to ensure the host machine's safety. WebAssembly was a natural choice since one of its core features is default sandboxing. WebAssembly applications require explicit permission and interfaces to access host machine data and resources.
Wasmer has not invented the wheel here nor we were the first ones to create a Wasm runtime for the server-side (WAVM should probably have an honorific mention somewhere!).
All our work has been based in some way or another on the shoulders of previous projects from great developers and ecosystems, and for that we will be eternally grateful <3 (examples of this are WAVM, cervous, nebulet, perlin's life and many more!)
If you aren't compiling maliciously crafted WASM programs, then the runtime performance of the cranelift or LLVM compilers would appear to be generally more desirable.
WASM only good for client side web browsers, anything is a pure waste of time and human resources
[1] https://github.com/wasmerio/wasmer-js/
What's up with Rust people bloating everything?
I'm a Python developer. Two needs I have for WASM are:
- I want to use libraries like ffmpeg without first figuring out how to compile them and talk to them through Python bindings. If the JavaScript community have already done the work to compile ffmpeg to WASM then I can use it from Python too - on any platform that has a Python WASM runtime.
- I want a safe sandbox for executing untrusted code - for example, I'd like to build a plugin system for one of my projects where the users of that project can execute code they find on the internet without fear of it 0wning their computer. Sandboxing Python scripts (and Sandboxing for most other languages) is notoriously hard to do safely. WASM offers a rock-solid, widely tested sandbox mechanism.
I am wondering why the LLVM backend takes so long to compile the TiDb Wasm. Presumably it doesn't take >3 days to compile TiDb from source with llgo and rustc. Why would compiling it to Wasm first make it take way longer to compile than from source?
In general, compiling to Wasm gives you the universality over a chipset or OS. Imagine that you compile TiDB today to Wasm, tomorrow you will be able to run it in chipsets or platforms where it was not available today (RISC-V, for example), without the need of installing a toolchain to rebuild the binary... just with a small runtime like Wasmer.
It is one thing that 2.2 is 5x or 10x faster than 1.0, but without some well known / understood figures; C, Java or LuaJIT. It is hard to judge the relative performance. I know a lot of these are not fair comparison, but ( as Benedict Evans likes to put it ), relevant comparison. As I would like to know the cost of abstraction and isolation.