leonarski_fandClaude Opus 5.5
aa3fa6b9c7
A cold run on a spinning disk waited on the disk twice over. The CBF header
scan read 256 kB from every frame on eight threads that each strode through
their own share of the sweep, so they drifted apart and the scan became a
seek storm (34 s for 2400 frames here); and after it, the pre-scan and the
first-pass indexing touch a few hundred frames and leave the disk idle until
the first image loop reads everything at seek-bound rates.
- ReadAhead (reader/): once the dataset is open, rugnux starts eight threads
that read the data files - HDF5 data files (legacy, VDS or the integrated
master) or the per-frame CBF/marCCD/SMV files - in 4 MB pieces taken
strictly in order, into a throwaway buffer. One stream reads this disk at
125 MB/s, eight in-order streams at 190 MB/s, 32 at 157 MB/s. It never gets
more than a quarter of MemAvailable (GlobalMemoryStatusEx on Windows, 4 GiB
where there is no figure) ahead of what ReadRawImage has handed out, so a
dataset bigger than the cache does not evict its own start, and it stops
with the reader. Plain ifstream reads: portable, no POSIX calls.
- Header scans (CBF, marCCD, SMV) hand the files out in order from an atomic
counter (sweep::ForEachInOrder) instead of striding: 18 s -> 12 s for 2400
cold CBF headers. The CBF header is first read with a 16 kB probe and again
with the old 256 kB one only when the separator is not in it, so the parsed
header is exactly what it was: 12 s -> 6 s.
Output unchanged: p.hkl, p.mtz and p_unmerged.mtz md5-identical to the
rc173 baseline on 6toc (CBF, 2400 frames, 6.0 GB) and 9q41 (HDF5 VDS, 900
frames, 5.1 GB), and on 6z9g (HDF5, 12.8 GB) to the unmodified branch; myob
(p.hkl p.mtz p_P1.mtz p_unmerged.mtz) md5-identical to the reference.
Measured cold (files evicted with POSIX_FADV_DONTNEED before every run),
same code without this commit vs with it, on a shared box (load 20-70, other
agents reading the same disk, so single runs scatter by +-20 s):
6toc wall 61.7/62.7 -> 49.3/49.8 s (clean pairs); all data resident
after 62/51/50 -> 45/41/42 s
9q41 wall 67.3 -> 57.8 s (clean pair); resident after 58/46/43 -> 48/37/35 s
6z9g resident after 81 -> 69 s
The first image loop can look slower with this in CBF runs: the old 256 kB
header probes pulled ~70% of the data in as kernel readahead, so the old
loop started warm - after a 34 s header scan instead of 10 s.
Warm (myob, NVMe, cached): 19.35/20.00 s without, 19.76-20.16 s with; the
read-ahead then only copies 9.3 GB out of the page cache, 0.44 s wall and
3.4 CPU-s measured standalone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D1G8gJVAy6gp1K5Dz3NE5C
59 lines
2.5 KiB
C++
59 lines
2.5 KiB
C++
// SPDX-FileCopyrightText: 2026 Filip Leonarski, Paul Scherrer Institute <filip.leonarski@psi.ch>
|
|
// SPDX-License-Identifier: GPL-3.0-only
|
|
|
|
#pragma once
|
|
|
|
#include <atomic>
|
|
#include <cstdint>
|
|
#include <string>
|
|
#include <thread>
|
|
#include <vector>
|
|
|
|
// Streams the files that hold a dataset's frames into the page cache, front to back, ahead of the
|
|
// image loops that read them.
|
|
//
|
|
// On a spinning disk a cold run otherwise waits on the disk: the header scan, the pre-scan and the
|
|
// first-pass indexing touch a few hundred frames and leave the disk idle for tens of seconds, and
|
|
// then the first image loop reads everything at whatever rate its scattered requests get. Streaming
|
|
// from the moment the dataset is open keeps the disk busy through all of that, at its sequential
|
|
// rate, so the loops find their frames already in memory.
|
|
//
|
|
// The files are read in 4 MB pieces by a few threads that take the pieces strictly in order: on the
|
|
// disk measured here one thread streams at 125 MB/s, eight such threads at 190 MB/s (and 32 at
|
|
// 157 MB/s), so eight keep the stream ahead of an image loop that is itself reading from disk.
|
|
//
|
|
// It changes only WHEN bytes arrive, never what is read: the loops still read every image themselves,
|
|
// and a frame the read-ahead has not reached yet is read cold, as it always was.
|
|
//
|
|
// It never runs more than a window - a quarter of the memory available when it starts - ahead of
|
|
// what the loops have read. A dataset larger than that is not streamed in only to push out its own
|
|
// beginning before the first loop gets there; and a page the read-ahead brought in is then read a
|
|
// second time by the loop, which is what keeps it in the page cache for the loops after.
|
|
class ReadAhead {
|
|
struct Piece {
|
|
size_t file;
|
|
uint64_t offset; // in the file
|
|
uint64_t position; // in the whole stream
|
|
};
|
|
|
|
std::vector<std::string> files_;
|
|
std::vector<Piece> pieces_;
|
|
double window_ = 0;
|
|
double bytes_per_image_ = 0;
|
|
std::atomic<size_t> next_piece_{0};
|
|
std::atomic<uint64_t> images_read_{0};
|
|
std::atomic<bool> stop_{false};
|
|
std::vector<std::thread> threads_;
|
|
|
|
void Run();
|
|
public:
|
|
// files: in the order the images sit in them; n_images: how many images they hold between them.
|
|
ReadAhead(std::vector<std::string> files, uint64_t n_images);
|
|
~ReadAhead();
|
|
ReadAhead(const ReadAhead &) = delete;
|
|
ReadAhead &operator=(const ReadAhead &) = delete;
|
|
|
|
// An image loop has read one image; the window moves on by one image's worth of bytes.
|
|
void ImageRead() { images_read_++; }
|
|
};
|