static_executor.hpp File Reference

Equal fixed shares, one per worker. More...

#include <cstdint>
#include <string_view>
#include <vector>
#include "orrery/backend/cpu_topology.hpp"
#include "orrery/backend/executor.hpp"
#include "orrery/backend/thread_pool.hpp"
#include "orrery/backend/worker_statistics.hpp"
#include "orrery/core/types.hpp"

Go to the source code of this file.

Classes
class	orrery::backend::StaticExecutor
	Divides the range into equal shares once and does not revisit the decision. More...

Detailed Description

Equal fixed shares, one per worker.

The scheme this phase exists to reject.

It is the obvious way to parallelise a loop and it is what most codes do: divide the range into as many equal pieces as there are threads, give each thread one, wait for them all. On a machine whose cores are alike it is very nearly optimal, and it has no scheduling overhead at all, because there is no scheduling. Each worker is told once what to do and does it.

On the target machine it is the wrong answer, for the reason section 2 of the implementation plan sets out. Four Lion Cove performance cores and four Skymont efficiency cores do not run the same code at the same rate, so equal shares take unequal times, and the region cannot end until the slowest worker finishes. The performance cores complete their share and then wait, and the whole of that waiting is throughput the machine had available and did not use.

This class is kept, and kept correct, because the claim that dynamic scheduling is worth its overhead is only worth making if the alternative was measured rather than assumed. docs/performance/threading.md reports both, and ADR-0016 records the decision that follows from the numbers. It is also the honest baseline for a machine that is not hybrid, where it should win.