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.