You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently polyval (and thus crates built on top of it) uses 32-bit soft backend which was written with targets without wide multiplication in mind. However, this code can be quite inefficient for targets which do support wide multiplication, such as:
WASM32: u32s can be extended to 64 bits and multiplied using i64.mul.
RISC-V: wide multiplication is implemented by combining MULHU and MUL operations (hardware may fuse them later into a single instruction).
Also it may be worth to add a soft backend for 64-bit targets without wide multiplication? Though right now I can't name a target for which it could be useful.
The text was updated successfully, but these errors were encountered:
The current 32-bit backend is largely targeted at things like microcontrollers and should probably be gated on thumb* and other microcontroller targets specifically.
According to the comment it may be also useful on i386 targets, no? I guess we can make the 32-bit wide backend default and enable the 32-bit nonwide one only for selected targets.
What are your thoughts about the potential 64-bit nonwide backend?
According to the comment it may be also useful on i386 targets, no?
Wasn't aware Rust even supported those!
What are your thoughts about the potential 64-bit nonwide backend?
I think it's ok to add additional backends (or perhaps decompose the existing backends into separate target-specific codepaths) as long as there's a reasonable performance justification.
Currently
polyval
(and thus crates built on top of it) uses 32-bit soft backend which was written with targets without wide multiplication in mind. However, this code can be quite inefficient for targets which do support wide multiplication, such as:u32
s can be extended to 64 bits and multiplied usingi64.mul
.MULHU
andMUL
operations (hardware may fuse them later into a single instruction).Also it may be worth to add a soft backend for 64-bit targets without wide multiplication? Though right now I can't name a target for which it could be useful.
The text was updated successfully, but these errors were encountered: