Another summary:
Summary:
- bn_mat_determinant()
GCC 4.6.3 compiles both existing libbn and my implementations to roughly
equally efficient binary on x86-64 if optimizations are enabled. Without
compiler optimizations, mine is clearly faster.
Without optimizations, mine runs in 154 cycles (minimum and median),
whereas the libbn one takes 210 cycles minimum, 219 cycles median. (Mine is
almost a third faster!)
With typical optimizations, '-O2', mine runs in 92 or 93 cycles (minimum
and median), whereas the libbn one runs in 95 cycles (minimum and median).
The relative difference in the results for a large set of random
matrices was always under one billionth, 10-9. That is, the error is
roughly the same order as the precision of a square root of some value,
sqrt().
- bn_mat_inverse()
Using GCC-4.6.3, my implementation is demonstrably faster than the
existing libbn implementation -- even if the existing libbn implementation
cannot invert all non-singular real-valued 4x4 matrices! (I verified some
of my random matrices using Maple.)
Without optimization, my implementation is three times as fast,
completing in 544 cycles (median value), whereas libbn implementation
requires 1660 cycles (median value).
With -O2, my implementation takes 423 (minimum) to 432 (median) cycles,
whereas libbn implementation takes 610 (minimum) to 660 (median) cycles.
My preferred maximum level of optimization is '-O3
-fomit-frame-pointer'; my implementation takes 423 (minimum) to 427
(median) cycles, whereas libbn implementation takes 466 (minimum) to 483
(median) cycles; in the median case, my implementation is still 11% faster.
The maximum level of optimization I tried is '-O3 -fomit-frame-pointer
-ftree-vectorize -march=native -mtune=native'. Mine still runs in 420 to
426 cycles, whereas libbn took 480 to 500 cycles.
Already created patch together with these results on sf.
Cheers!
Nyah
On Thu, Jul 25, 2013 at 6:25 PM, Check Nyah <[email protected]> wrote:
> Hey Sean,
> Just ran the tests comparing the old and new routines for computing the
> determinant and which gave me the following results:
>
> Old_determinant Test:
> Det: -3291.00
> real 1m5.151s
> user 1m5.081s
> sys 0m0.019s
>
> New_determinant Test:
> Det: -3291.00
> real 0m54.921s
> user 0m54.815s
> sys 0m0.054s
>
> To run for Inverse matrix routines now.
>
> Cheers!
> Nyah
>
>
>
> On Thu, Jul 25, 2013 at 3:14 PM, Christopher Sean Morrison <[email protected]
> > wrote:
>
>>
>>
>> On Jul 25, 2013, at 08:38 AM, Check Nyah <[email protected]> wrote:
>>
>> >Please do share your test and summarize your testing results here or on
>> the patch itself when you have it. If you need help setting up the test
>> harness, just ask. We >seem to end up writing a quick test harness for
>> something ever week. :)
>>
>> I have already implemented and tested the algorithm with patch already on
>> sf [https://sourceforge.net/p/brlcad/patches/216/ here]. Well i need
>> some assistance in setting up the test and returning the results for both.
>> But patched in the code and performed a benchmark test which returned all
>> results correct.
>>
>>
>> The benchmark is what's called an integration test. It's too high-level
>> for properly evaluating this change. It is a good high-level sanity check,
>> but it's not sufficient for this.
>>
>> When I talked about writing a test, I meant literally writing something
>> like:
>>
>> int
>> main(int ac, char *av[])
>> {
>> int i;
>> mat_t m;
>> for (i=0; i<123123; i++) {
>> m = some random matrix;
>> call bn_mat_determinant(mat);
>> }
>> }
>>
>> And then you can time that with something like "time ./a.out" and just
>> keep increasing that 123123 loop until time shows that it's taking 30-60
>> seconds. Run it a few times until the numbers are stable, then change
>> bn_mat_determinant to yours and compare. That'll demonstrate the
>> performance impact.
>>
>> Then to test correctness, you can do the same loop, but call both
>> bn_mat_determinant() and yours, compare the result and make sure they're
>> the same.
>>
>> This isn't going to be production code, this is quick and dirty to proof
>> it's right/better. It's a good habit to learn how to write and compile
>> little main() programs on the fly.
>>
>> 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
