Hi Sriraj — What I was wondering was really, what needs are driving this expansion to 128 bits and multiple fields? For example, are you expecting to put, say, a network node ID in one field and a node-local unique task identifier in the other, so that taken together they form a task ID which is unique across an entire multi-locale program? Or maybe even a full locale ID plus a task ID? Chapel’s current task IDs are unique only within a node (top-level locale), since the tasking implementations are all intra-node so far. So if you were considering a multi-locale tasking implementation I could see a need for a larger task ID. At this point I’m really just trying to understand the requirements are.
thanks, greg > On Jan 3, 2017, at 11:18 AM, sri raj paul <[email protected]> wrote: > > 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
