And Michael P. Ferguson writes: > Can you explain why the existing atomics interface in > Atomics.chpl is not sufficient?
Sorry, left out the context in my hurry. There are many sparse matrix / graph operations that work in the space of the output and can be parallelized easily (with natural performance caveats) using atomic operations. Currently the target of atomic operations has to be wrapped in a type, either the classes in Atomics.chpl or the atomic type modifier (as far as I understand). That requires copying large arrays out of the atomic type into the typical type, defeating the nice same-space property. Mine ignores the standards committee politics and just uses atomic operations on plain types. Yes, there are platforms where different combinations may not work (e.g. atomic add on a 16-bit int), but the common 64-bit case likely always will. The missing combinations for a platform can be left as unavailable methods. (Although being able to add to the compiler's error message might be nice...) Or am I mis-reading Atomics.chpl? > The Atomics module mostly adds an 'on' statement around these > calls. I also am intentionally punting on remote atomics by wrapping in local. I don't see an easy way to support using, say, aries or torrent remote ops *and* simple local intrinsics depending on the context. And Jeff Hammond writes: > As far as an implementation of atomics on PPC goes, I recommend > starting with GCC intrinsics, as these are also supported by IBM > XLC. IBM pretty much supports every combination of everything if you find the right flags, but at least one Power7 box I was using didn't support the gcc intrinsics without magic extra compiler flags. I'd rather not rely on Chapel being compiled with those. Also, I suspect they support the __sync intrinsics. Besides, that part of the code is more a sanity check of how to support multiple platforms in Chapel without CPP-ish macros or Lisp-ish #+ bits. Somewhat conflating issues, but Chapel needs some way to cope with platform-specific oddities. Param functions that check seem a sane path for simpler cases. But I also haven't checked the LLVM back-end to see if symbols in other platforms' branches appear as unresolved. -- Jason Riedy ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
