Uninitialised algorithms, move using std::memcpy

[Johan511]

In case of triviably copyable types we copy using std::memcpy. Performance improvement is almost 10x

[StellarBot]

Performance test report

HPX Performance

Comparison

BENCHMARK	FORK_JOIN_EXECUTOR	PARALLEL_EXECUTOR	SCHEDULER_EXECUTOR
For Each	(=)	??	(=)

Info

Property	Before	After
HPX Commit	dcb5415	cea04ba
HPX Datetime	2023-05-10T12:07:53+00:00	2023-06-04T18:53:34+00:00
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Envfile
Datetime	2023-05-10T14:50:18.616050-05:00	2023-06-04T14:00:18.258564-05:00
Clustername	rostam	rostam

Comparison

BENCHMARK	NO-EXECUTOR
Future Overhead - Create Thread Hierarchical - Latch	-

Info

Property	Before	After
HPX Commit	dcb5415	cea04ba
HPX Datetime	2023-05-10T12:07:53+00:00	2023-06-04T18:53:34+00:00
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Envfile
Datetime	2023-05-10T14:52:35.047119-05:00	2023-06-04T14:02:36.669467-05:00
Clustername	rostam	rostam

Comparison

BENCHMARK	FORK_JOIN_EXECUTOR_DEFAULT_FORK_JOIN_POLICY_ALLOCATOR	PARALLEL_EXECUTOR_DEFAULT_PARALLEL_POLICY_ALLOCATOR	SCHEDULER_EXECUTOR_DEFAULT_SCHEDULER_EXECUTOR_ALLOCATOR
Stream Benchmark - Add	(=)	=	(=)
Stream Benchmark - Scale	(=)	=	(=)
Stream Benchmark - Triad	(=)	=	(=)
Stream Benchmark - Copy	(=)	(=)	=

Info

Property	Before	After
HPX Commit	dcb5415	cea04ba
HPX Datetime	2023-05-10T12:07:53+00:00	2023-06-04T18:53:34+00:00
Hostname	medusa08.rostam.cct.lsu.edu	medusa08.rostam.cct.lsu.edu
Compiler	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1	/opt/apps/llvm/13.0.1/bin/clang++ 13.0.1
Envfile
Datetime	2023-05-10T14:52:52.237641-05:00	2023-06-04T14:02:53.869239-05:00
Clustername	rostam	rostam

Explanation of Symbols

Symbol	MEANING
=	No performance change (confidence interval within ±1%)
(=)	Probably no performance change (confidence interval within ±2%)
(+)/(-)	Very small performance improvement/degradation (≤1%)
+/-	Small performance improvement/degradation (≤5%)
++/--	Large performance improvement/degradation (≤10%)
+++/---	Very large performance improvement/degradation (>10%)
?	Probably no change, but quite large uncertainty (confidence interval with ±5%)
??	Unclear result, very large uncertainty (±10%)
???	Something unexpected…

[hkaiser]

Can you replace all the try { /* do loop */ } catch(...) { /*cleanup */} with loop_with_cleanup?

[Johan511]

@hkaiser requested changes have been made, only existing try-catch blocks are in loop_with_cleanup* functions

[Johan511]

@hkaiser can you clarify what does HPX_COMPUTE_DEVICE_CODE signify over here

hpx/libs/core/algorithms/include/hpx/parallel/util/loop.hpp

Lines 129 to 148 in 15e8964

	#if !defined(HPX_COMPUTE_DEVICE_CODE)
	inline constexpr loop_t loop = loop_t{};
	#else
	template <typename ExPolicy, typename Begin, typename End, typename F>
	HPX_HOST_DEVICE HPX_FORCEINLINE constexpr Begin loop(
	ExPolicy&& policy, Begin begin, End end, F&& f)
	{
	return hpx::parallel::util::loop_t{}(
	HPX_FORWARD(ExPolicy, policy), begin, end, HPX_FORWARD(F, f));
	}
	template <typename ExPolicy, typename Begin, typename End,
	typename CancelToken, typename F>
	HPX_HOST_DEVICE HPX_FORCEINLINE constexpr Begin loop(
	ExPolicy&& policy, Begin begin, End end, CancelToken& tok, F&& f)
	{
	return hpx::parallel::util::loop_t{}(
	HPX_FORWARD(ExPolicy, policy), begin, end, tok, HPX_FORWARD(F, f));
	}
	#endif

[hkaiser]

@Johan511 The code in question fails compiling when using nvcc. The #else case adds a workaround. Both cases are functionally equivalent.

[hkaiser]

This looks better now. One question, though: you seem to have removed the cancellation tokens altogether. Can you explain the rationale for doing so, please?

[Johan511]

@hkaiser can you please point out to the lines you are referring to? In most places I have tried not to change the implementations much.

In some cases where I wrote a function which calls loop_with_cleanup, I have used the loop without any cancellation tokens, I don't see a point to cancellation tokens in this context as the only case we end the loop prematurely is when an error is thrown. This is taken case by try-catch and I don't believe it needs any token.

Is there something I am missing or would you suggest I do away with tokens completely?

[hkaiser]

@hkaiser can you please point out to the lines you are referring to? In most places I have tried not to change the implementations much.

In some cases where I wrote a function which calls loop_with_cleanup, I have used the loop without any cancellation tokens, I don't see a point to cancellation tokens in this context as the only case we end the loop prematurely is when an error is thrown. This is taken case by try-catch and I don't believe it needs any token.

Is there something I am missing or would you suggest I do away with tokens completely?

So I guess your rationale of removing the cancellation tokens was that those would matter only in case of errors. That means we were slowing down the success path in order to speed up the error path. I agree to remove them in this case.

[Johan511]

That means we were slowing down the success path in order to speed up the error path.

loop_with_cleanup was checking for tok only at the start.

Not sure how having tok was speeding up the error path, we were still throwing the error not doing cleanup with token.

[hkaiser]

That means we were slowing down the success path in order to speed up the error path.

loop_with_cleanup was checking for tok only at the start.

Not sure how having tok was speeding up the error path, we were still throwing the error not doing cleanup with token.

The token was used to stop doing work on the partitions that were not erroneous.

[Johan511]

The token was used to stop doing work on the partitions that were not erroneous.

We don't seem to explicitly cancel the token in the catch block.
Ref.

[hkaiser]

The token was used to stop doing work on the partitions that were not erroneous.

We don't seem to explicitly cancel the token in the catch block. Ref.

As I said, I'm fine with removing the token if we were using it just to speed up the error path without helping the success path.

[hkaiser]

Let's get this in now. Thanks a lot!

[hkaiser]

bors merge

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Bors

[Johan511]

Performance numbers for uninit-copy