Skip to content
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

Feature: Support blocked ranges #551

Open
samayala22 opened this issue Feb 7, 2024 · 1 comment
Open

Feature: Support blocked ranges #551

samayala22 opened this issue Feb 7, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@samayala22
Copy link

This is a feature that is only really useful for those developping high performance kernels.

In TBB you have access to blocked_ranges, which gives you the begin and the end index of the current task partition. This is very practical when you have fully vectorized kernels that operate on a range rather than an index.

Example:

tbb::parallel_for(tbb::blocked_range<int>(0, 1000),[&](const tbb::blocked_range<int>& r) {
    some_vectorized_kernel(r.begin(), r.end());
});

In taskflow, the closest thing we can do right now is:

const int step = 16; // some hardcoded step size
taskflow.for_each_index(0, 1000, step, [&] (int i) {
    some_vectorized_kernel(i, i+step);
});

This is okay but we are hardcoding the step size (usually the vector width) which can affect the granularity of the parallelism. If the step is too big, irregular workloads cannot be properly balanced. If the step is too small (like here at 16), we are increasing function call overhead, decreasing ILP in our kernel and polluting cache between intermediate calls.

The solution is almost there. With something like a guided or static partitioner, we just need to modify the api to have some sort of access to the chunk size (or a start and begin index like TBB).

Example:

taskflow.for_each_index(0, 1000, step, [&] (const tf::Range<int>& r) {
    some_vectorized_kernel(r.begin(), r.end());
});
@tsung-wei-huang tsung-wei-huang added the enhancement New feature or request label Feb 17, 2024
@longpractice
Copy link

I also think this is kind of important since within a block I usual do a bit more initialization work before going into individual indices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants