From: Klaus S. <kla...@fr...> - 2006-08-21 21:29:25
|
Hi=20 I've checked the second solution by defining typedef boost::numeric::ublas::vector<double> Array; typedef boost::numeric::ublas::matrix<double> Matrix; and porting the rest of the QuantLib. (This breaks quite a lot interfaces=20 within the QL;-). The resulting performance is disappointing. Using normal= =20 compiler switches the ublas version is 20% slower than the original=20 implementation. When using more aggressive compiler optimization switches t= he=20 ublas can only match the original performance but is not faster. =46YI: I got 10% more performance for the test-suite without changing inter= faces=20 by using the slightly improved version of array.hpp and matrix.hpp enclosed= =20 in the attachment (I haven't checked this version too much;-) cheers=20 Klaus =20 On Thursday 22 June 2006 5:07 pm, Fran=E7ois du Vignaud wrote: > Hi all, > I'm hesitating between two solutions for the uBlas migration : Embedding > all uBlas code in the existing Array and Matrix classes. The main advanta= ge > is that no other file would be altered. However it seems really tedious to > expose all the nice features of uBlas using this architecture. Replacing > completely all Array and Matrix in the QuantLib code. > I tend to prefer the second solution because it is much neater in my > opinion even if it is not the simplest one in the short run. I'm aware th= at > uBlas is not the most efficient linear algebra library available, however > profiling shows that it is sufficient for the LFM case (sheer linera > algebra operations accounts for a small part of the computation time). Mo= re > complex operations can be performed using ATLAS through uBlas bindings. A= ny > suggestion/advice are more than welcome. > Thanks for your attention, > best regards, > Fran=E7ois |