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
