-
Notifications
You must be signed in to change notification settings - Fork 61
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
please push a later version of arm64 #105
Comments
I've been using https://github.com/mandrean/cw-optimizoor/ for this. Alternatively, you could build an arm image locally with But yeah, having a release of the latest version of this would be useful |
To be honest, I am very sceptical about the existence of the *-arm64 images. Since they produce different build results than the Intel ones, they are not suitable for reproducible builds. And this is one of the main goals of this project. If you do not need reproducible builds, you are better off not using a dockerized solution at all. cw-optimizoor does non-reproducible local builds with the native Rust compiler, this build script does the same. |
thanks @webmaster128 .. personally new to the mac scene, and am trying to get my compile-test-swear-compile loop as fast as possiblel... I'll check out the build script & optimizoor.. as for the memory issues, I haven't seen them, but I have a larger memory capacity on my dev box. |
Maybe adding that build script to the default template would help. The hard part is making sure it's not used for production 🤔 An option would be to just rename the outputs to include |
That's a fair point we need to consider on the education side. On the one hand you want a convenient development flow. On the other hand there needs to be a clear border between that and production builds. The same issue exists for In this case, maybe promoting |
I think that makes sense. The script to build locally (as well as cw-optimizoor) are useful for faster (and more colorful) builds, but they could be left as documentation for whoever needs them. I'm thinking it might make sense to have a production feature flag that gets used in the x86 version of rust-optimizer but not the arm86 version. Wasmd can then check the feature and otherwise error with something like: I was actually surprised when I first learned that contracts compiled to different wasm in arm64, and still don't understand why that's the case. Do you know if there will be a way to bridge that gap in the future? |
Well, actually it is not necessarily wrong to compile with We can open up this warning: Arm images are released to ease development and testing on Mac M1 machines. For release / production use, only contracts built with the Intel optimizers must be used. and just say that
Because all the toolchains (Rust compiler, LLVM backend, wasm-opt, …) is compiled to ARM64 including thousands of low level CPU specific case distinctions. This toolchain just produces slightly different results than a toolchain compiled to x86. The results will both be very similar and both fully functional. But not bit-for-bit the same. |
Right. So having the image available with a warning + maybe a note on https://docs.cosmwasm.com/docs/1.0/getting-started/compile-contract/#optimized-compilation about verifying the images |
Version 0.12.11 was pushed for all 4 images. I think this closes this ticket. I'll write some follow up regarding the usage any verifyability of the 4 different images. There is a lot if README to be adjusted and I think the |
rust 1.64 has some changes in the cargo/workspace stuff, which my projects uses.. I just switch to a M1 and now I can't optimize contracts anymore ;-(
The text was updated successfully, but these errors were encountered: