GSOC Boost BigInt design issues
swagat konchada wrote:
I had a look upon the BigInt code from the sandbox. It's entirely wrapped around GMP(linked to gmblib). [snip] That is uncompatible with the Boost license, which hinders the distribution of a Boost_bigInt library which wholly is a wrapper around GMP.
Keeping in view the above issues what should be our priority? Improving the wrapping around GMP for time being or Starting Boost's own version of BigInt. I see mixed reactions on this subject. My personal opinion is that suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, which I think is in line with Boost's long term aspirations.
Rob Stewart wrote
The usual idea is that BigInt would provide expression templates and other optimizations to avoid calling the back end engine inefficiently. That may require an adapter layer between the user-visible BigInt API and the computation engine, like GMP, at the back end, to insulate the API from differences in the back end engines. (Then again, there may be nothing left to a layer above the adapter layer; I'm not saying there must be three layers.)
If GMP is an optional batck end supported by BigInt, along with other back ends, controlled by conditional compilation, then a BigInt user can choose to use GMP if they like, but the licensing issue will be theirs and not Boost's.
HTH,
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways 1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time. 2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP. In a 3 layered architecture, 3 function calls would take place for each overloaded operator, whatever the option chosen by the user. Whereas in a 2 layered architecture, in which only GMP is an extra option, there is an equal probability of a user using Boost's own bigint or GMP and thus half of the times, 2 function calls are made and in the other half only 1 function call for each overloaded operator. This means doubling in the number of function calls. Though I realize most of the time is spent inside the function rather than in calling the functions, does this result in an overhead we should worry about? -- Problem is a phenomenon indicating lack of thought. Swagat Konchada
swagat konchada wrote: Please don't overquote.
Rob Stewart wrote
The usual idea is that BigInt would provide expression templates and other optimizations to avoid calling the back end engine inefficiently. That may require an adapter layer between the user-visible BigInt API and the computation engine, like GMP, at the back end, to insulate the API from differences in the back end engines. (Then again, there may be nothing left to a layer above the adapter layer; I'm not saying there must be three layers.)
If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways
1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time.
2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP.
[snip]
This means doubling in the number of function calls. Though I realize most of the time is spent inside the function rather than in calling the functions, does this result in an overhead we should worry about?
It is premature to think this way without a real, if test, implementation for comparison. I expect the compiler to do much of the work, via expression templates, and much of the rest to be inlined, leaving relatively few real function calls to worry about. Whether your expectation or mine is correct remains to be seen, but it shouldn't be an overarching consideration at this time. What is important for a GSoC project is to design the interface well, provide the necessary points of customization to make the library appropriately flexible, produce correct results, and document the whole thing. With that done, attention can then turn to reimplementing a Boost back end or otherwise optimizing the code. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stewart, Robert Sent: Tuesday, March 30, 2010 11:52 AM To: boost@lists.boost.org Subject: Re: [boost] GSOC Boost BigInt design issues
swagat konchada wrote:
If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways
1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time.
2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP.
[snip]
IMO you should look at the discussion on a numeric_adaptor by Barend Gehrels and some draft code mentioned in http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770 to get some idea of the problem and a plausible framework which might include 'BoostsOwnBigInt' as an alternative to GMP etc. Paul PS But you should also be aware that another xInt project is being discussed on this group. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
participants (3)
-
Paul A. Bristow -
Stewart, Robert -
swagat konchada