From 5d23f2ac2b7e2b795ec06792880bf31c3ef5dd6a Mon Sep 17 00:00:00 2001 From: Dan Hoeflinger Date: Thu, 16 Jan 2025 14:47:07 -0500 Subject: [PATCH] adding discussion of input sizes Signed-off-by: Dan Hoeflinger --- .../proposed/algorithms_histogram_cpu_backends/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/rfcs/proposed/algorithms_histogram_cpu_backends/README.md b/rfcs/proposed/algorithms_histogram_cpu_backends/README.md index 56d1ea7559..cf4236bd85 100644 --- a/rfcs/proposed/algorithms_histogram_cpu_backends/README.md +++ b/rfcs/proposed/algorithms_histogram_cpu_backends/README.md @@ -25,9 +25,16 @@ they can select from when using oneDPL. It is important that all combinations of `histogram` APIs. ### Performance -With little computation, a histogram algorithm is likely a memory-bound algorithm. So, the implementation prioritizes +Histogram algorithms typically involve minimal computation and are likely to be memory-bound. So, the implementation prioritizes reducing memory accesses and minimizing temporary memory traffic. +For CPU backends, we will focus on input sizes ranging from 32K to 4M elements and 32 - 4k histogram bins. Smaller sizes +of input may best be suited for serial histogram implementation, and very large sizes may be better suited for GPU +device targets. Histogram bin counts can vary from use case to use case, but the most common rule of thumb is to size +the number of bins approximately to the cube root of the number of input elements. For our input size ranges this gives +us a range of 32 - 256. In practice, some users find need to increase the number of bins beyond that rough rule. +For this reason, we have aelected our histogram size range to 32 - 4k elements. + ### Memory Footprint There are no guidelines here from the standard library as this is an extension API. Still, we will minimize memory footprint where possible.