-
-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implemented segmented algorithms for partitioned vector #2725
Conversation
Tasks completed as part of GSoC project - - Moved unit tests for segmented algorithms from component to parallel/segmented_algorithms - Implemented segmented for_each_n using existing segmented for_each along with test - Implemented segmented unary transform along with test - Implemented 2 versions of segmented binary transform with 4 and 5 iterators as parameters along with tests for both - Implemented segmented reduce along with test - Implemented segmented transform_inclusive/exclusive_scan by modifying existing inclusive/exculsive_scan to accept one more default parameter (unary operator) as input, along with tests both - modified dispatch in both algorithms/detail and segmented_algorithms/detail to add helper functions for output inference and casting See: #1338
commit 1c28b70 Author: Ajai V George <[email protected]> Date: Wed Jun 21 18:50:46 2017 +0530 Updated tests for other algorithms for multiple localities commit 16a3660 Author: Ajai V George <[email protected]> Date: Wed Jun 21 18:25:42 2017 +0530 Updated tests for for_each to run on multiple localities
Updated file headers with last updated date and also changed the copyright for new files
Fixed 5 Inspect errors related to missing includes
…lgorithms merge error
hpx/include/parallel_for_each.hpp
Outdated
#if !defined(HPX_PARALLEL_FOREACH_JUN_28_2014_0827AM) | ||
#define HPX_PARALLEL_FOREACH_JUN_28_2014_0827AM | ||
#if !defined(HPX_PARALLEL_FOREACH_JUN_21_2017_0827AM) | ||
#define HPX_PARALLEL_FOREACH_JUN_21_2017_0827AM | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's simply a misunderstanding between me and the student. I told him to modify include guards but I meant only files he has created.
@ajaivgeorge could you revert those changes in files which have not been created by you?
hpx/include/parallel_reduce.hpp
Outdated
#if !defined(HPX_PARALLEL_REDUCE_JUN_28_2014_0827AM) | ||
#define HPX_PARALLEL_REDUCE_JUN_28_2014_0827AM | ||
#if !defined(HPX_PARALLEL_REDUCE_JUN_21_2017_0827AM) | ||
#define HPX_PARALLEL_REDUCE_JUN_21_2017_0827AM | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
@@ -18,7 +18,7 @@ | |||
#include <hpx/parallel/executors/execution.hpp> | |||
#include <hpx/parallel/util/detail/algorithm_result.hpp> | |||
#include <hpx/parallel/util/detail/scoped_executor_parameters.hpp> | |||
|
|||
#include <hpx/util/tuple.hpp> | |||
#include <string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep an empty line between the HPX headers and the std headers. This prevents clang-format from sorting those two groups of headers files into one block.
hpx/include/parallel_transform.hpp
Outdated
#if !defined(HPX_PARALLEL_TRANSFORM_JUN_28_2014_0827AM) | ||
#define HPX_PARALLEL_TRANSFORM_JUN_28_2014_0827AM | ||
#if !defined(HPX_PARALLEL_TRANSFORM_JUN_21_2017_0827AM) | ||
#define HPX_PARALLEL_TRANSFORM_JUN_21_2017_0827AM | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to modify the include guards on every edit.
hpx/parallel/algorithms/for_each.hpp
Outdated
std::true_type, Proj && proj = Proj()) | ||
{ | ||
auto last = first; | ||
detail::advance(last,std::size_t(count)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please try to conform to our code formatting style. In particular we normally place a space after commas separating arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment applies to many spots in the code, btw. Clang-format will help with that as well (at least for the files you created).
hpx/parallel/algorithms/for_each.hpp
Outdated
@@ -463,7 +510,7 @@ namespace hpx { namespace parallel { inline namespace v1 | |||
> | |||
typename util::detail::algorithm_result<ExPolicy, InIter>::type | |||
for_each(ExPolicy && policy, InIter first, InIter last, F && f, | |||
Proj && proj = Proj()) | |||
Proj && proj) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you remove the default argument value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for_each is forward declared above, so no default argument here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I missed that. Sorry.
T const& init, Op && op, std::true_type); | ||
inclusive_scan_(ExPolicy&& policy, InIter first, InIter last, OutIter | ||
dest, T const& init, Op && op, std::true_type, Conv && conv = | ||
Conv()); | ||
/// \endcond |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please try not to separate argument type and argument name onto different lines.
@@ -17,6 +17,8 @@ | |||
#include <hpx/parallel/execution_policy.hpp> | |||
#include <hpx/parallel/util/detail/algorithm_result.hpp> | |||
#include <hpx/parallel/util/detail/handle_remote_exceptions.hpp> | |||
#include <hpx/util/tuple.hpp> | |||
#include <exception> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This header is duplicated.
Updated the Iterator Types from InIter and OutIter to FwdIter Conflicts: hpx/parallel/algorithms/exclusive_scan.hpp hpx/parallel/algorithms/for_each.hpp hpx/parallel/algorithms/inclusive_scan.hpp hpx/parallel/algorithms/reduce.hpp hpx/parallel/algorithms/transform.hpp hpx/parallel/algorithms/transform_exclusive_scan.hpp hpx/parallel/algorithms/transform_inclusive_scan.hpp tests/unit/parallel/segmented_algorithms/partitioned_vector_transform_reduce.cpp
@ajaivgeorge Have you fixed the issue with ctest and verified that all tests are passing on multiple localities? |
@mcopik, yes (going by the CI test below). I have modified the CMakeLists file in the segmented_algorithms test folder. Please check that. I am no longer trusting the results from my laptop. Running on Rostam right now. |
@mcopik, Only, transform fails on rostam. I forgot that CI wasn't running the tests. I will fix this first and then get back to find_end/first_of. Are you sure find test fails? I ran it on rostam and there was no SegFault. Find end failed as expected. |
@mcopik Errors have been fixed. Please review. |
Is this ready to be reviewed now? |
@hkaiser Yes it is ready to be reviewed. |
#if !defined(HPX_PARALLEL_ALGORITHM_EXCLUSIVE_SCAN_DEC_30_2014_1236PM) | ||
#define HPX_PARALLEL_ALGORITHM_EXCLUSIVE_SCAN_DEC_30_2014_1236PM | ||
#if !defined(HPX_PARALLEL_ALGORITHM_EXCLUSIVE_SCAN_JUN_21_2017_1236PM) | ||
#define HPX_PARALLEL_ALGORITHM_EXCLUSIVE_SCAN_JUN_21_2017_1236PM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to change the include guards.
{ | ||
T part_init = get<0>(*part_begin++); | ||
T part_init = hpx::util::invoke(conv, get<0>(*part_begin++)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This additionally requires a check whether part_begin
has not reached the end after the increment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what the lambda should return if part_begin has reached the end. The only scenario where that happens is if there is a partition with two elements. I looked at an example from algorithms/reduce.hpp L72, and even here there is no such check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should return part_init
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at an example from algorithms/reduce.hpp L72, and even here there is no such check.
There it is not a problem as part_size
would drop to zero, thus avoiding to dereference the iterator produced by ++part_begin
inside accumulate_n
.
#if !defined(HPX_PARALLEL_ALGORITHM_INCLUSIVE_SCAN_JAN_03_2015_0136PM) | ||
#define HPX_PARALLEL_ALGORITHM_INCLUSIVE_SCAN_JAN_03_2015_0136PM | ||
#if !defined(HPX_PARALLEL_ALGORITHM_INCLUSIVE_SCAN_JUN_21_2017_0136PM) | ||
#define HPX_PARALLEL_ALGORITHM_INCLUSIVE_SCAN_JUN_21_2017_0136PM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to change the include guards.
{ | ||
T part_init = get<0>(*part_begin); | ||
T part_init = hpx::util::invoke(conv, get<0>(*part_begin)); | ||
get<1>(*part_begin++) = part_init; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This requires an additional check that part_begin
has not reached the end after the increment.
(hpx::traits::is_forward_iterator<FwdIter1>::value), | ||
"Requires at least forward iterator."); | ||
static_assert( | ||
(hpx::traits::is_input_iterator<FwdIter2>::value), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this check for forward_iterator_tag
instead?
}, | ||
hpx::util::unwrapped([r](std::vector<T> && results) | ||
{ | ||
auto rfirst = std::begin(results); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use hpx::util::begin
/hpx::util::end
instead of the standard versions.
@@ -637,14 +651,14 @@ namespace hpx { namespace parallel { inline namespace v1 | |||
hpx::dataflow( | |||
policy.executor(), | |||
hpx::util::unwrapped( | |||
[=, &op](T last_value, T) | |||
[=, &op, &conv](T last_value, T) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add an explicit return type to this lambda.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The return of segmented_scan_void function object is hpx::util::unused. Should this be the return of he lambda or should it be blank for void?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lambda returns void
.
typedef util::detail::algorithm_result<ExPolicy, | ||
hpx::util::tagged_tuple< | ||
tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> | ||
> result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, the indentation is confusing, I see this now.
typedef util::detail::algorithm_result<ExPolicy, | ||
hpx::util::tagged_tuple< | ||
tag::in1(InIter1), tag::in2(InIter2), tag::out(OutIter)> | ||
> result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, strange indentation...
hpx/parallel/util/loop.hpp
Outdated
{ | ||
val = hpx::util::invoke(r, val, *iter); | ||
iter++; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stray semicolon, also - why don't you use first
for the iteration?
@ajaivgeorge Overall, very nice job - thanks for your effort! |
@ajaivgeorge I don't see any other problems besides those mentioned by Hartmut already. For the scan, it makes sense to verify if @hkaiser can we enforce a CI build on AppVeyor? It seems it failed due to a network problem. |
AppVeyor seems to have problems to pull from repository forks... I can try rebuilding, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
@mcopik: are you fine with going ahead and merging this? |
@hkaiser Yes, let's do it :) |
@ajaivgeorge, @mcopik: two of the new tests are failing in distributed runs, see here for an example: http://rostam.cct.lsu.edu/builders/hpx_gcc_4_9_4_boost_1_56_centos_x86_64_release/builds/126/steps/run_unit_tests/logs/stdio Could you fix those asap, please? |
@ajaivgeorge, congratulations on your commit to HPX. Once you get the Buildbot issues sorted out, contact me so that we can send you a T-Shirt |
@hkaiser @mcopik, The error has been fixed in my master branch. The issue was with the util/loop accumulate function that I added. During the PR review when i changed from using a temp iterator to using first iterator directly i forgot to add a ++first. Hadn't run the test after this change. I have tested the algorithm upto localities=5. The other algorithms like transform_scan test and for_each and transform also work for localities > 2. But the following tests fail for localities > 2
These might be failing because the tests are designed for localities=2 (especially the extensive tests for the scans) or because of something fundamental with the algorithm. I will look into this once I am done with the find algorithms. |
@ajaivgeorge: please create a new PR for the algorithm fixes. |
Tasks completed as part of GSoC project (See: #1338) -
parallel/segmented_algorithms
iterators as arguments
modifying existing inclusive/exculsive_scan to accept one more
default parameter (unary operator) as input
segmented_algorithms/detail to add helper functions for output type
inference and casting
All algorithms have associated passing tests in the unit/parallel/segmented_algorithms folder.
Inspect shows 0 errors
This branch has been updated with the almost latest hpx/master and only one test unrelated to my code fails (68 - tests.regressions.lcos_dir.wait_for_1751), which has been fixed in later commits.