machine
Mojo module 🡭
machine
What the CPU this process is running on looks like, for the few thresholds that depend on it.
Most of this package’s parallelism decisions are work counts, which
are machine-independent enough to be constants. Two are not: whether a
buffer still fits the last-level cache the writing core owns decides
whether banding a pure-store pass helps or hurts (_clear_bands in
buffer.mojo), and the same question about a source decides how far a
read-heavy pass should spread (_read_local_bands in resize.mojo).
Both were measured on one machine and were written as that machine’s
number, 16 MB, which is one L3 slice of a Threadripper 3970X. On a
laptop with 8 MB of L3 that constant keeps a 12 MB clear serial when
banding would win, and on a part with larger slices it bands a clear
that would have been faster left alone (#399).
l3_slice_bytes asks the operating system instead. The quantity
wanted is not the chip’s total L3 but the share one core can reach
without crossing to another complex, which is exactly what both
platforms report: Linux names the last-level cache of cpu0 in sysfs
together with the CPUs sharing it (on the 3970X, 16384K shared by four
cores and their SMT siblings, the CCX), and macOS reports
hw.l3cachesize. Where neither answers, or answers something outside
the range any real cache occupies, the measured constant stands.
The value cannot change while the process runs, so it is read once
into a process-wide global and every later call is a lookup: 12.7 ns
against the 23 us clear of an 800x600 canvas, the smallest fill it
gates. Canvas.fill is not raises and neither is
_read_local_bands, so nothing here raises either: a failure is the
fallback, not an error.
Not a comptime value, for two reasons. This Mojo cannot evaluate
either mechanism at compile time – both num_physical_cores() and a
file read fail to interpret – and even where it could, a comptime
constant describes the machine that built the package rather than
the one running it, which is the same bug one step removed as soon as
anything is built in a container or shipped as a binary.