Hans Petter Selasky <h...@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 iterations.
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 "microcode". 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 close. (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. ) -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
