Google Summer of Code (GSoC) 2020 - STEllAR-GROUP/hpx GitHub Wiki

Welcome to the Google Summer of Code (GSoC) page for the HPX project. Here you can find information about student projects, proposal submission templates, advice on writing good proposals, and links to information on getting started with HPX. The STE||AR Group will apply as an organization and our goal is to have at least five funded students working on HPX related projects.

Students must submit a proposal. A template for the proposal can be found here. Hints for writing a good proposal can be found here.

We strongly suggest that students interested in developing a proposal for HPX discuss their ideas on the IRC channel or the mailing list in order to help refine the requirements and goals. For information on how to access IRC or the mailing list please see this page. Students who actively plan and discuss projects with developers are generally ranked before those that do not.

If the descriptions of these projects seem a little vague... Well, that is intentional. We are looking for students to develop requirements for their proposals by doing initial background research on the topic, and interacting with the community. In addition, it is important to note that the suggested projects on this page are not binding - if you have an interest in parallel task-based programming and have an idea for a project that would either improve HPX or demonstrate how well it can be applied to your problem, then feel free to suggest your idea as a project and write a proposal for it. We will be glad to help you with project goals to improve your proposal if you have ideas and do not leave them until the last minute.

We will expect students to demonstrate that they have the required level of C++ and CMake knowledge by showing us some of their previous work (e.g. a github repository), or preferably, by them making a small demonstration program using HPX that shows a simple example of something they have created themselves.

New projects for this year, or ones revamped from previous years that are still of interest. These projects have mentors ready and waiting to help students with.

These are projects that involve making changes/improvements/extensions to the core HPX library

• Add Vectorization to the par_unseq Implementations of the Parallel Algorithms
• Concurrent Data Structure Support
• Create Generic Histogram Performance Counter
• Parallel Algorithms and Ranges
• Range based Parallel Algorithms
• Implement missing Parallel Algorithms
• Conflict (range-based) Locks
• ROCm backend for HPX.Compute

These are project that improve code that uses HPX. In general the primary goal with these projects is to improve user uptake of HPX by demonstrating its use in other projects and only minor fixes/changes/extensions should be necessary in the main HPX library itself.

• Task Bench: A Parameterized Benchmark for Evaluating Parallel Runtime Performance
• Domain decomposition and load balancing for a crack and fracture mechanics code
• UI Improvements for Performance Visualization
• Charting Support for HPX OTF2 Trace Visualization
• Large File Support for HPX OTF2 Trace Visualization
• Test Framework for Phylanx Algorithms
• Providing a pip package for Phylanx
• Optimizer implementation for Phylanx
• Working on Blaze Tensor

These are project ideas from previous Summer of Code years that we are still interested in working on, but it might be harder to find a mentor willing to supervise a student. We would therefore expect only very self motivated and capable students to select a project from the legacy category and we cannot guarantee that we will select a project from this list unless we are quite satisfied that the student is capable of completing the work.

• Add Mask Move/Assign Wrappers for Vectorization Intrinsics
• Implement Your Favorite Parcelport Backend
• Implement A Faster Associative Container for GIDs
• Port HPX to iOS
• Create A Parcelport Based on WebSockets
• Script Language Bindings
• All to All Communications
• Distributed Component Placement
• Resumable Function Implementation
• Coroutine-like Interface
• Port Graph500 to HPX
• Port Mantevo MiniApps to HPX
• Create an HPX Communicator for Trilinos Project
• Add More Arithmetic Performance Counters
• Add More Iterative Solvers in Phylanx
• Project Template
• Bug Hunter

We are looking to fund work on a number of different kinds of proposals (for more details about concrete project ideas, see below):

• Extensions to existing library features,
• New distributed data structures and algorithms
• Multiple competing proposals for the same project

• Abstract: Phylanx is a platform for computations on distributed arrays for applied statistics and machine learning on cloud systems. Currently, it has optimized implementations for some algorithms. The idea of this project is to apply one of the ALS (Alternating Least Squares), LDA (Latent Dirichlet Allocation) or k-means clustering algorithms on a real-world dataset to make a real-world application (which is not implemented before). You can find a dataset on Kaggle or use any desired open dataset.
• Difficulty: Easy-Medium
• Expected result: An integrated Phylanx test for one of the mentioned algorithms on a real-world dataset
• Knowledge Prerequisite: Basic knowledge of Data Science, Python, and C++
• Mentor: Bita Hasheminezhad ()

• Abstract: In Phylanx we have implemented a set of iterative linear system solvers intended for use, including conjugate gradient (CG), preconditioned CG, BiCGSTAB, preconditioned BiCGSTAB, Arnoldi, Lanczos, and GMRES with the blaze library, a high-performance C++ linear algebra library. For this project, a student can implement more iterative solvers. See BlazeIterative for more information on the existing solvers.
• Difficulty: Easy-Medium
• Expected result: Implement at least one solver
• Knowledge Prerequisite: C++
• Mentor: Nanmiao Wu () and Patrick Diehl ()

• Abstract: Phylanx relies on many external libraries which makes the building process tedious and error prone, especially to the target audience of the software- domain scientist. The goal of this project is to automate the build process of Phylanx by creating a distribution package. The distribution package should build and install Phylanx and its requirements through Python's pip package manager.
• Difficulty: Easy-Medium
• Expected result: Phylanx can be installed with pip
• Knowledge Prerequisite: Python, CMake
• Mentor: Patrick Diehl ()

• Abstract: The aim of this project is to add HPX to the suite of runtimes examined in the [Task Bench: A Parameterized Benchmark for Evaluating Parallel Runtime Performance](paper https://arxiv.org/abs/1908.05790). A comparison of HPX with other runtimes is useful for our own benchmarking to see how well we compare to other runtimes, and it is also useful for publicity and attracting users if the numbers show that HPX performs well. This project has an issue on github. The student should not only integrate HPX into the benchmarking suite, but ideally, should create a "Superproject" capable of downloading, building, running, testing, benchmarking all (or as many as possible/reasonable) of the runtimes in one go. This might involve use of a CMake superproject capable of fetching versions of each runtim from the web, performing the build etc etc. The student will need to optimize the benchmark for HPX by chosing/testing the right executors, parallel algorithms and suchlike to get the best performance possible.

• Abstract: Peridynamics is used to model cracks and fractures in materials. In recent years there have been several numerical approximations proposed for peridynamics. Peridynamics is a nonlocal model, i.e. to compute force/strain/energy at a point, one has to look at the neighbors of a point within a finite radius. A code utilizing the parallel algorithms and futurization within HPX for a single shared memory node is available. This code should be extended with a domain decomposition for computations on several nodes. Here, the challenge would be to perform an efficient load balancing of the domain partitions. In case of damage, the computational costs in the domain where the damage occurs in the material decreases. In this project, an efficient algorithm which detects where the computational costs are decreasing and how to redistribute the domains such that load is balanced should be developed.
• Difficulty: Medium
• Expected result:

1. Extend the existing implementation with domain decomposition for multiple nodes
2. Provide an efficient load balancing algorithms which redistribute the domains after damage.

• Knowledge Prerequisite: C++, STL
• Mentor: Patrick Diehl ()

• Abstract: Some multi-threaded algorithms may require resources that must be held using a lock, but the locking mechanism may be range-based rather than absolute. Consider a large array of N items where a task requires some small subset of the items to be locked whilst a second task requires a second range. If these tasks are placed into a DAG so that task2 can only run once task1 has completed, it will be inefficient when the range of items used by task2 does not overlap the range from task1. When many tasks operate on the range, with randomly overlapping or non-overlapping regions, DAG based task scheduling leads to a highly inefficient strategy. We need a range based lock that can be templated over <items> and that can then be locked/unlocked on ranges (of those items) and interact with our future<> based scheduling so that items will become ready when the range they need has no locks outstanding, and so that when a task releases a lock, any other tasks that overlap the range are in turn signaled as possibly ready. (For an example of how this is used in conventional HPC programming, look up Byte Range locks in MPI for Parallel IO to a single file). A successful implementation can be extended to multi-dimensional locking *2D/3D etc, ideally templated over dimensions and types).
• Difficulty: Medium/Hard
• Expected result: A test application that creates arrays of items and randomly assigns tasks to operate on regions of those items with locking and schedules the tasks to operate in a non-conflicting way.
• Knowledge Prerequisite: Thread safe programming. Futures.
• Mentor: John Biddiscombe ()

