Re:A smaller, cheaper RISC V board
by userbinator on Thursday September 21, 2017 @12:01AM
(#15300503)
REP MOVS/STOS is not optimized at all
That might've been true for a period some time ago, but before and after that it has been the preferred way to do memcpy() or memset() since it can operate on entire cachelines at a time. It's one of the fastest, if not the fastest, and also the absolute smallest (which helps with icache consumption), while leaving the SIMD registers free to do more... useful things than shuffling data around.
Why is that supposed to be more difficult? Matching combinable instructions is trivial.
How is it "trivial" to match a round of AES or SHA, or a multiplication or division algorithm, or even a memory copy/store loop, so they can be replaced with the optimal hardware implementation...?
That might've been true for a period some time ago, but before and after that it has been the preferred way to do memcpy() or memset() since it can operate on entire cachelines at a time. It's one of the fastest, if not the fastest, and also the absolute smallest (which helps with icache consumption), while leaving the SIMD registers free to do more... useful things than shuffling data around.
https://stackoverflow.com/questions/43343231/enhanced-rep-mo...
https://github.com/golang/go/issues/14630
Why is that supposed to be more difficult? Matching combinable instructions is trivial.
How is it "trivial" to match a round of AES or SHA, or a multiplication or division algorithm, or even a memory copy/store loop, so they can be replaced with the optimal hardware implementation...?