This commit is contained in:
@@ -0,0 +1,20 @@
|
|||||||
|
# Parallelism and Runtime Invariant
|
||||||
|
|
||||||
|
Compile-time optimization must not trade away execution parallelism or worsen
|
||||||
|
theoretical runtime behavior. The absence of a precise runtime measurement does
|
||||||
|
not make such a trade acceptable.
|
||||||
|
|
||||||
|
In particular, a compile-time optimization must not:
|
||||||
|
|
||||||
|
- serialize work that can execute independently;
|
||||||
|
- coarsen lane, core, batch, or scheduling granularity in a way that reduces
|
||||||
|
available execution parallelism;
|
||||||
|
- increase the theoretical runtime critical path, instruction count, memory
|
||||||
|
traffic, synchronization, or required copies merely to reduce compiler work;
|
||||||
|
- merge independently scheduled work when doing so may reduce concurrency.
|
||||||
|
|
||||||
|
Compiler representations may share analysis, planning, or code-generation
|
||||||
|
work only when the emitted execution retains the same independent work,
|
||||||
|
schedule semantics, and available parallelism. If runtime impact cannot be
|
||||||
|
measured precisely, it must be established from the transformation's semantics;
|
||||||
|
uncertainty is not permission to accept a possible runtime regression.
|
||||||
Reference in New Issue
Block a user