Who needs and wants parallelism-friendly core libs?
ekmett at gmail.com
Thu Nov 21 16:29:15 UTC 2013
Actually, the Primitive.Vector constructor should be irrelevant. Nevermind.
It is the mutable one you need and that one is public.
On Thu, Nov 21, 2013 at 11:11 AM, Edward Kmett <ekmett at gmail.com> wrote:
> I'd like to hash this out a bit further. As this issue affects vector primarily,
> it is outside of the scope of the core library committee per se, and is
> largely up to Roman as the maintainer of vector.
> That said if I put on my personal and not my 'committee' hat:
> I would use these operations, personally, were they available to me.
> The question is how to best expose them from an API perspective.
> Vector currently exposes enough (or at least almost enough) of the
> implementation details that such support could be implemented 'out-of-line'
> from the main library. (I think the Data.Vector.Primitive constructor is
> currently not exported, and you'd need that.)
> I don't *think* Roman would object too strenuously to exporting it though
> and I've personally wanted it for other reasons. This would open the door
> to this sort of thing being something you might supply entirely outside of
> the library, giving the final placement of the code some flexibility.
> You could handle CAS operations for Primitive and boxed Vectors pretty
> easily at least, leaving off Unboxed and my various hybrid vector
> approaches as they are intrinsically tied to working on multiple underlying
> source vectors.
> I'm pretty open to ideas about where the instances should live though. One
> argument for putting it in vector is you could extend Prim with the CAS
> operations directly rather than subclass it. An argument against is it
> could then iterate on a more flexible time table.
> On Thu, Nov 21, 2013 at 10:30 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>> [Popping up to the big-picture question for a moment, from the previous
>> thread on Vector CAS.]
>> Given that a lot of people are really advertising Haskell on the
>> parallel/concurrent front, it seems like we *should* be committed as a
>> community to making our basic libraries support parallel/concurrent use
>> cases effectively. This will necessarily mean touching some core libraries
>> (container, vector...).
>> The two things that have come up for me recently are (1) CAS/RMW on
>> [unboxed] Vectors and a general notion of balanced-splitting for tree-based
>> structures (Map,Set). But I'm sure there are others!
>> Is any one else invested in getting this kind of thing moving? It would
>> be great to have a partner. I can commit a small amount of cycles, but I
>> don't have lots of bandwidth for non-research infrastructure work
>> presently. Edward, is any of this useful to you?
>> In many of these cases it seems like the main problem is not a technical
>> one, but the social one of consensus building (and fighting excessive "stop
>> energy" if it appears). Edward, as chair of the core libraries committee,
>> maybe you could help with this?
>> On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>> [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS
>>> business too. (I thought that was just Repa & Accelerate.)
>>> In any case, an unboxed vector of tuples can't *actually* support
>>> atomic CAS anyway, so not supporting it is inevitable.
>>> It does mean that exposeMutableByteArray can't be a method of the
>>> Unbox class. It would need to be another class capturing the subset of
>>> vector types that are "Atomic" (support concurrent/atomic memory ops).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries