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