Skip to content
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

Closed
wants to merge 6 commits into from
Closed

Testing Arm Support #1210

wants to merge 6 commits into from

Conversation

faddat
Copy link

@faddat faddat commented Feb 4, 2022

No description provided.

@faddat
Copy link
Author

faddat commented Feb 7, 2022

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.

@webmaster128
Copy link
Member

This is desired, but we'll not rush into this. This has multiple reasons.

  1. Various patches have to be shipped this week/near term in order to unblock Juno
  2. Wasmer 2.2.0 is not ready and has open issues
  3. We want to perserve a wider range of Rust compiler versions than proposed in this diff

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.

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).

@faddat
Copy link
Author

faddat commented Feb 7, 2022

@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.

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).

So basically, it's failing because the gas estimation looks too low to be correct?

@webmaster128
Copy link
Member

webmaster128 commented Feb 7, 2022

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.

So basically, it's failing because the gas estimation looks too low to be correct?

The cargo wasm command creates the Wasm of the contract. By bumping the compiler version in the CI, you use a compiler that produces more efficient output. So in order to fix the test in the CI, you need to reduce the expected gas usage in that test.

@faddat
Copy link
Author

faddat commented Feb 7, 2022

Hey!

So I just encountered-- everything you just said :).

I'll summarize and please let me know if I have any of this wrong?

  • MSRV is because of contract gas? Different versions of rust can cause quite different gas estimates, basically?

I haven't worked with rust very much before-- is this like, a rust thing, or a cw thing?

@faddat faddat changed the title Testing with arm support for Juno and Osmosis Testing Arm Support Feb 7, 2022
@faddat
Copy link
Author

faddat commented Feb 7, 2022

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 :)

@webmaster128
Copy link
Member

  • Different versions of rust can cause quite different gas estimates, basically?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants