Thank you Greg!!! That is the Ideal solution for me. Sriraj > On Jan 4, 2017, at 10:27 PM, Greg Titus <[email protected]> wrote: > > Actually, given Sriraj’s latest response I’ve come around to the other point > of view. > > Let’s separate the issues of the internal and the external task ID > representation. Even if the internal representation is a plain 64-bit int > defined independently from the implementations, defining a > chpl_task_sameIDs() to compare task IDs is a good idea so that the rest of > the code isn’t dependent on that internal type. That’s just good interface > engineering practice. > > Then, no matter what the internal representation is, only the implementations > can provide a reasonable chpl_task_idToString() conversion function to > produce the external representation, because only the implementations can > decode or unpack encoded internal IDs. For example, if the encoded form has > 16 high-order bits of node ID and 48 low-order bits of task ID within node, > if some ID has node==1 and task_within_node==2 clearly it’s better to print > “1:2” rather than the raw value “281474976710658" or “0x100000002” an > implementation independent convertor would produce. > > Given that we need chpl_task_sameIDs() and chpl_task_idToString() anyway, I > believe we should continue to have the implementations define the task ID > type, so they can use whatever is convenient for them, and then require them > to provide those two functions (and adjust to using those in qio and chplvis > and elsewhere as needed). > > greg > > >> On Jan 4, 2017, at 8:08 AM, Michael Ferguson <[email protected]> wrote: >> >> Hi - >> >> On 1/4/17, 7:24 AM, "sri raj paul" <[email protected]> wrote: >> >>> 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? >> >> If we did what Greg is proposing - at least as I understand it - >> we would have a single definition for chpl_taskID in chpl-tasks.h >> like this: >> >> typedef int64_t chpl_taskID; >> >> You need to tell us if you can work with that with OCR. Of course, >> even if we don't make that change now, you could get started on >> having OCR use an int64_t for the chpl_taskID now. (Which if I >> understand correctly it was already doing - but newer OCRs >> change some OCR type to be 128-bits - so we're really just saying >> "try harder to make the Chapel task ID 64-bits"). >> >> Thanks, and let us know if that's a workable solution or if we >> need to discuss it further. >> >> -michael >> >>> >>> 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 >
------------------------------------------------------------------------------ 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