• Abstract: STL containers such as vectors/maps/sets/etc are not thread safe. One cannot safely add or remove elements from one of these containers in one thread, whilst iterating or adding/removing in another thread without potentially catastrophic consequences (usually segmentation faults leading to eventual program failure). Some work has begun on implementing concurrent structures in HPX, a concurrent unordered map with reader/writer lock and a partial implementation of concurrent vector exist, but they have not all been completed, do not have unit tests and need to be unified into an hpx::concurrent namespace. A number of libraries implementing thread safe (sometimes lockfree) containers already exist that can be used for ideas and where code uses a boost compatible license can be integrated into HPX. The aim of the project is to collect as much information and as many implementations of threads safe containers and create or integrate them into the HPX library.
• Difficulty: Medium/Hard
• Expected result: A contribution of an hpx::concurrent namespace including as many STL compatible containers (and/or helper structures) as possible, with unit testing and examples that use them.
• Knowledge Prerequisite: Thread safe programming.
• Mentor: John Biddiscombe (), Hartmut Kaiser () and Marcin Copik ()
• See issue #2235 on HPX bug tracker

Note that this project was started by a previous GSoC student, but unfortunately, did not progress far due to other commitments that took the student away from the project. Anyone considering taking up this project may benefit from reading the following blog articles written by the student

• GSoC-01-HPX-and-libcds
• GSoC-02-Deployment-and-Configuration

And also to look at commit f25d57c35de7d05 made by the student to start integrating flat-combining into hpx.

A good first step to demonstrate ability to begin this project, would be to update the commit in that repository to work with current HPX master and work on a simple test to check the code. Ideally the student working on this project would

• Add libcds as a subdirectory in HPX by making use of CMake FetchContent and put together a build that allows HPX to download libcds, build it and then access libcds algorithms and utilities from HPX. The other approach would be to have HPX find_package libcds from a previously installed libcds, but combining the two into a single build setup would be preferable - this step will require familiarity with CMake.
• As noted in the blog articles, libcds makes heavy use of hazard pointers and Read/Copy/Update (RCU) methods in its approach to concurrency. Modifying some of the utilities in libcds to use HPX types where possible and/or integrating some of these utilities in HPX directly (and making changes to libcds where necessary) so that basic tools are shared between libcds and HPX. (Example, Hazard pointers have been proposed for standardization in C++ and we would like a single implementation shared between libcds and HPX, libcds should therefore be integrated cleanly into HPX so that other ancillary structures are not duplicated between the two libraries).

• Abstract: HPX supports performance counters that return a set of values for each invocation. We have used this to implement performance counters collecting histograms for various characteristics related to parcel coalescing (such as the histogram of the time intervals between parcels). The idea of this project is to create a general purpose performance counter which collects the value of any other given performance at given time intervals and calculates a histogram for those values. This project could be combined with Add more arithmetic performance counters.
• Difficulty: Medium
• Expected result: Implement a functioning performance counter which returns the histogram for any other given performance counter as collected at given time intervals.
• Knowledge Prerequisite: Minimal knowledge of statistical analysis is required.
• Mentor: Hartmut Kaiser () and Mikael Simberg ()
• See issue #2237 on HPX bug tracker

• Abstract: HPX already supports performance counters that can be used to dynamically calculate the result of addition, subtraction, multiplication, and division of values gathered from a set of other given performance counters. The idea of this project is to create more performance counters which are very similar to the existing ones, except that those calculate various other statistical results, such as minimum/maximum, mean, and median value (more are possible). This project could be combined with Create generic histogram performance counter.
• Difficulty: Easy/Medium
• Expected result: Implement a set of functioning performance counters which return the result of various statistical operations for a set of other given performance counters.
• Knowledge Prerequisite: Minimal knowledge of statistical analysis is required.
• Mentor: Hartmut Kaiser () and Marcin Copik ()
• See issue #2455 on HPX bug tracker

