This all was very useful for me to know, thank you. Dominik
On Thu, Nov 24, 2011 at 3:18 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > On Thu, Nov 24, 2011 at 07:46, Dominik Szczerba <dominik at itis.ethz.ch> > wrote: >> >> Yes, that is true, but 1) within the overshot preallocation margin 2) >> I do it at each execution of the loop, so I do not see why only the >> second time there are mallocs. I display mallocs directly before >> KSPSolve(). > > The matrix is compacted. The implementation > (MatSeqAIJSetPreallocation_SeqAIJ) could be changed to analyze the newly > prescribed preallocation relative to the old allocation and determine that > it can fit within the old storage. The problem here is that someone might > specifically preallocate smaller because they want to free the old storage. > So maybe we should just recognize an exact match, but what if the user > called MatCreateMPIAIJWithSplitArrays() (so they still own the arrays) and > they are calling this preallocation routine because they want to reuse the > arrays for something else? > If we can settle on some understandable semantics for when freeing and > reallocating makes sense, then we can put it in. > Or you could insert zeros into those locations that might be used later. > >> >> > I suggest assembling all possible entries (even the ones that happen to >> > be >> > zero) in the first assembly. Then there will be space and you can reuse >> > the >> > data structure. >> >> This will require a bigger change in my code. Is always calling >> MatMPIAIJSetPreallocation a bad (inefficient) alternative? > > Depends on the availability of memory, but probably not. Always profile.
