> On Oct 27, 2014, at 7:21 PM, Gilles Gouaillardet
> 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
>>
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
> On Oct 26, 2014, at 11:12 PM, Gilles Gouaillardet
> wrote:
>
> Ralph,
>
> this is also a solution.
> the pro is it seems more lightweight than PR #249
> the two cons i can see are :
> - opal_process_name_t alignment goes from 64 to 32 bits
> - some functions
Ralph,
this is also a solution.
the pro is it seems more lightweight than PR #249
the two cons i can see are :
- opal_process_name_t alignment goes from 64 to 32 bits
- some functions (opal_hash_table_*) takes an uint64_t as argument so we
still need to use memcpy in order to
* guarantee 64
Just took a glance thru 249 and have a few suggestions on it - will pass them
along tomorrow. I think the right solution is to (a) dump opal_identifier_t in
favor of using opal_process_name_t everywhere in the opal layer, (b) typedef
orte_process_name_t to opal_process_name_t, and (c) leave
No :-(
I need some extra work to stop declaring orte_process_name_t and
ompi_process_name_t variables.
#249 will make things much easier.
One option is to use opal_process_name_t everywhere or typedef orte and ompi
types to the opal one.
An other (lightweight but error prone imho) is to change