Ok Thanks Sean. Well will get into libbn when i finish with my pull
routine :). But the test could be integrated into brlcad for testing core
functionality of libbn routines.
Cheers!
Nyah
On Fri, Jul 26, 2013 at 6:09 AM, Christopher Sean Morrison
<[email protected]>wrote:
>
> On Jul 25, 2013, at 4:07 PM, Check Nyah wrote:
>
> >Also, were the numbers stable? That is, your two results are
> approximately 65s vs 55s which is about 15% reduction in time. If you ran
> the comparison a couple more >times with different matrices, is always
> about 15%?
>
> Well the test was based on the fact that the code generates a real
> transformation matrix, by constructing a random orthonormal basis vector
> triplet *x*,*y*,*z*, i.e. ||*x*||=1, ||*y*||=1, ||*z*||=1, *x*·*y*=0, *x*·
> *z*=0, *y*·*y*=0, *x*×*y*=*z*, plus a random translation vector *t*.
>
>
> That doesn't really answer the question about whether the performance
> numbers were stable... The question is really just inspecting how much of
> an influence CPU cache levels are having on performance, how much of an
> error bar there is on the *rate* of improvement in the general use case.
> That said, your numbers as provided are already informative enough to
> characterize the impact. Nicely done.
>
> My *bn_mat_inverse()* is clearly faster than the current libbn
> implementation -- even if mine does a full 4x4 matrix inverse, and the old
> libbn one something else! The most important point is that mine is easy to
> verify, and does work on all matrices you care to throw at it (that are not
> singular); the speed boost is just an added bonus.
>
> My *bn_mat_determinant()* is only slightly faster than the current libbn
> implementation. However, mine is much more robust wrt. compiler
> optimizations: the existing implementation is only fast if the compiler can
> optimize the code (which might uncover bugs elsewhere in the code,
> considering the code base is pretty old). Considering how robust and simple
> it is, and that it is *never slower* than the existing implementation (in
> fact is significantly faster if the compiler does not perform heavy
> optimization), I'd recommend using mine instead.
>
>
> An excellent summary and you stated much of that earlier too. My comments
> before weren't an indication of doubt (or trust). Assertions are pretty
> much irrelevant when it comes to changing core API. It's best to always
> test and prove it's correct / better or, if only, to have metrics behind an
> improvement claim.
>
> We really only care about objective demonstrable algorithm correctness,
> code maintainability, and runtime performance during optimized compiles.
> If you do it enough, testing can go REALLY quickly. Your testing
> demonstrated all three points brilliantly. Again, nicely done.
>
> Cheers!
> Sean
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> BRL-CAD Developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
