> > 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
