<div dir="ltr">I think that currently there is an expectation on the user's part that most of the necessary options can obtained by the object from the options database right before (or during) XXXSetUp() -- a sort of "pull" model, rather than the explicit "push" with XXXSetYYY(). In particular, we can probably rule out the additional flexibility of setting from options and then overriding some of those options programmatically with XXXSetYYY(). We can legislate that expectation by simply moving all XXXSetFromOptions() calls inside XXXSetUp() so that it's called only once right before the setup code runs. <div>
<br><div>That allows us to enclose all of the options in PetscOptionsBegin()/End() and friends, which is useful for -help, publishing, etc. (There may be a minor exception here or there, e.g., when PetscOptionsFindPair_Private() and such intervene). That might also force a reorganization of some of the setup code (e.g., PCFieldSplit's), that has gotten to be hard to follow. We can also protect against repeated string checking with a flag checked at the granularity of XXXSetUp().</div>
<div><br></div><div>There may be a corner case where for some private object we might not want to acquire options from the database. That can be prevented by setting some obscure prefix that would match nothing in the database. An alternative would be to move the code from XXXSetFromOptions() into XXXSetUp(), but make XXXSetFromOptions() only set a flag (true by default), that would turn on/off the setting of the options from the database. That would be a bit with odds with the semantics of XXXViewFromOptions(), though. </div>
</div><div><br></div><div>I'm not sure how to short-circuit the options checking at runtime short of dlsym() of different versions of the same routine.</div><div><br></div><div>Dmitry.</div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, Nov 25, 2013 at 8:03 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Trying again then: I see two types of option checking<br>
<br>
1) Inside XXXSetFromOptions(), I believe we can protect these so they are only called when they can actually have an affect to actually set some options<br>
<br>
2) All the various -xxx_view that are in the code to help with understand what it is doing, what the matrices look like etc. For example -ksp_mat_view that allows saving the matrix right before a solve or -pc_factor_mat_view etc. These are called in tight loops sometimes because we want to check things in those tight loops.<br>
<br>
It may be possible to organize all the -xxx_view calls through a universal PetscObject/XXXViewFromOptions() call that gets dropped into the source code wherever we like. But we have a runtime option that short-circuits the call so no checks are actually made and hence no cost. Conceivably you could even apply this option selectively to only some objects.<br>
<br>
I’ll see if I can organize XXXViewFromOptions() universally and make a branch to see if this API makes sense. Regardless using XXXViewFromOptions() consistently will be better than the hodgepodge we have now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Nov 25, 2013, at 6:38 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
><br>
>> If we put all the options passed in into a hash table then won’t a<br>
>> PetscOptions look up be pretty cheap, compute the hash, look in the<br>
>> table, check that the strings match with a strncmp, done (usually)<br>
>> and at worst do 2 or 3 string compares?<br>
><br>
> Yes, I have always thought that we should use a hash for the options table...<br>
><br>
>> If we adopt the view that an options check is very cheap that we<br>
>> don’t need to worry much about options being rechecked right?<br>
><br>
> ... however, I don't think it changes the picture that we should move<br>
> options testing out of the fast path for algorithms. The hash just<br>
> pushes the pain point down somewhat, most importantly, in a way that is<br>
> scalable in the total number of options in the options table. But with<br>
> a big options table, it's still a lot of string hashing and a lot of<br>
> likely cache misses probing into the options hash.<br>
><br>
> I would like to make PETSc competitive for integrating 20-species<br>
> chemical systems, and I don't see room for string operations in that<br>
> world.<br>
<br>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div></div>