• Abstract: Our parallel algorithms currently don't support the par_unseq execution policy. This project is centered around the idea to implement this execution policy for at least some of the existing algorithms (such as for_each and similar).
• Difficulty: Medium/Hard
• Expected result: The result should be functioning parallel algorithms when used with the par_unseq execution policy. The loop body should end up being vectorized.
• Knowledge Prerequisite: Vectorization, parallel algorithms.
• Mentor: Marcin Copik ()
• See issue #2271 on HPX bug tracker

• Abstract: Traveler-Integrated is a platform for performance visualization of parallel runtimes such as HPX. The interface allows accessing multiple datasets, from different executions. However, there are several improvements that can be made to the interface in terms of managing large numbers of files (e.g., from historical regression runs) and organizing windows to handle comparison of runs. In this project you will work on the Javascript front end to implement this interface, refining the design through user feedback.
• Difficulty: Easy-Medium
• Expected result: Traveler-Integrated will have a newly designed interface for managing data of multiple runs.
• Knowledge Prerequisite: Javascript.
• Mentor: Kate Isaacs ()

• Abstract: HPX traces are collected with APEX and written in as OTF2 files with extensions. These trace files are typically visualized using a Gantt chart or collection of timelines. The Gantt chart visualization provides difficult information but is quite large, making it difficult to navigate. Integration of this visualization with summary charts, such as histograms which show the distribution of thread types, status, or counter information, could be created to help users understand the global picture of the trace. Through linked (Javascript) interactions, they could help users further filter the trace data to a more manageable, less-cluttered size. Collecting information for these charts will require manipulating the trace file itself (C++/Python). This project will also require some iterations of interface design.
• Difficulty: Medium
• Expected result: The interactive Gantt chart is complimented with interactive histograms which can be queried in dynamic time ranges.
• Knowledge Prerequisite: C++, Python, Javascript.
• Mentor: Kate Isaacs ()

• Abstract: HPX traces are collected with APEX and written in as OTF2 files with extensions. These trace files are typically visualized using a Gantt chart or collection of timelines. The present implementation reads the entirety of the trace file before generating the visualization. However, the OTF2 interface has support for partial reading of the file as well as using a parallel backend. This project would modify the Gantt chart backend (C++) to utilize these features, thus supporting larger files. The project could also modify the front end to use WebGL (Javascript) when the number of data items is large.
• Difficulty: Medium-Hard
• Expected result: Files requiring more memory than a single machine can be run from that machine. The time from program-start to visualization is decreased due to the use of large file features.
• Knowledge Prerequisite: C++, Javascript.
• Mentor: Kate Isaacs ()

is a side project to HPX which tries to uses HPX's facilities to achieve asynchronous I/O on top of POSIX libraries as well as OrangeFS distributed file system. Lustre is parallel distributed file system that is used in many clusters. Adding a Lustre backend to hpxio will be a great addition hpxio since many clusters already use Lustre file system.

• Difficulty: Easy/Medium
• Expected result: hpxio library will be able to lustre file system as backend.
• Knowledge Prerequisite: Good C++ knowledge
• Mentor: Alireza Kheirkhahan (), Hartmut Kaiser ()

• Abstract: HPX has already proven to run efficiently on ARM based systems. This has been demonstrated with an application written for Android tablet devices. A port to handheld devices running with iOS would be the next logical steps! In order to be able to run HPX efficiently on there, we need to adapt our build system to be able to cross compile for iOS and add a code to interface with the iOS GUI and other system services.
• Difficulty: Easy-Medium
• Expected result: Provide a prototype HPX application running on an iPhone or iPad
• Knowledge Prerequisite: C++, Objective-C, iOS
• Mentor: Hartmut Kaiser () and Thomas Heller ()

