Re: [boost] different matrix library?

Subject: Re: [boost] different matrix library?
From: DE (satan66613_at_[hidden])
Date: 2009-08-19 13:56:01

on 18.08.2009 at 18:59
 joel wrote :
>> looks smart and tricky but i don't see any advantages over computed
>> indeces but only wasted spaces and time (for allocating additional
>> storage for pointers)
>> at the same time dereferencing a pointer is like computing an index -
>> no computational advantage agai
> Back to this issue here is the generated code using
> 1/ NRC array of dimension 4
> [code here]
> Lo and behold ;)
> Doing the computation of index jump int he allcoation helps tremendously.
i got somewhat unexpected results

i reimplemented 'matrix' in terms of nrc
here are results

1. a small mixin to vector operations
disadvantage is ~10% - predictable
(here by advantage i mean ratio (old_time - nrc_time)/old_time
since i assume that nrc would outperform old (non-nrc) code (should
be nrc_time<old_time, then ration is >0)
if the ratio is negative then it is actually a disadvantage
value of ratio is in % for convenience)

2. intensive matrix operations (+-* etc.)
advantage is roughly zero - predictable

3. matrix multiplication
advantage is roughly zero for best implementation - predictable
(see mul.png)

4. matrix inversion (inplace, full pivoting)
_advantage_ is ~15% - totally unpredictable
(see inv.png)

actually it's difficult for me to explain the reason
since it implements full pivoting maybe acceleration of the search
process defeats the slowness of reducing cycles
or maybe i made a mistake

however i can explain cases 1-3 disadvantages by the involvement of
additional allocation/deallocation and setup process i'm still
wondering about the latter case

but i consider an invertion such an unwanted corner case and that's
why i suggest to implement computed indeces for 2d case

however for you, joel, there is nothing to bother since your point is
perfectly motivated

-- 
Pavel