Cell Sorting, main branch (2026.02.20.)#1264
Cell Sorting, main branch (2026.02.20.)#1264krasznaa wants to merge 7 commits intoacts-project:mainfrom
Conversation
| if (rhs >= cells.size()) { | ||
| return true; | ||
| } | ||
| return cells.at(lhs) < cells.at(rhs); |
There was a problem hiding this comment.
@stephenswat, "how sorted" do the cells actually need to be? 🤔 The I/O code was "fully" sorting them so far, so I went for the same in these algorithms. But is this necessary? Would it maybe be enough to just do the same that we do for the measurements? (That cells belonging to the same module would be side-by-side. But not necessarily in the correct order.)
There was a problem hiding this comment.
Stephen confirmed recently that they need to be grouped (contiguous) by module and then sorted by row and column indices.
There was a problem hiding this comment.
Yeah, this is what I remembered. Still, was hoping that I misremembered...
In the end this is exactly what the EDM defines currently.
|
This is quite interesting, thank you for providing this. So 0.85 ms to sort the completely randomized cells of a PU200 events. First, just to make sure that our numbers are comparable: how many cells is this? For ITk we have on average 1.1e6 cells per ttbar, pu200 event. I expect it to be the same. If we want to compare with the current scenario, we want to know how long it takes to sort all cells provided that there are already grouped by module. This, I expect, can make a significant difference on your side. To be more cost efficient than the CPU equivalent in this scenario the GPU needs to make it in 0.54 ms or less. |
Made it possible to randomize the order of the cells read from an input CSV. In order to exercise the newly added cell sorting algorithms.
krasznaa
force-pushed
the
CellSorting-main-20260219
branch
from
7a1f05b to
388eff3
Compare
|
All good/relevant points. The ODD μ=200 sample contains O(500k) cells per event. So about half of the ITk. 🤔 I'll do a test with just shuffling the cells per module. Let's see how much of a change that will bring. ( 🤞 that a lot...) |
This is so odd (pun intended) that it requires double-checking and further investigation. |
|
|
This latest version of the code, which only shuffles cells within the same module, runs like this: So Thrust's sorting, as expected, is quite a bit quicker in this case. |
Awesome. I will now test this with ITk. |
2 participants
After earlier discussions about how fast we can be with sorting cells as part of the throughput measurements, I spent some time in putting up some code for this.
I introduced "cell sorting algorithms" for all backends. In pretty much the same way in which the measurement sorting algorithms are implemented.
Then I taught
traccc::io::read_cells(...)how to randomize the order of the cells on request. I did it like this because the CSV reading code is fundamentally set up such that it would output a sorted vector of cells. Instead of completely re-thinking the logic of the I/O code, it was easier to add a shuffling step at the end. (When the user asks for it.)Finally I updated the throughput measurement applications to:
Unfortunately the result is slightly worse than what I was hoping for. 😦 With the current
mainbranch I see the following (reference) throughput on our trusty ol' A5000:While when I add an extra sorting step, I get:
So the cell sorting adds almost an entire millisecond to the event processing. 😦 Way more than I was expecting...
I didn't do any deeper profiling on the sorting code. It's not impossible that it could still be improved. And it's also worth remembering that the random shuffling of the cells that the code does is a much worse scenario than what we would ever get from real data. Even under the least ideal circumstances.
Still, I was hoping for a quicker sorting, even with all this taken into account. 🤔
Pinging @flg, @paradajzblond.