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. 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. > 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.)
pgpTudGJMpQfi.pgp
Description: PGP signature