• Abstract: Create a new parcelport which is based on WebSockets. The WebSockets++ library seems to be a perfect starting point to avoid having to dig into the WebSocket protocol too deeply.
• Difficulty: Medium-Hard
• Expected result: A proof of concept parcelport based on WebSockets with benchmark results
• Knowledge Prerequisite: C++, knowing WebSockets is a plus
• Mentor: Hartmut Kaiser () and Thomas Heller ()

• Abstract: Design and implement Python bindings for HPX exposing all or parts of the HPX functionality with a 'Pythonic' API. This should be possible as Python has a much more dynamic type system than C++. Using Boost.Python seems to be a good choice for this.
• Difficulty: Medium
• Expected result: Demonstrate functioning bindings by implementing small example scripts for different simple use cases
• Knowledge Prerequisite: C++, Python
• Mentor: Hartmut Kaiser ()

• Abstract: Design and implement efficient all-to-all communication LCOs. While MPI provides mechanisms for broadcasting, scattering and gathering with all MPI processes inside a communicator, HPX currently misses this feature. It should be possible to exploit the Active Global Address Space to mimic global all-to-all communications without the need to actually communicate with every participating locality. Different strategies should be implemented and tested. A first and very basic implementation of broadcast already exists which tries to tackle the above described problem, however, more strategies to granularity control and locality exploitation need to be investigated an implemented. We also have a first version of a gather utility implemented.
• Difficulty: Medium-Hard
• Expected result: Implement benchmarks and provide performance results for the implemented algorithms
• Knowledge Prerequisite: C++
• Mentor: Thomas Heller () and Andreas Schaefer ()

