optimization of U256

[NikVolf]

before

test u256_add ... bench:     139,774 ns/iter (+/- 8,128)
test u256_mul ... bench:   4,915,555 ns/iter (+/- 436,083)
test u256_sub ... bench:     757,326 ns/iter (+/- 47,169)

after

test u256_add ... bench:      36,160 ns/iter (+/- 2,217)
test u256_mul ... bench:     104,526 ns/iter (+/- 3,128)
test u256_sub ... bench:      35,494 ns/iter (+/- 1,163)

[debris]

nice, benchmarks are really impressive ^^ 👍

[NikVolf]

just good old asm :)

[arkpar]

What about U512? That's even more of a bottleneck currently.
I think we don't actually need multiplication of 512 -bit uints, We can get away with a custom function that multiplies two U256s into a U512.

[arkpar]

benchmark is not very accurate having a call to U256::from on each iteration.

[arkpar]

Sub::sub is still not using the asm version?

[NikVolf]

@arkpar sub uses overflowing_add
so it should become better as well

@arkpar
only u256 in this pr
u512 comes next

@arkpar
other issues resolved

[debris]

You can also move assembly code to separate .s files and compile it with gcc. It would make optimization available also on rust beta/stable.

[arkpar]

@marek We want the calls to be inlined. Also less less problems with windows later

[NikVolf]

removed warning (cause it's macros expansion, had to ignore it)

[gavofyork]

space around =.

[gavofyork]

minor style stuff. can't speak for the logic and i don't see any additional tests... coverage seems to have gone down slightly - is this spurious or an indication that additional code paths need testing?

[NikVolf]

@gavofyork
yeah right
i have plenty of tests here: https://github.com/NikVolf/asm-fun/blob/master/src/lib.rs
will migrate it

[NikVolf]

@debris indeed, Arkady right, inlining gives 2x boost to performance for add/sub