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
