<div class="gmail_quote">On Tue, May 10, 2011 at 10:16, Gong Ding <span dir="ltr"><<a href="mailto:gdiso@ustc.edu">gdiso@ustc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":7yh">I just use uthash <a href="http://uthash.sourceforge.net" target="_blank">http://uthash.sourceforge.net</a>. It is a bsd licensed hash table implementation.<br></div></blockquote><div><br></div><div>I used uthash at one point and later switched to a slightly customized version of khash (<a href="https://github.com/attractivechaos/klib/blob/master/khash.h">https://github.com/attractivechaos/klib/blob/master/khash.h</a>) which I like much better. See these blog posts by the author:</div>
<div><br></div><div><a href="http://attractivechaos.wordpress.com/2008/08/28/comparison-of-hash-table-libraries/">http://attractivechaos.wordpress.com/2008/08/28/comparison-of-hash-table-libraries/</a></div><div><a href="http://attractivechaos.wordpress.com/2008/09/02/implementing-generic-hash-library-in-c/">http://attractivechaos.wordpress.com/2008/09/02/implementing-generic-hash-library-in-c/</a></div>
<div><br></div><div>If PETSc is going to adopt a generic C hash implementation for use in multiple places, it is worth considering.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":7yh">
At present, the hash key is <row,col> pair. Using row index as hash key, and store each row as dynamic array of col, value<br>
is possible.<br>
In general, hash table with key <row,col> is fast enough.<br></div></blockquote><div><br></div><div>This also has less overhead for when most rows are preallocated correctly. Without benchmarks for specific use cases, I don't see a convincing argument either way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":7yh"><div class="im">
<br>
</div>Add hash table to original AIJ avoid the type name problem. However, there are some other matrix types also derived from AIJ. i.e.<br>
CSRPERM.</div></blockquote><div><br></div><div>AIJPERM uses AIJ for assembly so it would also benefit if preallocation spills were handled with the hash. There are also genuinely different formats (e.g. BAIJ) that could benefit from the hash. As perhaps a future matter, it may be worth hooking in at the level of MatSeqXAIJReallocateAIJ. This might not actually be hard, it looks like the right information is already available. I think that hideous macro would need to be turned into a function before doing anything else.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":7yh"> As a result, I guess CSRPERM will also crash...<br>
I think each sub type (of AIJ matrix, i.e.) should hold its base type. And mumps interface only needs to check the base type.</div></blockquote></div><br><div>Yes, better handling of base types is needed for several things now so it will be done soon.</div>