Test GMP impact on performance

[Boyan-MILANOV]

Following comments about improving performance in #5:

If using GNU MP turns out to be a bottleneck, here are some alternatives to consider

• https://github.com/bluescarni/mppp
• https://github.com/libntl/ntl
• BOOST multiprecision

Random thoughts:

• Using uint512_t instead of true multiprecision numbers could be useful it it allows the library to use stack-allocated objects instead of dynamically allocating them
• The most important point is not how fast the multi-precision computation is but rather how efficient the object creation/copy is. MP numbers are part of Maat's Number class, and Number objects are created all the time, so the cost of creation of an MP object is by far the most important

[Boyan-MILANOV]

I need to confirm this but it seems that mpz objects are not initialised when default-constructed, resulting in no extra memory allocation. This means virtually no overhead (except calling the mpz_class constructor) when using Number with values on 64 bits or less. If it is indeed the case then using GMP is less an issue than I originally thought, and the room for improvement gets much smaller (for values on less than 64 bits). We could consider to stick with GMP.

Cases where GMP could still impact performance significantly would be

• code using A LOT of SSE2/AVX instructions, manipulating mostly 128+ bits values
• EVM bytecode if we decide to support it, because it uses uint256_t a lot