-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
feat: non simd sha256 for incompatible systems #427
base: master
Are you sure you want to change the base?
Conversation
Update: nvm, we haven't used but the wasm code was loaded anyway |
f55d080
to
bdf755c
Compare
ddd5c17
to
51b1bdd
Compare
Performance Report✔️ no performance regression detected Full benchmark results
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to use WebAssembly.validate
to synchronously do "feature detection" and avoid a lot of complexity related to async initialization here.
(It appears that wasm-feature-detect
is using WebAssembly.validate
under the hood.)
eg:
import {wasmCode} from "./wasmCode.js";
import {wasmSimdCode} from "./wasmSimdCode.js";
const hasSimd = WebAssembly.validate(wasmSimdCode);
const _module = new WebAssembly.Module(hasSimd ? wasmSimdCode : wasmCode);
final, | ||
digest, | ||
digest64 | ||
} from "./common"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a non-simd implementation of batchHash4UintArray64s
and batchHash4HashObjectInputs
here (making the interface of simd and non-simd wasm module the same). Then the javascript layer won't need runtime checking and the only refactor there is the module reinitialization.
Motivation
An issue was posted about systems that do not support simd feature set. Made library compatible with those systems.
See ChainSafe/lodestar#7177 for more information.
Description of Changes
as-sha25