Re: [ublas] Element-wise operations are really slow

Subject: Re: [ublas] Element-wise operations are really slow
From: Vardan Akopian (vakopian_at_[hidden])
Date: 2010-04-28 02:32:45

On Tue, Apr 27, 2010 at 9:03 PM, xiss burg <xissburg_at_[hidden]> wrote:

> Gunter,
>
> Actually I got confused because you said both push_back and append_element.
> Anyway, I tried both. append_element is 100 times slower than an
> ublas::matrix with +=s. I don't know what I'm doing wrong (sorry if there's
> something really stupid there). Please take a look at the source attached.
>
> Thank you.
>
>
Xiss,

You are right, that coordinate_matrix is very slow for this example. Here is
the reason: the reserve() function gets triggered several times (at least 9
with your example code). reserve() itself calls sort(). And every time it
has more and more elements (starting with 15000 on the first call, and
finishing with about 2.7 million elements on the last call). These calls to
sort() become more expensive as the number of elements grows, and so your
main loop spends 80% of its time doing the sort() (I actually profiled it!).
I don't think this can be remedied, because you do have lots of elements
(numTetrahedrons*12*12 = 2.8 million) to append to the coordinate_matrix. So
I guess coordinate_matrix is not appropriate for this use case after all.

BTW, I think you have a bug in the attached code: r*numNodes will most
likely overflow and will become smaller than mtrand.max(), which will make
ni be equal to 0, so all elements of the index matrix will be 0, 1 or 2. I'm
pretty sure that's not what you want. One easy fix is to declare r as double
(instead of int).

-Vardan