Build Packages / build:viewer-tgz:cpu (push) Successful in 19m41s
Build Packages / build:viewer-tgz:cuda (push) Successful in 22m26s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 24m17s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 25m22s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 28m12s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 28m41s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 29m1s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 20m8s
Build Packages / XDS test (durin plugin) (push) Successful in 11m39s
Build Packages / build:rpm (rocky9) (push) Successful in 21m51s
Build Packages / Generate python client (push) Successful in 34s
Build Packages / Build documentation (push) Successful in 1m24s
Build Packages / Create release (push) Skipped
Build Packages / build:rpm (rocky8) (push) Successful in 26m38s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 22m0s
Build Packages / DIALS test (push) Successful in 21m28s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 25m22s
Build Packages / XDS test (neggia plugin) (push) Successful in 10m14s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 11m19s
Build Packages / Unit tests (push) Successful in 1h19m35s
Build Packages / build:windows:nocuda (push) Successful in 59m3s
Build Packages / build:windows:cuda (push) Successful in 1h2m17s
Two thirds of a rotation run is one thread. The image loop is not the problem - on the heaviest crystal of the battery it is 1.8 s of 40 - and neither GPU nor CPU is saturated, because while the corrections and the space-group search run there is one core working and 47 idle. Mean occupancy over the whole run: 3.9 of 48. In the correction surfaces (absorption in the goniometer frame, detector-plane modulation, absorption against time and detector position - all one function): the per-cell accumulation, the score reduction and the final apply are now chunked, as are the three loops that assign a full to its cell, one of which spends a sine and a cosine per full de-rotating it into the crystal frame. Two full sorts of four million floats went with them: only the nine bin edges are wanted, so they are selected instead, each selection starting where the last one left off. The per-group pass is deliberately left serial. The terms of one group are spread all over the list, so the only way to give a thread groups of its own is to walk in group order, and that trades a near-sequential read of the fulls for a random one over a few hundred megabytes - the trade that already lost once in the combine kernel. The space-group search scores each candidate rotation by correlating I(h) against I(Rh) over the whole merge. Every operator it can ask about comes from a fixed list and none of them depend on each other, so they are scored up front, in parallel, and the search reads the cache. The scratch that stops a pair being counted twice is now per worker rather than shared. Worker counts are gated on how much work there is, not on how many cores the machine has (ThreadsForWork). Both parallel helpers start a thread per chunk, so a small dataset on a large node would otherwise pay for 48 thread starts to sum a few thousand terms - and this runs on 8-core laptops as well as on this node. Measured on the heaviest crystal, idle machine, two runs each, summed over both passes: those phases go 7.88 s -> 5.19 s. Whole-run wall time is the wrong ruler for it - it moves +-4 s between identical runs. Battery 9m45s -> 9m23s, space group 21/24, no failures; 16 of 24 crystals bit-identical to the previous run and the rest inside the noise floor of running one binary twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
67 lines
3.1 KiB
C++
67 lines
3.1 KiB
C++
// SPDX-FileCopyrightText: 2026 Filip Leonarski, Paul Scherrer Institute <filip.leonarski@psi.ch>
|
|
// SPDX-License-Identifier: GPL-3.0-only
|
|
|
|
#pragma once
|
|
|
|
#include <algorithm>
|
|
#include <atomic>
|
|
#include <future>
|
|
#include <vector>
|
|
|
|
// Two shapes of "run this over a range on several threads", used by the analysis code. Both take the
|
|
// worker count from the caller rather than asking the hardware, so a run that was told how many
|
|
// threads to use keeps to it.
|
|
|
|
// How many workers a pass over `n` cheap items should use: enough that each gets at least
|
|
// `min_per_thread` of them, and never more than the caller was given. Both helpers below start a
|
|
// thread per chunk, which costs tens of microseconds, so a pass that is repeated - or one whose data
|
|
// is small - can easily spend more on splitting the work than on doing it. That is not a large
|
|
// machine's problem: it is what makes the same code right on an 8-core laptop, a 16-core desktop and
|
|
// a two-socket node, none of which should be handed 48 chunks of a few thousand items.
|
|
inline size_t ThreadsForWork(size_t n, size_t nthreads, size_t min_per_thread = 32768) {
|
|
if (nthreads <= 1 || n == 0) return 1;
|
|
return std::clamp<size_t>(n / min_per_thread, 1, nthreads);
|
|
}
|
|
|
|
// Chunked: each worker gets one contiguous [lo, hi) range and there is no per-item synchronisation.
|
|
// Right for millions of cheap uniform items - the CPU stand-in for a flat CUDA grid-stride kernel.
|
|
// The split is fixed and deterministic, so a pass whose per-element work is independent gives the
|
|
// same answer as the serial loop, bit for bit.
|
|
template <typename Fn>
|
|
void ParallelChunks(int n, size_t nthreads, Fn fn) {
|
|
if (n <= 0) return;
|
|
const int nt = static_cast<int>(std::max<size_t>(1, std::min(nthreads, static_cast<size_t>(n))));
|
|
if (nt == 1) { fn(0, n); return; }
|
|
const int chunk = (n + nt - 1) / nt;
|
|
std::vector<std::future<void>> futures;
|
|
futures.reserve(nt);
|
|
for (int t = 0; t < nt; t++) {
|
|
const int lo = t * chunk, hi = std::min(n, lo + chunk);
|
|
if (lo >= hi) break;
|
|
futures.emplace_back(std::async(std::launch::async, [&fn, lo, hi] { fn(lo, hi); }));
|
|
}
|
|
for (auto &f : futures) f.get();
|
|
}
|
|
|
|
// Work-stealing per item, off a shared atomic counter: one atomic per item, so use it only where the
|
|
// per-item work is heavy and uneven (per-frame fits, per-ring selections) and the atomic amortises.
|
|
// For millions of tiny uniform items a per-item atomic is pure contention - use ParallelChunks.
|
|
template <typename Fn>
|
|
void ParallelFor(int n, size_t nthreads, Fn fn) {
|
|
if (n <= 0) return;
|
|
if (nthreads <= 1 || n == 1) {
|
|
for (int i = 0; i < n; i++) fn(i);
|
|
return;
|
|
}
|
|
const size_t local = std::min(nthreads, static_cast<size_t>(n));
|
|
std::atomic<int> next = 0;
|
|
std::vector<std::future<void>> futures;
|
|
futures.reserve(local);
|
|
for (size_t t = 0; t < local; t++)
|
|
futures.emplace_back(std::async(std::launch::async, [&] {
|
|
for (int i = next.fetch_add(1); i < n; i = next.fetch_add(1))
|
|
fn(i);
|
|
}));
|
|
for (auto &f : futures) f.get();
|
|
}
|