3 ms·

A bitch to use on just about every language in existence. The issue is having code that links to this breaks cross platform support -- especially in interpreted

A bitch to use on just about every language in existence. The issue is having code that links to this breaks cross platform support -- especially in interpreted languages. Just a few days ago I had to try find a library for Rust that did fixed precision calculations with integers and most of them linked to GMP instead of implementing code in Rust. It meant I had to use another library because third-party deps breaks the complex build process for my teams software. In special software like cryptography I've also seen GMP avoided for speed reasons.

FartyMcFarter 5y ago
You can't blame this on GMP. People are free to interface with it in better ways from the languages you mention. As for speed, I'm sure some very specialized applications can do better if they have constraints that allow for specific optimization, but as far as a general library goes I haven't seen better performance than GMP personally.
- brandmeyer 5y ago
  GMP doesn't do well in prime fields with a small, fixed number of limbs. Poly1305 and elliptic curves are both good examples. Its general routines aren't as fast as custom routines, and it doesn't execute in constant time. MPFQ exists for short finite field work, but it hasn't achieved the popularity of GNU MP. https://gitlab.inria.fr/mpfq/mpfq https://gitlab.inria.fr/mpfq/mpfq
jcelerier 5y ago
> It meant I had to use another library because third-party deps breaks the complex build process for my teams software this is what software such as CMake was created to solve. I guess the solution is to extend CMake to support Rust :)
- Sesse__ 5y ago
  That would be nontrivial (although probably not impossible). At least that was Meson's experience in trying to support Rust: https://lwn.net/Articles/820836/ https://lwn.net/Articles/820836/
  - jcelerier 5y ago
    I remember when people were like "compiler monoculture bad", wonder what changed since then to make people like that ecosystem so much.
    - smoldesu 5y ago
      Rust has multiple compilers, but only a couple of them get actually used. If you're wondering what changed, it's probably 40 years of being forced to draw a 3-way Venn diagram between Clang, LLVM and GCC every time you want to build your software. The added conventions of Rust in conjunction with it's package specification means that most compilers are just going to be boring.
    - uluyol 5y ago
      cargo is not a compiler, it's a build system. The difference between build systems and compilers is that compilers implement language specs, and build systems do whatever they want. That's the problem with having multiple build systems. The fact that there is so much heterogeneity in C/C++ land means I spend way too much time trying to build things. When things are standardized, I don't have to think much about builds. They just work. If build systems were made to interoperate (e.g. by having a common spec, or by implementing the same behavior), then we could have competing build systems without the fragmentation.

FartyMcFarter 5y ago

You can't blame this on GMP. People are free to interface with it in better ways from the languages you mention. As for speed, I'm sure some very specialized applications can do better if they have constraints that allow for specific optimization, but as far as a general library goes I haven't seen better performance than GMP personally.

brandmeyer 5y ago
GMP doesn't do well in prime fields with a small, fixed number of limbs. Poly1305 and elliptic curves are both good examples. Its general routines aren't as fast as custom routines, and it doesn't execute in constant time. MPFQ exists for short finite field work, but it hasn't achieved the popularity of GNU MP. https://gitlab.inria.fr/mpfq/mpfq https://gitlab.inria.fr/mpfq/mpfq

jcelerier 5y ago

> It meant I had to use another library because third-party deps breaks the complex build process for my teams software this is what software such as CMake was created to solve. I guess the solution is to extend CMake to support Rust :)

Sesse__ 5y ago
That would be nontrivial (although probably not impossible). At least that was Meson's experience in trying to support Rust: https://lwn.net/Articles/820836/ https://lwn.net/Articles/820836/
- jcelerier 5y ago
  I remember when people were like "compiler monoculture bad", wonder what changed since then to make people like that ecosystem so much.
  - smoldesu 5y ago
    Rust has multiple compilers, but only a couple of them get actually used. If you're wondering what changed, it's probably 40 years of being forced to draw a 3-way Venn diagram between Clang, LLVM and GCC every time you want to build your software. The added conventions of Rust in conjunction with it's package specification means that most compilers are just going to be boring.
  - uluyol 5y ago
    cargo is not a compiler, it's a build system. The difference between build systems and compilers is that compilers implement language specs, and build systems do whatever they want. That's the problem with having multiple build systems. The fact that there is so much heterogeneity in C/C++ land means I spend way too much time trying to build things. When things are standardized, I don't have to think much about builds. They just work. If build systems were made to interoperate (e.g. by having a common spec, or by implementing the same behavior), then we could have competing build systems without the fragmentation.