Hi Michael, True. "typedef int64_t chpl_taskID" is not giving anything new.
I will have to read the integer field from the OCR ID struct for storing to chpl_taskID. When I want to use a chpl_taskID, I will have to create a OCR ID variable and fill its field with chpl_taskID’s value. That is a workable solution for me. Still if possible, I prefer to use the OCR ID directly :) Thank you Sriraj > On Jan 4, 2017, at 8:38 PM, 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
