You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
auto _ = distributed_pool[0].for_slices(first_half.size() / dimensions, concurrent_searcher);
329
-
auto _ = distributed_pool[1].for_slices(second_half.size() / dimensions, concurrent_searcher);
337
+
});
338
+
slices.join();
330
339
return result;
331
340
}
332
341
```
333
342
334
343
In a dream world, we would call `distributed_pool.for_n`, but there is no clean way to make the scheduling processes aware of the data distribution in an arbitrary application, so that's left to the user.
335
-
Calling `linux_colocated_pool::for_slices` on individual NUMA-node-specific colocated pools is the cheapest general-purpose recipe for Big Data applications.
344
+
The `for_slices` helper provides colocated metadata (`fu::colocated_prong`) that lets you pick the right shard of data based on the NUMA node, while keeping scheduling inside the distributed pool.
336
345
For more flexibility around building higher-level low-latency systems, there are unsafe APIs expecting you to manually "join" the broadcasted calls, like `unsafe_for_threads` and `unsafe_join`.
337
-
Instead of hard-coding the `distributed_pool[0]` and `distributed_pool[1]`, we can iterate through them without keeping the lifetime-preserving handle to the passed `concurrent_searcher`:
338
-
339
-
```cpp
340
-
for (std::size_t colocation = 0; colocation < distributed_pool.colocations_count(); ++colocation)
0 commit comments