4 ms·

It's really annoying that any non-LGPL haskell project you release needs to be dynamically linked to libgmp instead of statically linked because of the LGPL res

It's really annoying that any non-LGPL haskell project you release needs to be dynamically linked to libgmp instead of statically linked because of the LGPL restrictionss. We have a similar discussion about it going on here: http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/ http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_... Might make a haskell FFI libray to this library.

wbhart 13y ago
I took a look at that discussion. It looks to me like he might be comparing the mpz interface in GMP against a lower level interface. Of course GMP has the latter too, and it's likely much faster than the one he is writing. It sounds like he switches to single word arithmetic when he can. We do that in flint, and it is faster. But it's more like a factor of two, which makes me very suspicious of the benchmarking there. There was a Scheme implementation which once beat GMP for very large integer multiplication, and Magma was also once faster. But those days are long gone. GMP beats what a compiler can do by a factor of 4-12 depending on the compiler version and their high level algorithms are insanely technical. I simply don't believe someone can beat 20 years of GMP development in a few days with a Haskell compiler.
- jerf 13y ago
  If you look through that thread, you'll find much of the community is pretty skeptical too (including me, same name). Even my citing of 1.5x - 2x was intended to be quite conservative; I'd be happy with rough-factor-of-magnitude. Being willing to add primops is a bit of a wildcard, though; since that means changing what the compiler outputs it means that with enough work, you could juts theoretically convince the compiler to emit the same code an optimized library does. It's not just "Haskell of today" that you're looking at (which I think we'd all trivially agree could not come close in performance on this particular task), it's "Haskell of tomorrow with newly-added features for this task" that we're looking at, and that's harder to guess what its performance could be. (That's nothing to do with Haskell, of course; any language implementation that went that route would see hard-to-predict performance jumps.)
  - wbhart 13y ago
    Yes, I understand. I did a quick benchmark to get a ballpark figure for his 10 large integer multiplications, and using GMP's basecase code (which is much slower than the asymptotically faster algorithms it provides) I get about 2ms on my machine. Assuming his machine is a similar speed to mine, that puts him only a factor of about 4 behind GMP. That's actually pretty good. You need a pretty modern GCC to do that in C. So I will be interested in seeing what he finally releases. The addition timings don't seem realistic. GMP can add 1000 small integers in 10 uS without even getting out the assembly primitives.
jordigh 13y ago
> It's really annoying that any non-LGPL haskell project you release needs to be dynamically linked to libgmp instead of statically linked because of the LGPL restrictionss. You should note that the FSF's opinion is that statically or dynamically linking does not alter the status of the result being derivative work or not.
- dragonwriter 13y ago
  > You should note that the FSF's opinion is that statically or dynamically linking does not alter the status of the result being derivative work or not. Dynamic linking may or may not create a derivative work on applicable copyright law (on which matter the FSF's opinion is merely the FSF's opinion), but static linking involves directly embedding the libraries code into the final product, which is unmistakably within the exclusive rights of copyright. In any case, the FSF's opinion on this issue actually makes the GPL more problematic than the alternative would make it.
- comex 13y ago
  Yes, but if you statically link, the LGPL requires providing a way for a user to switch to a modified version of the library (e.g. a .a of the rest of the application), which is more hassle than just using dynamic linking.
  - belorn 13y ago
    By definition, dynamic linking will be less of an hassle (and give better performance) than statically linking. After all, this is the original purpose of dynamic linking. It is also more secure for the user of an computer system.

wbhart 13y ago

I took a look at that discussion. It looks to me like he might be comparing the mpz interface in GMP against a lower level interface. Of course GMP has the latter too, and it's likely much faster than the one he is writing. It sounds like he switches to single word arithmetic when he can. We do that in flint, and it is faster. But it's more like a factor of two, which makes me very suspicious of the benchmarking there. There was a Scheme implementation which once beat GMP for very large integer multiplication, and Magma was also once faster. But those days are long gone. GMP beats what a compiler can do by a factor of 4-12 depending on the compiler version and their high level algorithms are insanely technical. I simply don't believe someone can beat 20 years of GMP development in a few days with a Haskell compiler.

jerf 13y ago
If you look through that thread, you'll find much of the community is pretty skeptical too (including me, same name). Even my citing of 1.5x - 2x was intended to be quite conservative; I'd be happy with rough-factor-of-magnitude. Being willing to add primops is a bit of a wildcard, though; since that means changing what the compiler outputs it means that with enough work, you could juts theoretically convince the compiler to emit the same code an optimized library does. It's not just "Haskell of today" that you're looking at (which I think we'd all trivially agree could not come close in performance on this particular task), it's "Haskell of tomorrow with newly-added features for this task" that we're looking at, and that's harder to guess what its performance could be. (That's nothing to do with Haskell, of course; any language implementation that went that route would see hard-to-predict performance jumps.)
- wbhart 13y ago
  Yes, I understand. I did a quick benchmark to get a ballpark figure for his 10 large integer multiplications, and using GMP's basecase code (which is much slower than the asymptotically faster algorithms it provides) I get about 2ms on my machine. Assuming his machine is a similar speed to mine, that puts him only a factor of about 4 behind GMP. That's actually pretty good. You need a pretty modern GCC to do that in C. So I will be interested in seeing what he finally releases. The addition timings don't seem realistic. GMP can add 1000 small integers in 10 uS without even getting out the assembly primitives.

jordigh 13y ago

> It's really annoying that any non-LGPL haskell project you release needs to be dynamically linked to libgmp instead of statically linked because of the LGPL restrictionss. You should note that the FSF's opinion is that statically or dynamically linking does not alter the status of the result being derivative work or not.

dragonwriter 13y ago
> You should note that the FSF's opinion is that statically or dynamically linking does not alter the status of the result being derivative work or not. Dynamic linking may or may not create a derivative work on applicable copyright law (on which matter the FSF's opinion is merely the FSF's opinion), but static linking involves directly embedding the libraries code into the final product, which is unmistakably within the exclusive rights of copyright. In any case, the FSF's opinion on this issue actually makes the GPL more problematic than the alternative would make it.
comex 13y ago
Yes, but if you statically link, the LGPL requires providing a way for a user to switch to a modified version of the library (e.g. a .a of the rest of the application), which is more hassle than just using dynamic linking.
- belorn 13y ago
  By definition, dynamic linking will be less of an hassle (and give better performance) than statically linking. After all, this is the original purpose of dynamic linking. It is also more secure for the user of an computer system.