Remove GMP field implementation #168

1. 
   sipa commented at 11:46 am on December 17, 2014: contributor

   The GMP field implementation is has no constant-time guarantees, so shouldn’t be used for production code. In addition, it is hard to optimize for, as it uses a different bounds/normalization pattern. Also, if it is autoselected you end up with an extra dependency.

   If we want a reference field implementation, I’m sure a more readable plain-C one is possible (with horrible performance).

2. Remove GMP field implementation 7277fd76e2
3. 
   laanwj commented at 12:38 pm on December 17, 2014: member

   ACK. If isn’t safe for production code it shouldn’t be configurable with simple configure flags. Also fewer combinations to test.
4. 
   gmaxwell commented at 4:47 pm on December 17, 2014: contributor

   Sounds fine to me. I believe the only place its faster anymore is x86 32bit (and even then maybe only on more recent cores). Arm and PPC are faster with the internal one.
5. 
   sipa commented at 5:36 pm on December 17, 2014: contributor

   field=gmp is around 22% faster here than field=32bit (on -m32 -O3, core i7, no endomorphism, no bignum). I expect that x86-specific assembly can beat that number.
6. sipa merged this on Dec 18, 2014
7. sipa closed this on Dec 18, 2014

   ---

8. sipa referenced this in commit 6d1660663f on Dec 18, 2014
9. 
   DavidEGrayson commented at 2:50 am on December 18, 2014: none

   README.md still mentions GMP, so probably that should be removed.
10. 
    laanwj commented at 8:36 am on December 18, 2014: member

    This is about just the field implementation. GMP can still be used for num (mostly the modular inverse).
11. sipa cross-referenced this on Dec 20, 2014 from issue Weak normalization by sipa

Contributors
sipa laanwj gmaxwell DavidEGrayson