Optimizers need a rethink
Modern compilers and database query planners increasingly act as opaque “black boxes” whose optimizations are both essential for performance and too unreliable to depend on explicitly. Commenters argue that when a performance property becomes load‑bearing, it should be expressed and guaranteed at the language or tooling level (e.g., value types, no‑GC regions, constant‑time code) rather than left to heuristics, and they call for better ways to inspect, constrain, or even formally verify optimizations. Others note that traditional compiler gains are tapering off, suggesting research and tooling should shift more toward programmer productivity, transparency, and correctness than ever more intricate automatic optimizations.
Optimization vs Language Semantics
- Several comments argue that once an “optimization” is guaranteed, it effectively becomes part of the language or library semantics (e.g., mandatory RVO, guaranteed tail calls, value types).
- Others emphasize keeping behavior and performance specs separate: a simple semantic model plus a separate, stable performance contract is seen as valuable but hard to maintain.
- Unreliability is framed as intrinsic to optimizations; if users must rely on something, it should be promoted into the language design rather than left to heuristics.
Need for Guarantees and User Control
- Many participants want “assert-style” controls: annotations or pragmas that either guarantee a transform (inline, no allocation, vectorization, constant time) or fail compilation.
- There is frustration with opaque optimizer behavior (e.g., -ffast-math changing behavior, autovectorization hit-or-miss, inlining hints ignored).
- Some see load‑bearing optimizations (no-GC, tail calls, escape analysis) as language-design bugs if not guaranteed; others stress the complexity and slowness of adding such features.
Verification, Security, and Constant Time
- Multiple comments describe work on formal equivalence proofs from spec → C → machine code, inspired by seL4, aiming to reduce effort via SMT/model checking.
- Optimizer bugs are reported as having introduced timing side channels in cryptographic code; this motivates user-guided or extensible optimizers and better ways to express timing constraints.
- Hardware and languages rarely provide constant-time guarantees; some see this as primarily a language-design problem, others as a hardware and tooling gap.
Databases and Query Planners as Analogy
- SQL planners are compared to compiler optimizers: powerful but unpredictable, often forcing users to read plans and fight heuristics.
- Some want the ability to “freeze” or explicitly specify query plans or receive stable plan identifiers/metrics; others note vendors already offer “frozen plans” or similar.
- There’s tension between dynamic re-planning (good for changing data) and reproducible performance.
Debugging, Tooling, and Complexity
- Optimizations make debugging hard; mapping optimized code back to source is likened to reconstructing a cow from hamburger.
- Suggestions include better optimization reports, performance regression testing, plan/IR lockfiles, and tiered language/implementation “levels.”
- Commenters note diminishing gains from traditional optimizers (referencing Proebsting’s law), suggesting future effort may be better spent on programmer productivity and verification rather than ever-more-complex heuristic passes.