• Abstract: Implement a EDSL to specify the placement policies for components. This could be done similar to [Chapels Domain Maps] (http://chapel.cray.com/tutorials/SC12/SC12-6-DomainMaps.pdf). In Addition, allocators can be built on top of those domain maps to use with C++ standard library containers. This is one of the key features to allow users to efficiently write parallel algorithms without having them worried to much about the initial placement of their distributed objects in the Global Address space
• Difficulty: Medium-Hard
• Expected result: Provide at least one policy which automatically creates components in the global address space
• Knowledge Prerequisite: C++
• Mentor: Thomas Heller () and Hartmut Kaiser ()

• Abstract: Implement resumable functions either in GNU g++ or Clang. This should be based on the corresponding proposal to the C++ standardization committee (see N4286. While this is not a project which directly related HPX, having resumable functions available and integrated with hpx::future would allow to improve the performance and readability of asynchronous code. This project sounds to be huge - but it actually should not be too difficult to realize.
• Difficulty: Medium-Hard
• Expected result: Demonstrating the await functionality with appropriate tests
• Knowledge Prerequisite: C++, knowledge of how to extend clang or gcc is clearly advantageous
• Mentor: Hartmut Kaiser ()

• Abstract: HPX is an excellent runtime system for doing task based parallelism. In its current form however results of tasks can only be expressed in terms of returning from a function. However, there are scenarios where this is not sufficient. One example would be lazy ranges of integers (For example fibonacci, 0 to n, etc.). For those a generator/yield construct would be perfect!
• Difficulty: Easy-Medium
• Expected result: Implement yield and demonstrate on at least one example
• Knowledge Prerequisite: C++
• Mentor: Hartmut Kaiser () and Thomas Heller ()

• Abstract: Implement Graph500 using the HPX Runtime System. Graph500 is the benchmark used by HPC industry to model important factors of many modern parallel analytical workloads. The Graph500 list is a performance list of systems using the benchmark and was designed to augment the Top 500 list. The current Graph500 benchmarks are implemented using OpenMP and MPI. HPX is well suited for the fine-grain and irregular workloads of graph applications. Porting Graph500 to HPX would require replacing the inherent barrier synchronization with asynchronous communications of HPX, producing a new benchmark for the HPC community as well as an addition to the HPX benchmark suite. See http://www.graph500.org/ for information on the present Graph500 implementations.
• Difficulty: Medium
• Expected result: New implementation of the Graph500 benchmark.
• Knowledge Prerequisite: C++
• Mentor: Patricia Grubel (), and Thomas Heller ()

• Abstract: Implement a version of one or more mini apps from the Mantevo project (http://mantevo.org/ "Mantevo Project Home Page") using HPX Runtime System. We are interested in mini applications ported to HPX that have irregular workloads. Some of these are under development and we will have access to them in addition to those listed on the site. On the site, MiniFE and phdMESH would be a good additions to include in HPX benchmark suites. Porting the mini apps would require porting the apps from C to C++ and replacing the inherent barrier synchronization with HPX's asynchronous communication. This project would be a great addition to the HPX benchmark suite and the HPC community.
• Difficulty: Medium
• Expected result: New implementation of a Mantevo mini app or apps.
• Knowledge Prerequisite: C, C++
• Mentor: Patricia Grubel () and Thomas Heller ()

• Abstract: The trilinos project (http://trilinos.org/) consists of many libraries for HPC applications in several capability areas (http://trilinos.org/capability-areas/). Communication between parallel processes is handled by an abstract communication API (http://trilinos.org/docs/dev/packages/teuchos/doc/html/index.html#TeuchosComm_src) which currently has implementations for MPI and serial only. Extending the implementation with an HPX backend would permit any of the Teuchos enabled Trilinos libraries to run in parallel using HPX in place of MPI. Of particular interest is the mesh partitioning library Zoltan2 (http://trilinos.org/packages/zoltan2/ "Zoltan2 - A Package for Load Balancing and Combinatorial Scientific Computing") which would be used as a test case for the new communications interface. Note that some new collective HPX algorithms may be required to fulfill the API requirements (see all-to-all-communications project above).
• Difficulty: Medium-Hard
• Expected result: A demo application for partitioning meshes using HPX and Zoltan.
• Knowledge Prerequisite: C, C++, (MPI)
• Mentor: John Biddiscombe () and Thomas Heller ()

• Abstract: Vectorization is a key technique to leverage the full potential of modern CPUs. LibFlatArray is a C++ library which helps with transitioning scalar numerical algorithms on objects to vectorized implementations. It comes with expression templates that enable the user to write code that encapsulate vector intrinsics but appear to the user like standard mathematical datatypes and operations. These templates (dubbed short_vec in LibFlatArray) currently lack a mechanism to selectively set certain lanes of the vector registers via conditional masks. If we had this functionality we'd be able to represent if/then/else constructs way more idiomatically. Intrinsics for mask generation/application are readily available in all current vector instruction sets (Intel/ARM/IBM), we simply lack convenient/efficient wrappers to utilize them.
• Difficulty: Medium
• Expected result: Wrapper functions for comparison (to generate masks) and conditional assignment (using masks)
• Knowledge Prerequisite: basic C++, vectorization via SSE, AVX/AVX2/AVX512
• Mentor: Andreas Schaefer ()

• Abstract: HPX.Compute is a layer on top of HPX which provides a way to distribute work and data for parallel algorithms on accelerators. The existing implementation supports execution on CUDA-enabled GPUs. In this project a ROCm backend for AMD GPUs should be implemented based on the existing CUDA backend. The work could involve either implementing a completely new backend optimized for AMD GPUs or the existing CUDA backend could be ported to use HIP which would allow a single implementation to be used for both AMD and NVidia GPUs. Other tasks involve implementing and testing additional parallel algorithms, implementing a concurrent executor, supporting work dispatch to multiple devices, or optimizing and comparing the performance of different backends.
• Difficulty: Medium
• Expected result: The backend is comparable with CUDA in terms of supported features and can schedule at least few algorithms, including the index-based parallel for-loop.
• Knowledge Prerequisite: Basic knowledge in CUDA or ROCm, good knowledge in C++.
• Mentor: Mikael Simberg ()

• Abstract: The HPX runtime system uses a module called Parcelport to deliver packages over the network. An efficient implementation of this layer is indispensable and we are searching for new backend implementations based on CCI, ucx or libfabric. All of these mentioned abstractions over various network transport layers offer the ability to do fast, one-sided RDMA transfers. The purpose of this project is to explore one of these and implement a parcelport using it.
• Difficulty: Medium-Hard
• Expected result: A proof of concept for a chosen backend implementation with performance results
• Knowledge Prerequisite: C++, Basic understanding of Network transports
• Mentor: Thomas Heller ()

• Abstract: The HPX runtime system uses Active Global Address Space (AGAS) to address global objects. Objects in HPX are identified by a 128-bit unique global identifier, abbreviated as a GID. The performance of HPX relies on fast lookups of GIDs in associative containers. We have experimented with binary search trees (std::map) and hash maps (std::unordered_map). However, we believe that we can implement a search data structure based on n-ary trees, tries or radix trees that exploit the structure of GIDs such that it allows us to have faster lookup and insertion.
• Difficulty: Medium-Hard
• Expected result: Various different container approaches to choose from together with realistic benchmarks to show the performance properties
• Knowledge Prerequisite: C++, Algorithms
• Mentor: Thomas Heller ()

• Abstract: Blaze Tensor implements 3D data structures (tensors) that integrate well with the Blaze library. From the Blaze website: Blaze is an open-source, high-performance C++ math library for dense and sparse arithmetic. With its state-of-the-art Smart Expression Template implementation Blaze combines the elegance and ease of use of a domain-specific language with HPC-grade performance, making it one of the most intuitive and fastest C++ math libraries available. Blaze Tensor follows the design goals of Blaze, so all of the above applies to it as well. There are many tasks one could work on for Blaze Tensor. For an initial list, please see here.
• Difficulty: Medium-Hard
• Expected result: Finish implementation (and corresponding doxygen based API documentation) for the selected set of features
• Knowledge Prerequisite: CMake and C++
• Mentor: Hartmut Kaiser ()

• Abstract: Our parallel algorithms currently expect for the begin iterators to have the same type as the corresponding end iterators. The latest changes to the C++ Standard allow for those to be different. This enables the use of the algorithms with more general range abstractions (i.e. begin-iterator/sentinel pairs such as C-style strings). We have created a list of algorithms that need to be changed to support different types for the begin/end iterator pairs (see here). There you can also see what algorithms have already been adapted, which may help in understanding the task.
• Difficulty: Medium-Hard
• Expected result: Make as many parallel algorithms as possible compatible with ranges
• Knowledge Prerequisite: CMake and C++
• Mentor: Hartmut Kaiser ()

• Abstract: This project is different from the project Parallel Algorithms and Ranges as it does not require to modify the existing iterator-based parallel algorithms but requires to create new algorithm implementations that expose a range based interface as proposed by the Ranges-TS - Edit: these have been added to C++20 (latest draft). We have already added several range-based parallel algorithms, but many are still missing (see here for a list of what algorithms require work). Usually, the range-based algorithms are almost trivial to implement as they can just forward to the existing iterator-based versions, especially after those have been adapted to support ranges (see Parallel Algorithms and Ranges). There are however some algorithms that will require API changes to the existing iterator-based code (adding projections, mostly).
• Difficulty: Easy-Medium
• Expected result: Implement as many range-based parallel algorithms as possible
• Knowledge Prerequisite: CMake and C++
• Mentor: Hartmut Kaiser ()

• Abstract: C++17 has added a set of parallel algorithms to the standard library. In HPX we have implemented almost all of those, however we still miss a handful. Please see the corresponding ticket that lists the algorithms that have been implemented and those that are still up for grabs. For this project a student would work on implementing one or more of the remaining parallel algorithms in HPX.
• Difficulty: Medium-Hard
• Expected result: Implement some or all of the missing parallel algorithms
• Knowledge Prerequisite: CMake and C++
• Mentor: Hartmut Kaiser ()

• Abstract: In addition to our extensive ideas list, there are several active tickets listed in our issue tracker which are worth tackling as a separate project. Feel free to talk to us if you find something which is interesting to you. A prospective student should pick at least one ticket with medium to hard difficulty and discuss how it could be solved
• Difficulty: Medium-Hard
• Expected result: The selected issues need to be fixed
• Knowledge Prerequisite: C++
• Mentor: Thomas Heller ()

---

• Abstract:
• Difficulty:
• Expected result:
• Knowledge Prerequisite:
• Mentor: