Hi Greg,
Previously the ID type was a 64 bit integer (like).
Now they want to move it to 128 bit in future. For that struct is used,
The experimental 128 bit looks like.
struct {
int_ptr_t upper;
int_ptr_t lower;
}
For the transition, it is still 64 bit, but a struct with just one int_ptr_t
field. The integer can be taken out from it for now. But that would make it
difficult later when it moves to 128 bit fully.
Thank you
Sriraj
> On Jan 3, 2017, at 11:03 PM, Greg Titus <[email protected]> wrote:
>
> Hi Sriraj —
>
> Could you say even more about your task ID type? What are the elements of
> the structure? Could you pack them into 64 bits of an integer, or is that
> not enough space at scale and/or would cause a performance issue somehow?
> I’m curious because if you really do need more than 64 bits and/or a
> structured type, that would invalidate my earlier statement that we could
> define the task ID type the same way for all implementations.
>
> thanks,
> greg
>
>
>> On Jan 3, 2017, at 10:21 AM, sri raj paul <[email protected]> wrote:
>>
>>>
>>> Could you say more about what the "task ID" you are trying to use
>>> contains? How many bits long is it?
>>
>> The task ID I am considering is of type struct and therefore causes problems
>> with binary operations. It could be 64 or 128 bit long.
>>
>>>
>>> A simpler solution, which we’ve considered in the past but never
>>> implemented, would be to take the task ID type out of the
>>> implementation-specific definitions and just make it (say) an int64_t in
>>> all cases.
>>
>> Since we are already defining chpl_taskID_t, would it be better to use it
>> rather than converting it to 64 bit. There are runtimes (for example OCR and
>> also UPC i think) that already supports 128 bit IDs.
>>
>> Thank you
>> Sriraj
>>
>>
>>> On Jan 3, 2017, at 9:00 PM, Greg Titus <[email protected]> wrote:
>>>
>>> A simpler solution, which we’ve considered in the past but never
>>> implemented, would be to take the task ID type out of the
>>> implementation-specific definitions and just make it (say) an int64_t in
>>> all cases. The only reason I hadn’t already done this already was that it
>>> was so far down the list in importance. I wouldn’t mind a bit if someone
>>> wanted to take this on …
>>>
>>> greg
>>>
>>>
>>>> On Jan 3, 2017, at 7:42 AM, Michael Ferguson <[email protected]> wrote:
>>>>
>>>> Hi -
>>>>
>>>> On 1/2/17, 12:46 PM, "sri raj paul" <[email protected]> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am looking at the Chapel tasking-runtime source code.
>>>>>
>>>>> Each tasking model typedefs “chpl_taskID_t” to its own ID type and
>>>>> chpl_task_getId() has a return type of chpl_taskID_t
>>>>> The introduction of chpl_taskID_t might be to support multiple low-level
>>>>> runtimes.
>>>>>
>>>>> But in runtime/include/qio/qio.h:212 , Inside struct qio_lock_t , task
>>>>> owner’s ID is of type int64_t
>>>>> Later in runtime/src/qio/qio.c , inside functions qio_lock() and
>>>>> qio_unlock(), task IDs are stored int64_t variables.
>>>>> and also compared using binary operators (== , !=) in
>>>>> runtime/src/qio/qio.c:103 and 122.
>>>>>
>>>>> This causes type conversion errors if the underlying tasking model is
>>>>> using some ID type that is not compatible with integer.
>>>>> The qio files should also use chpl_taskID_t instead if int64_t.
>>>>
>>>> This change sounds reasonable to me and you could create a PR to do it.
>>>> Nonetheless the code that is there should be OK for any task ID that is a
>>>> pointer or integer type,
>>>> which is all that we have so far.
>>>>
>>>>> Also binary operators are not applicable to all types and therefore it
>>>>> will be better if each tasking model provides an isEqual() api for its ID
>>>>> type.
>>>>
>>>> I'm less certain about this one.
>>>>
>>>>> We tried this change and noticed that the runtime/src/chpl-visual-debug.c
>>>>> type-casts chpl_taskID_t to some integer type while doing printf().
>>>>
>>>> Right, chpl-visual-debug.c creates a log file for chplvis to use. The
>>>> visualization tool needs to
>>>> be able to figure out which events are in which task. I bet that for
>>>> chplvis's purposes though,
>>>> the "task ID" could be an arbitrary string.
>>>>
>>>> Could you say more about what the "task ID" you are trying to use
>>>> contains? How many bits long is it?
>>>>
>>>>>
>>>>> Again this causes problem for types not compatible with integers.
>>>>> So either a custom format specifier for ID should be made or easier
>>>>> option is to provide a chpl_taskID_t_to_integer() by each tasking model.
>>>>
>>>>
>>>> As with a custom isEqual(), I'm not sure if we need
>>>> chpl_taskID_t_to_integer. Let's talk more about
>>>> what you hope to encode in the task ID.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -michael
>>>>
>>>>
>>>>
>>>>> Just for testing, the address of chpl_taskID_t can be type casted to an
>>>>> integer pointer and then dereferenced, but this will cause loss of
>>>>> information.
>>>>>
>>>>> Thank you
>>>>> Sriraj
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------
>>>>> ----
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Chapel-developers mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Chapel-developers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
