[boost] GSOC Boost BigInt design issues

Subject: [boost] GSOC Boost BigInt design issues
From: swagat konchada (swagatata_at_[hidden])
Date: 2010-03-30 01:17:52

> >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_at_[hidden]
> 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