On Aug 24, 2021, at 4:57 PM, Hans Boehm via SG5 <sg5@lists.isocpp.org> 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@gmx.net> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg5