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
