3 ms·
Technically compiler will have more information about the program than processor will ever have. And vice versa, compiler could not know (or very hard to) more
by flamedoge 10y ago
Technically compiler will have more information about the program than processor will ever have. And vice versa, compiler could not know (or very hard to) more than processor about real time info. If the performance is at steady-state, then I don't see why static insn scheduler wouldn't work given sound methodologies.
Old Intel Atoms also used to lack OoO execution.
- stephencanon 10y agoThe biggest problem is that static scheduling requires recompiling your program for every micro-architecture. Anytime you change the latency of one instruction, or add an execution unit, etc, you need to recompile in order to get close to optimal performance. That's OK for some uses (Hello Gentoo Users and Other Genuine Humans), but an enormous hassle for most use cases -- the upshot is that most statically-scheduled code is non-optimal most of the time, and OoO eats its lunch. The second biggest problem is that cache residency is often not statically predictable, which means that you generally have no idea in what order the various memory dependencies will actually be satisfied, which makes all your effort on scheduling approximately useless. Those older Atoms were pretty universally terrible, by the way.
- flamedoge 10y agoSomething like tracing JIT within limited window of instructions could be the solution. Agreed that dynamism must be part of the solution for real data. Whether it's done on JIT or HW, there needs to be some feedback mechanism, ie. Perf Monitoring Unit on Intel X86. Agreed.