On 04/17/2014 03:47 PM, Jed Brown wrote:
Eric Chamberland <[email protected]> writes:
Now I noticed another thing while measuring performances (notice: I used
a PETSc compiled with debugging=yes... please don't flame me...):
The first assembly for a 549252 square matrix takes me 4.505s but if i
sort the indices passed to MAT_SET_VALUES (which I can do since I add
only zeros) it takes only 1.655s!!!!! Sorting the indices costs me only
0.4s...
How many nonzeros per row? If you pass unsorted entries to the first
assembly, insertion/row management will degrade from O(nnz*log(nnz)) to
O(nnz^2). This doesn't matter for short rows.
Mostly 52 nz per rows.
Total nz is 28 086 003;
Meanwhile, PETSc does not know if you pass all entries for a row in one
call or will be calling several times. If you pass all the entries, it
could make sense for _us_ to sort for you, but otherwise, it doesn't get
around the more expensive row shifting.
This is exactly what I am doing: I pass all the entries for identical
lines... (if any).
Is this a normal behavior? If so, it means we shall number our DOF in a
way that the elementary matrices have DOF # that are mostly sorted while
doing the "standard" assembly?
After the first assembly, it shouldn't make much difference, though
there are mild optimizations we could make if people wanted to guarantee
sorted input. (It's not clear these matter; usually assembly is faster
after the first time.)
ok.
Thank you!
Eric
