Brad, Thanks very much for the info. Let me think about this. I didn’t know about the custom indexing functions.
I don’t have a compelling case to suggest any language changes. But let me think about that as well. - Apan > On Jul 7, 2017, at 2:07 PM, Brad Chamberlain <[email protected]> wrote: > > > Hi Apan -- > > I'm happy that you're thinking about this challenge, as it's a longstanding > one that users bring up and one for which we've kicked ideas around, yet > without any ideal solution yet. > >> My question is, is there a way to determine which field is being requested >> in an AoS reference (A[i].x) from within the domain map code? > > Unfortunately not -- because the domain map code is only implementing the > array itself, it can only get the [i] access as an argument and know that the > element type is a(n apparent) record. > > I'll mention that when this challenge was first levelled at us (by some > potential Chapel users from DOE labs), I proposed a domain map-based > solution, albeit possibly one different than the one you are pursuing. I'd > imagined having the domain map be parameterized by the number/type of > elements in the fields and having it pre-allocate the data for them. I recall > that there was something about this solution that they found off-putting, but > can't quite recall what it was -- it seems like it was related to an extra > indirection or multiplication, but I can't reconstruct the conversation just > now. > > From there, my thoughts turned to approaches that would rely on the facts > that Chapel types can (1) implement their own indexing functions and (2) > support methods that omit parenthesis to get pseudo-fields. That is: > > ----- > record R { > proc this(i: real) { > return 2*i; > } > > proc x { > return 3.14; > } > } > > var myR: R; > > writeln(R[2.4]); > writeln(R.x); > ----- > > > The last time I was kicking this problem around, I was wondering whether > creating a record/class that wrapped an array, or group of arrays, could lean > on these mechanisms to provide AoS vs. SoA transparency. Offhand, I can't > recall whether I got stymied or never spent the time on it to see it through. > > > I'll also mention that I'm (personally) open to modifying the language to > "solve" the AoS vs. SoA challenge, though I'm hesitant to take the approach > of giving domain maps more context for the expression that follows the > indexing expression as you were asking about, at least on the surface (but > perhaps could be convinced, given a strong enough proposal and rationale). > > -Brad > > > > > On Fri, 7 Jul 2017, Qasem, Apan M wrote: > >> Hello, >> >> I am implementing data layout transformations in Chapel that favor >> GPU/heterogenous memory hierarchy. >> >> One of the transformations I am looking at is the AoS-to-SoA conversion >> (critical for heterogenous applications). I am hoping to implement this >> using a domain map. For example, >> >> var N = 1..100; >> >> record img { >> var r: int; >> var g: int; >> var b: int; >> var x: int; >> } >> >> var domAoS : domain(1) = {N}; >> var domSoA : domain(1) dmapped SoA() = {N}; >> >> var A : [domAoS] img; >> var B : [domSoA] img; >> >> A[3].g = 17; // A accessed as AoS >> B[3].g = 17; // B accessed as SoA >> >> >> I have a partial implementation where I am able to map an AoS index to an >> SoA index in the SoA() domain map (as long as the field access information >> is hard coded in the module code). >> >> My question is, is there a way to determine which field is being requested >> in an AoS reference (A[i].x) from within the domain map code? >> >> - Apan >> >> Apan Qasem, PhD >> Visiting Scholar, AMD Research >> Associate Professor, Dept of Computer Science >> Texas State University >> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.txstate.edu%2F~aq10&data=01%7C01%7Capan%40txstate.edu%7Cc1cc54ce75b9465881cb08d4c56b607e%7Cb19c134a14c94d4caf65c420f94c8cbb%7C0&sdata=eHt9DN6FzPUpxNNY66v%2FKEEmvO6draXz9m6I7Vte8Ro%3D&reserved=0 >> >> ------------------------------------------------------------------------------ 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
