Hi Greg, I am not fully sure of what exactly the bit field will be used for. These are global IDs (distributed) and therefore they will contain information about network node ID and so on. These ID’s are unique across the whole multi-locale system. I can see your point that Chapel’s current task ID’s are unique within a node and therefore 64 bit is enough!! If so, then your solution "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.” looks good. For that, should each tasking model implement an interface which converts chpl_taskID to something like int64_t?
Thank you Sriraj > On Jan 4, 2017, at 12:24 AM, Greg Titus <[email protected]> wrote: > > 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
