Who needs and wants parallelism-friendly core libs?

[Edward Kmett]

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.
>
> -Edward
>
>
> 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?
>>
>> Cheers,
>>   -Ryan
>>
>>
>> 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...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131121/8eaa92dd/attachment-0001.html>