3 ms·

I worked on a massively threaded signal processing application a few years ago. We manually set all of our thread affinities due to the issues raised in this a

I worked on a massively threaded signal processing application a few years ago. We manually set all of our thread affinities due to the issues raised in this article. We were also using the real-time kernel and round robin scheduler, though, so we had other considerations as well.

bawigga 11y ago
Can you share more about the application you built? Genuinely curious about what kind of projects need this level of concurrency.
- vonmoltke 11y ago
  It was the signal processor for an airborne surveillance radar. I can't get into specific sizing, but our processing technique was to divide the field of view into a rectangular grid, with each grid square backed by a processing thread. As the beam positions came in (each beam also has its own processing thread) the data from the beams was mapped to the appropriate thread in the grid. Once the sweep was complete, all the threads in the grid would start running the mode algorithms (moving target indication (MTI) or synthetic aperture radar (SAR) imaging), sharing data with their logical neighbors and building a complete picture of the area. It was basically grid computing, since we had multiple machines that had to be coordinated at certain points in the algorithm chain.
kev009 11y ago
It is standard practice when max throughput and/or latency are desired to pin. A scheduler provides convenience and automatic balancing in face of shifting workloads. If you have a fixed function system, it's just getting in the way.
- vonmoltke 11y ago
  Pretty much. Our pinning varied by task. Some were pinned to sockets, some to cores, and some to specific hardware threads. That's what I meant by "other considerations"; we would have still been pinning threads even if the bugs in the article didn't exist. The bugs just made figuring out the best pinning scheme more difficult.
- wyldfire 11y ago
  Yes and no. Depending on the complexity level of the solution it may make sense to at least widen the threads' affinity masks. It often makes sense to offer some degree of freedom to the scheduler.

bawigga 11y ago

Can you share more about the application you built? Genuinely curious about what kind of projects need this level of concurrency.

vonmoltke 11y ago
It was the signal processor for an airborne surveillance radar. I can't get into specific sizing, but our processing technique was to divide the field of view into a rectangular grid, with each grid square backed by a processing thread. As the beam positions came in (each beam also has its own processing thread) the data from the beams was mapped to the appropriate thread in the grid. Once the sweep was complete, all the threads in the grid would start running the mode algorithms (moving target indication (MTI) or synthetic aperture radar (SAR) imaging), sharing data with their logical neighbors and building a complete picture of the area. It was basically grid computing, since we had multiple machines that had to be coordinated at certain points in the algorithm chain.

kev009 11y ago

It is standard practice when max throughput and/or latency are desired to pin. A scheduler provides convenience and automatic balancing in face of shifting workloads. If you have a fixed function system, it's just getting in the way.

vonmoltke 11y ago
Pretty much. Our pinning varied by task. Some were pinned to sockets, some to cores, and some to specific hardware threads. That's what I meant by "other considerations"; we would have still been pinning threads even if the bugs in the article didn't exist. The bugs just made figuring out the best pinning scheme more difficult.
wyldfire 11y ago
Yes and no. Depending on the complexity level of the solution it may make sense to at least widen the threads' affinity masks. It often makes sense to offer some degree of freedom to the scheduler.