> On Oct 27, 2014, at 7:21 PM, Gilles Gouaillardet > <gilles.gouaillar...@iferc.org> wrote: > > Ralph, > > On 2014/10/28 0:46, Ralph Castain wrote: >> Actually, I propose to also remove that issue. Simple enough to use a >> hash_table_32 to handle the jobids, and let that point to a >> hash_table_32 of vpids. Since we rarely have more than one jobid >> anyway, the memory overhead actually decreases with this model, and we >> get rid of that annoying need to memcpy everything. > sounds good to me. > from an implementation/performance point of view, should we put treat > the local jobid differently ? > (e.g. use a special variable for the hash_table_32 of the vpids of the > current jobid)
Not entirely sure - let’s see as we go. My initial thought is “no”, but since the use of dynamic jobs is so rare, it might make sense. >>> as far as i am concerned, i am fine with your proposed suggestion to >>> dump opal_identifier_t. >>> >>> about the patch, did you mean you have something ready i can apply to my >>> PR ? >>> or do you expect me to do the changes (i am ok to do it if needed) >> Why don’t I grab your branch, create a separate repo based on it (just to >> keep things clean), push it to my area and give you write access? We can >> then collaborate on the changes and create a PR from there. This way, you >> don’t need to give me write access to your entire repo. >> >> Make sense? > ok to work on an other "somehow shared" repo for that issue. > i am not convinced you should grab my branch since all the changes i > made are will be no more valid. > anyway, feel free to fork a repo from my branch or the master and i will > work from here. Okay, I’ll set something up tomorrow > > Cheers, > > Gilles > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2014/10/25621.php
