[petsc-users] Amortizing calls to PetscOptionsFindPair_Private()
Barry Smith
bsmith at mcs.anl.gov
Sat Jan 16 12:20:56 CST 2016
> On Jan 16, 2016, at 7:12 AM, Griffith, Boyce Eugene <boyceg at email.unc.edu> wrote:
>
>
>> On Jan 16, 2016, at 12:34 AM, Bhalla, Amneet Pal S <amneetb at live.unc.edu> wrote:
>>
>>
>>
>>> On Jan 15, 2016, at 5:40 PM, Matthew Knepley <knepley at gmail.com> wrote:
>>>
>>> I am inclined to try
>>> Barry's experiment first, since this may have bugs that we have not yet discovered.
>>
>> Ok, I tried Barry’s suggestion. The runtime for PetscOptionsFindPair_Private() fell from 14% to mere 1.6%.
>> If I am getting it right, it’s the petsc options in the KSPSolve() that is sucking up nontrivial amount of time (14 - 1.6)
>> and not KSPSetFromOptions() itself (1.6%).
>
> Barry / Matt / Jed, if we were using KSPReset here and reusing KSPs, would that also bypass these calls to PetscOptionsXXX?
No that is a different issue.
In the short term I recommend when running optimized/production you work with a PETSc with those Options checking in KSPSolve commented out, you don't use them anyways*. Since you are using ASM with many subdomains there are many "fast" calls to KSPSolve which is why for your particular case the the PetscOptionsFindPair_Private takes so much time.
Now that you have eliminated this issue I would be very interested in seeing the HPCToolKit or Instruments profiling of the code to see hot spots in the PETSc solver configuration you are using. Thanks
Barry
* Eventually we'll switch to a KSPPreSolveMonitorSet() and KSPPostSolveMonitorSet() model to eliminate this overhead but still have the functionality.
>
> Thanks,
>
> -- Boyce
More information about the petsc-users
mailing list