Re: [Boost-users] Integral type with no upper limit?
2009/5/26 Marshall Clow
At 1:00 AM +0200 5/27/09, Michiel Helvensteijn wrote:
Perhaps Boost shouldn't reinvent the wheel? There's already an open-source arbitrary precision arithmetic library: http://gmplib.org/
Which says: GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non-free programs.
There are people using Boost for both free and non-free programs. It's my understanding that we (Boost) want to continue to support all of them.
Personally, I think Boost would be best served providing some sort of expression template wrapper into which different arbitrary-precision numbers could be plugged. That would mean far less work to get something usable, as it could use the GMP implementation initially. Then a BSL version of the implementation could be developed incrementally, while non-floss users could license some implementation to use with the Boost interface.
I would also be really interested in this. I use GMP and I am pretty
satisfied with it, but I think there are interesting things that could be
done, like:
- template-based constant-size operands whose size could be selected at
compile time. This would eliminate dynamic allocation of memory, which is
needless for certain use cases (i.e., I want a 256-bit integer behaving like
native ints, or a float with strictly 512-bit mantissa, etc..), and open up
room for further speed optimizations. With generic programming it may be
possible to share a big chunk of the implementation between constant-size
and variable-size types;
- header-only library: if used with small operands, GMP can suffer some
performance penalty related to function call overhead. Maybe it would be
possible to minimize it using aggressive inlining?
F.
On Wed, May 27, 2009 at 6:18 AM, Scott McMurray
At 1:00 AM +0200 5/27/09, Michiel Helvensteijn wrote:
Perhaps Boost shouldn't reinvent the wheel? There's already an
open-source
arbitrary precision arithmetic library: http://gmplib.org/
Which says: GMP is distributed under the GNU LGPL. This license makes the
2009/5/26 Marshall Clow
: library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non-free programs.
There are people using Boost for both free and non-free programs. It's my understanding that we (Boost) want to continue to support all of them.
Personally, I think Boost would be best served providing some sort of expression template wrapper into which different arbitrary-precision numbers could be plugged.
That would mean far less work to get something usable, as it could use the GMP implementation initially. Then a BSL version of the implementation could be developed incrementally, while non-floss users could license some implementation to use with the Boost interface. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG francesco biscani wrote:
- header-only library: if used with small operands, GMP can suffer some performance penalty related to function call overhead. Maybe it would be possible to minimize it using aggressive inlining?
Optimizing compilers can inline across translation units, these days. In Christ, Steven Watanabe
On Thu, May 28, 2009 at 8:58 AM, Steven Watanabe
AMDG
francesco biscani wrote:
- header-only library: if used with small operands, GMP can suffer some performance penalty related to function call overhead. Maybe it would be possible to minimize it using aggressive inlining?
Optimizing compilers can inline across translation units, these days.
No way! Really? That's so cool. What compilers currently utilize such an optimization?
On Thu, May 28, 2009 at 8:58 AM, Steven Watanabe
mailto:watanabesj@gmail.com> wrote: AMDG
francesco biscani wrote:
- header-only library: if used with small operands, GMP can suffer some performance penalty related to function call overhead. Maybe it would be possible to minimize it using aggressive inlining?
Optimizing compilers can inline across translation units, these days.
No way! Really? That's so cool. What compilers currently utilize such an optimization? Microsoft, Intel, LLVM-GCC with appropriate linker support (i.e. MacOS
Robert Dailey wrote: linker, llvm-ld, or gold), experimental in GCC trunk, and probably others. Sebastian
Optimizing compilers can inline across translation units, these days.
No way! Really? That's so cool. What compilers currently utilize such an optimization?
I believe that the Intel compiler's "Interprocedure Optimizations" will do that: basically the source is translated to an intermediate format (not quite an object file), and then the linker does all the hard work. Of course you need to compile everything with IPO turned on for it to work, it's *not* going to work if you just link against -lgmp or something. John.
2009/5/27 francesco biscani
- header-only library: if used with small operands, GMP can suffer some performance penalty related to function call overhead. Maybe it would be possible to minimize it using aggressive inlining?
The big danger there is that the FSF's interpretation is that inlining is more than linking (since they only really allow shared libraries), and as such your project would have to be LGPL.
participants (6)
-
francesco biscani
-
John Maddock
-
Robert Dailey
-
Scott McMurray
-
Sebastian Redl
-
Steven Watanabe