Skip to content

Conversation

@BwL1289
Copy link

@BwL1289 BwL1289 commented Apr 26, 2025

No description provided.

xnnpack-bot and others added 25 commits December 16, 2024 17:11
PiperOrigin-RevId: 706596019
PiperOrigin-RevId: 707095720
PiperOrigin-RevId: 707224063
2nd try, fixed subtle difference in `pthreadpool_decrement_fetch_acquire_release_size_t` this time around.

PiperOrigin-RevId: 708224758
Unless we're on Android, where sleeping/waking is slow.

PiperOrigin-RevId: 708363228
PiperOrigin-RevId: 714131650
…tegies to `pthreadpool`.

The `pthreadpool_parallelize_Xd_tile_Yd_dynamic` strategy differs from the existing non-dynamic `pthreadpool_parallelize_Xd_tile_Yd` in that the `count_*` argument of `function` corresponding to the innermost dimension can be any integer multiple of the corresponding `tile_*` argument, or the remainder of that range.

E.g. `pthreadpool_parallelize_3d_tile_2d_dynamic(&threadpool, function, context, range_i, range_j, range_k, tile_j, tile_k)`, results in calls to
```
function(context, offset_i, offset_j, offset_k, count_j, count_k)
```
where `offset_j` and `offset_k` are integer multiples of `tile_j` and `tile_k`, respectively, and `count_k` is an integer multiple of `tile_k` or `range_k - offset_k`. If `range_k <= tile_k`, then `count_j` may be an integer multiple of `tile_j` or `range_j - offset_j`.

The number of elements processed in each call is chosen as `max((count - offset) / (chunk_factor * num_threads), 1)` where `count` is the total number of elements and `offset` is the current number of elements already processed. This produces large element chunks initially, when there are lots of elements to process, and successively smaller chunks as the end of the computation nears.

The `chunk_factor` used above is the ratio of the fastest to the slowest core in the parallel computation plus one. On heterogeneous systems, this is set to `5`, otherwise to `2`.

PiperOrigin-RevId: 715757992
…gies to match the tile traversal order of the other strategies.

Also use the same logic for picking tiles within the range (owner picks from `range_start`, stealing threads from `range_end`) to reduce the number of atomic operations per tile.

PiperOrigin-RevId: 723497649
…ut first check.

PiperOrigin-RevId: 724250471
Apple toolchains have been moved to apple_support from Bazel 7. See bazelbuild/bazel#16619. Those values won't match anymore.

Also all those config_settings should move to platforms: https://bazel.build/extending/platforms

PiperOrigin-RevId: 732118106
PiperOrigin-RevId: 736869281
…d `pthreadpool_parallelize_4d_tile_2d_dynamic_with_uarch`.

PiperOrigin-RevId: 736903003
PiperOrigin-RevId: 738347700
…placing the implementation of pthreadpool functions.

PiperOrigin-RevId: 740067423
@BwL1289 BwL1289 merged commit be3c5e9 into eugo-inc:master Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants