Risc V greatly underperforms
tg at gmplib.org
Wed Oct 6 10:47:51 UTC 2021
Hans Petter Selasky <hps at selasky.org> writes:
Then you get a penalty. But the penalty might not be so big assuming
random input. Adding one to a number is pretty cheap and you only need
to continue traversing the data words making up the number when the
increment overflows. Which in turn gets you a variable number of
Not good, side-channel leakage.
How microcode works and what instruction sequences are optimal for a
bignum adder, I will not go into. My point is just that x86
instructions are parsed before they are executed. Almost like a VM.
Ahum. But Risc V instrutions are not "parsed" you say?
I would guess that if RISC-V executed "N" instructions at a time on
the same logical core w/o using microcode, the performance would be
comparable to x86. Then it would be up to the compiler to layout the
instructions correctly and not the microcode.
You guess wrong.
Most instructions today has a latency of a single cycle, be it Risc V,
some x86 core, or Arm.
Arm has the most powerful instruction set. But x86 also has powerful
instructions, albeit very messy from both a programmer's perspective and
from the hardware's perspective.
Now you claim that something magic (parsing, microcode) slows things
down on x86. Somehow, a single-cycle instruction on x86 is really
magically slower than a single-cycle instruction on Risc V.
You're dead wrong.
X86 will use many fewer instructions than Risc V for any task since X86
has many more instructions and many instructions are also more powerful.
Typically, instructions run in a single cycle and does not involve
Risc V will never compete with Arm or x86 for integer scientific tasks
(including crytpography). It won't even come close. It would need to
run at clock speeds several times higher than the competition to come
(Modern CPUs are complex, and surely many instructions are not executed
as simply as a plain add. Some instructions are internally split, e.g.,
"add mem,reg" might be split into a load and a register-based add. But
the opposite is also true, that some instruction pairs are glued to at
later stages be seen as a single instruction. )
Please encrypt, key id 0xC8601622
More information about the gmp-devel