I came across https://github.com/iden3/ffiasm and wondered if this asm code has ever been benched against the actual implementation. And if so, whether it is faster.
I did some initial exploration and saw that most of the asm backend we have at PSE (see here) is as optimized as what rust here compiles too. (At least for fns like double as seen in: #44 (comment)
From a quick look, to functions like double or square looks like the exact same thing or even slightly worse:
Square
| Instruction |
asmffi |
PSE-ASM (Ash) |
| PUSH |
4 |
0 |
| MOV |
20 |
19 |
| XOR |
1 |
2 |
| MULX |
36 |
36 |
| ADCX |
39 |
28 |
| ADOX |
28 |
0 |
| BT |
2 |
0 |
| SHL |
1 |
0 |
| ADD |
2 |
28 |
| SUB |
2 |
2 |
| SBB |
0 |
6 |
| CMOVC |
0 |
8 |
| TOTAL |
135 |
129 |
Double
From a superficial view is already obvious that PSE-ASM is has less ops.
So I just wonder if anyone has done a deep analysis on that. As from a short check, looks like is not worth even considering it.
I came across https://github.com/iden3/ffiasm and wondered if this asm code has ever been benched against the actual implementation. And if so, whether it is faster.
I did some initial exploration and saw that most of the asm backend we have at PSE (see here) is as optimized as what rust here compiles too. (At least for fns like
doubleas seen in: #44 (comment)From a quick look, to functions like
doubleorsquarelooks like the exact same thing or even slightly worse:Square
Double
From a superficial view is already obvious that PSE-ASM is has less ops.
So I just wonder if anyone has done a deep analysis on that. As from a short check, looks like is not worth even considering it.