-
-
Notifications
You must be signed in to change notification settings - Fork 430
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
Implement parallel::unique. #2867
Conversation
…es of parallel::unique.
Original way: allocating temporary storage and utilizing out-place version. New way: perform f3 sequentially. See also: STEllAR-GROUP#2804
1. Remove non-meaning codes. 2. Exchange the order of codes of parallel::unique and parallel::unique_copy.
https://github.com/taeguk/hpx/blob/da7fd5d7dd38ca0074c579d248ef7ea916c200bf/hpx/parallel/util/scan_partitioner.hpp#L284-L289 How do you think about it? Keep using current explicit waiting? Or use |
Please fix the conflicts, otherwise this can't go ahead. |
…_async for fixing a bug when parallel_task_policy is used. The bug : static_scan_partitioner doesn't work as async when parallel_task_policy is used. The reason : because of ```finalitems.back().wait();``` when scan_partitioner_sequential_f3_tag is used as ScanPartTag. How to fix : Use static_scan_partitioner_helper which returns R instead of hpx::future<R>.
…allel::util::scan_partitioner.
@hkaiser I'm ready to be reviewed and merged. |
@taeguk Please fix the conflicts for this to be merged. And sorry for the long delay ... |
@taeguk: thanks a lot for your continued work on this! Just a heads up - there are still problems reported by inspect. |
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 a lot!
It is related to #1141, #2804.
Check Box
Issues
-> I implemented both ways and benchmarked them. In conclusion, using the way to perform f3 sequentially is better. So, I choosed that.
Note for future