Date: Tue, 24 Aug 2021 16:58:51 -0400
Agreed.
> On Aug 24, 2021, at 4:57 PM, Hans Boehm via SG5 <sg5_at_[hidden]> wrote:
>
> I'm entirely fine with that.
>
> The down side is of course that you might be invoking an inner product function on a 3 element vector, and it uses parallel unsequenced algorithms underneath because it's designed to work for a billion elements as well, and expects the implementation to ignore that for three elements. But I agree that it's more important for now to not require implementers to deal with that.
>
> Hans
>
> On Tue, Aug 24, 2021 at 12:55 PM Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
> On 24/08/2021 20.16, Hans Boehm via SG5 wrote:
> > My attempt to draft the response to Hubert's first point, and looking back at old minutes, raised a new pair of questions:
> >
> > We currently require the full algorithms library, including the parallel variants, to be supported in transactions. Was that intentional? (Not a rhetorical question. I think there are arguments either way.) Note that parallel algorithms are allowed to be executed serially; they officially just add requirements to user code, making them safe to vectorize and/or parallelize.
> >
> > If we do require them, then this seems like a case in which a nontrivial implementation may need something like in_transaction() to avoid thread-level parallelism. But I think many simple implementations, including HTM with SGL fallback will still not need it; just falling back to a single global lock held by the main thread running the algorithm should still work, even with thread-level parallelism. So I think we should still not require it (assuming we allow parallel algorithms). Does this make sense to everybody?
>
> I think we should simply add the parallel algorithms to the "forbidden" list.
> Given that transactions are intended to be "small" and "quick", there is no
> need to consider invoking an algorithm that might benefit from multi-thread
> execution.
>
> Jens
>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
> On Aug 24, 2021, at 4:57 PM, Hans Boehm via SG5 <sg5_at_[hidden]> wrote:
>
> I'm entirely fine with that.
>
> The down side is of course that you might be invoking an inner product function on a 3 element vector, and it uses parallel unsequenced algorithms underneath because it's designed to work for a billion elements as well, and expects the implementation to ignore that for three elements. But I agree that it's more important for now to not require implementers to deal with that.
>
> Hans
>
> On Tue, Aug 24, 2021 at 12:55 PM Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
> On 24/08/2021 20.16, Hans Boehm via SG5 wrote:
> > My attempt to draft the response to Hubert's first point, and looking back at old minutes, raised a new pair of questions:
> >
> > We currently require the full algorithms library, including the parallel variants, to be supported in transactions. Was that intentional? (Not a rhetorical question. I think there are arguments either way.) Note that parallel algorithms are allowed to be executed serially; they officially just add requirements to user code, making them safe to vectorize and/or parallelize.
> >
> > If we do require them, then this seems like a case in which a nontrivial implementation may need something like in_transaction() to avoid thread-level parallelism. But I think many simple implementations, including HTM with SGL fallback will still not need it; just falling back to a single global lock held by the main thread running the algorithm should still work, even with thread-level parallelism. So I think we should still not require it (assuming we allow parallel algorithms). Does this make sense to everybody?
>
> I think we should simply add the parallel algorithms to the "forbidden" list.
> Given that transactions are intended to be "small" and "quick", there is no
> need to consider invoking an algorithm that might benefit from multi-thread
> execution.
>
> Jens
>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
Received on 2021-08-24 15:58:58