
Bsdnt – A BSD-licensed bignum library - wbhart
https://github.com/wbhart/bsdnt/tree/v1.0
======
fdej
As a benchmark, I tested computing exp(1) using the binary splitting algorithm
(gmp/mpir code: [https://gist.github.com/fredrik-
johansson/8198480](https://gist.github.com/fredrik-johansson/8198480) \--
bsdnt code: [https://gist.github.com/fredrik-
johansson/8198432](https://gist.github.com/fredrik-johansson/8198432)).

    
    
        digits   mpir         bsdnt
        100      0.0000126    0.0000176
        1000     0.0000803    0.000113
        10000    0.000945     0.0015
        100000   0.0171       0.037
        1000000  0.266        1.19
        10000000 4.37         40.52
    

Not bad for 1.0!

Edit: python's built-in bignums for reference:

    
    
        100       0.000125
        1000      0.000290
        10000     0.00518
        100000    0.292
        1000000   26.1
        10000000  long

~~~
zhemao
A bunch of people have been asking for benchmarks of LibTommath for
comparison. I've ported this benchmark to tommath at
[https://gist.github.com/zhemao/8204404](https://gist.github.com/zhemao/8204404).

Here are the runs on my machine

BSDNT

    
    
        digits = 100: 2.43242e-05 s
        digits = 1000: 0.000143717  s
        digits = 10000: 0.0016644 s
        digits = 100000: 0.0378964 s
        digits = 1000000: 1.20317 s
        digits = 10000000: 40.1549 s
    

GMP

    
    
        digits = 100: 1.64086e-05 s
        digits = 1000: 0.000117272 s
        digits = 10000: 0.00113377 s
        digits = 100000: 0.0175584 s
        digits = 1000000: 0.284023 s
        digits = 10000000: 4.96335 s
    

TOMMATH

    
    
        digits = 100: 4.90092e-05 s
        digits = 1000: 0.000302586 s
        digits = 10000: 0.00548351 s
        digits = 100000: 0.368923 s
        digits = 1000000: 36.7576 s
        digits = 10000000: longer than I was willing to wait
    

I have no idea why libtommath gets so slow for larger numbers. Would anyone
care to comment? I think something must be wrong in the way I ported the
benchmark.

~~~
luckydude
Any chance we can see results for 10 digits as well? The reason I ask is I'm
guessing that a lot of work will actually be with smaller numbers of digits.

Is it possible to design a math lib that uses native ints/floats for stuff
that fits and switches in the big num stuff on overflow? I believe ruby does
this, do any of the libs do it?

I think the ruby approach is to cast the 32 bit items to 64 bit, do the
operation into a 64 bit, see if any of the top 32 bits are set, if so, switch
to bignum, if not, use the result. If tommath or any of the others do that,
then I don't really care that much (for my purpose which is scripting langs
that use tommath) about the big num perf. Faster is better but the high order
bit for me, at least, is perf on the smaller numbers.

~~~
fdej
Yes, for example the fmpz type in flint
([http://flintlib.org/](http://flintlib.org/)) implements this optimization,
and also caches bignum objects for quick allocation/deallocation. Here is the
benchmark with the mpir mpz type vs the flint fmpz type:

    
    
                           mpz           fmpz
        digits = 10:       4.24e-06 s    1.2e-06 s
        digits = 100:      1.28e-05 s    3.3e-06 s
        digits = 1000:     8e-05 s       2.7e-05 s
        digits = 10000:    0.001 s       0.0006 s
        digits = 100000:   0.017 s       0.013 s
        digits = 1000000:  0.25 s        0.23 s
        digits = 10000000: 4.32 s        4.08 s
    

In fact, the benchmark is a bit biased against the mpz type because it spends
a lot of time allocating and deallocating temporary mpz's. It would be much
faster to replace the recursion by a loop with in-place operations when b - a
< 20, say. (On the other hand, unoptimized code of this kind is probably quite
common in practice...)

------
arianvanp
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_...](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/)

Might make a haskell FFI libray to this library.

~~~
jordigh
> 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.

~~~
comex
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
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.

------
crististm
For each of these projects that herald the BSD license as a feature, I ask
myself - what's wrong with GPL? In fact, if it wasn't for GNU and GPL, the
world would be a very different place than it is now. I would claim that there
would be no such abundance of free software that we find today.

So why do some people route around GPL?

~~~
wbhart
I develop GPL software too. Quite a lot of it, actually. I'm not sure what you
mean by "route around GPL".

I chose BSD because it will maximise usability in certain BSD licensed
programming languages.

You can always fork the code, put the GPL on it and distribute it under those
terms if you want.

~~~
crististm
You can't fork a BSD project and relicense it as GPL unless you are the
copyright owner.

"Route around GPL" is the tendency to avoid GPL license on new projects (or to
change the license on existing projects - see VLC and jquery). Since project
owners are free to do that anyway, the question is why is the BSD license
trumpeted as a feature of the product?

Let's take the example of LLVM: there is no problem using GCC on MACs since
GCC itself can be used to build proprietary systems. However, LLVM is promoted
as "this is your dream compiler - fast, feature full and free from GPL
restrictions".

~~~
wbhart
I don't understand the comment about forking. Sure, you can't take my files
and change the license on them. But you can take any and all of my files as
is, incorporate them into your own GPL project. That's effective the same
thing as now the project itself must be distributed under the terms of the
GPL. So long as you don't violate the terms of the BSD license, you are free
to do what you want. Going the other way is not possible. (Of course when I
say BSD license I mean modified-BSD, not the original 4-term license. We don't
use that of course.)

------
raverbashing
Congrats

It's good to have some competition in this area.

I used mostly NTL (which can use GMP)
[http://www.shoup.net/ntl/](http://www.shoup.net/ntl/) and it provides some
good resources, maybe it's too high level for the goals of this project, but
you can always take some idea.

But the downside is that NTL is GPL as well.

~~~
wbhart
We already have 220,000 lines of (GPL) C code competing with NTL:
[http://flintlib.org/](http://flintlib.org/) :-)

------
gioele
> It is not a goal to insanely optimise where that would make the code less
> readable and maintainable.

> Future improvements: * Unroll assembly loops

:)

~~~
wbhart
Nicely spotted. Though to be fair MPIR's assembly was improved using a
superoptimiser and many more complex algorithms have assembly versions. It
could take days for an inexperienced person to understand them. I hope to
avoid that complexity (at the obvious loss of some performance) in bsdnt.

------
riffraff
I am completely unqualified to comment on these so feel free to correct me,
but isn't libtommath a liberally licensed (WTFPL) that also provides efficient
bignums?

~~~
wbhart
I'd be interested to see a performance comparison. :-)

------
anonymouz
Are there advantages of this over MPIR or GMP? (If I don't care about the
different licenses).

~~~
wbhart
Simplicity and code size are important. With a large complex project like MPIR
(which, being derived from GMP is certainly faster) it is very difficult for
newcomers to make contributions. This typically means you are already
contributing to GMP (or MPIR) or not at all. So we might hope to develop a
larger community around bsdnt because of the lower barrier to entry.

On a more technical level, the divide-and-conquer integer division algorithm
in BSDNT is brand new, as is the basecase division. There are also technical
improvements in the mullo, mulmid and mulhi interfaces, with 2 words
overflows. The FFT I hope to include in the next version also represents
significant improvements from only a couple of years ago (though it is already
in MPIR).

There are lots of other innovations, such as a dramatically simplified build
system, on account of the inline assembly. The zz0 interface is a new idea; it
allows one to use light weight signed multiprecision integers in the low level
multiprecision natural number interface (nn). And we also test that our
pseudorandom generator yields the same values on all systems by taking the
sha1 hash of a long stream of output.

------
thu
I don't know well the subject hence the question: isn't there a bignum library
within OpenSSL (Apache-style license)?

~~~
wbhart
Yes, but for crypto you only need to optimise for small "bignums". So
performance is not satisfactory for larger stuff, at least not last time I
looked. Which was a while ago.

~~~
wbhart
I should add that crypto is a whole 'nuther ballgame. You often need your
algorithms to not leak information. That often means going to pretty insane
lengths to ensure that.

The standard in good crypto software is also so much more exacting. You don't
want to be 99.9% sure it has no exploitable bugs. You want to be 99.999% sure.

I'm absolutely no kind of crypto expert. I'm a number theorist. In no way
would bsdnt be suitable for use in crypto applications!

------
luckydude
Has anyone compared this to libtommath?

------
tehwalrus
This looks very cool, I will keep an eye on it, thanks!

