-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing Arm Support #1210
Testing Arm Support #1210
Conversation
Hi I have some comments and questions here. First of all, is this desired? I figure that wasmer 2.2.0 may land in time for the osmosis upgrade. Secondly, I really couldn’t figure out why the hackathon contract was failing. If anybody has any pointers for me about this, I would really appreciate it. Thirdly, I’d like to say why I desire this. The reasons are I suppose twofold: I think that this will remove developer friction when working on both contracts and Blockchain code. Many of us, including me have shifted to using the Apple M1 CPU. And so part of my motivation here is to allow developers to work on the stuff with the same ease and fluidity that they were anything else. My second motivation, is something I have spoken about a little bit but have taken much more serious measures toward recently. I would like to create a single board computer for validators. One of the appealing platforms for this is the nvidia Jetson. In fact, a Jetson CPU will even be compatible with the GPU requirements needed for the bostrom project. we have chosen a hardware engineering design firm at Notional, and have begun preliminary engineering discussions and paid a deposit. Ensuring that CW is arm compatible, will ensure that chains built using CW will be able to use this hardware, which is designed to make validating as simple and secure as possible. |
This is desired, but we'll not rush into this. This has multiple reasons.
This is because the compiled Wasm got very efficient for the Argon2 execution when using the latest Rust version. See https://gist.github.com/webmaster128/c0f8292d071522f694fd69a11e280738 and cosmos/cosmjs#907 (comment). |
@webmaster128 OK, sounds good to me. When I patched CI, I dropped the concept of MSRV, and just used the latest released Rust. Is that alright? Appreciate your detailed reply above. <3 PS: I guess what I'm proposing is that I'll get this ready to go, how you'd like it, and leave e'r here for when v2.2.0 of wasmer has hit a release.
So basically, it's failing because the gas estimation looks too low to be correct? |
I am as excited as you for the ARM support, @faddat 🚀. Thanks for giving it a try. I already tested locally what you proposed here. We'll get there very soon. But the new feature should not get in the way of pending patches. MSRV is a hot topic and pretty problematic. We compile with Rust 1.55.0 in wasmvm as we had big issues with newer version. Those can be handled, but we cannot so everything at once. So basically what I would like to do is to take it easy and break it down. We can bump the MSRV to 1.54 without issues. This might already help to compile everything.
The |
Hey! So I just encountered-- everything you just said :). I'll summarize and please let me know if I have any of this wrong?
I haven't worked with rust very much before-- is this like, a rust thing, or a cw thing? |
I'll also change this to a draft PR. If at all possible for osmo, I'd love to get this in mainly just so that I can continue to compile locally. If not possible I guess I'll pick up a new laptop :) |
In this particular case, the difference is very big. The Wasm output is 3x faster than a few months ago. But this is Argon2 where a few optimization in the hot path of the code can make a huge difference. The general rule of thumb is: be nice to developers and accept a wide range of Rust compilers. For the production build, use a very recent one to get the latest and greatest optimizer. |
No description provided.