<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 25, 2013 at 6:38 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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"><div class="im">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>
</div>Yes, I have always thought that we should use a hash for the options table...<br>
<div class="im"><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>
</div>... 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>
</blockquote></div><br>I agree with every object having clearly defined configure and compute</div><div class="gmail_extra">phases. However, I do not think its all that useful to prescribe a single</div><div class="gmail_extra">
model for all objects, just that the objects are clear about the model they</div><div class="gmail_extra">use. Some objects have a ton of setup to do, often with dependent parts.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
I would like us to be clearer about how we get the information to objects.</div><div class="gmail_extra">For instance, I want a way to trace back to whoever set the option. If its</div><div class="gmail_extra">code, what line? If its input, from where? It has become untenable to</div>
<div class="gmail_extra">setup deeply nested solvers with the API, so options need to become a</div><div class="gmail_extra">universal way to configure objects.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener
</div></div>