4 ms·

you should just write compilers. I wish processors would remove some features to save power such as OoO and defer it to compiler instruction scheduler.

stephencanon 10y ago
While it's not my day-to-day job, I've been an occasional contributor to llvm and clang for almost a decade (though most of my more significant contributions have been in the form of behind-the-scenes conversations with folks who are more regular contributors).
AstralStorm 10y ago
Static scheduling has been tried in VLIW architectures, such as Itanium. You got both worse assembly too understand, compiler that is hard to write and finally worse performance. Essentially you also lose they advantage of runtime optimization Compare plain java compiler with a java JIT compiler.
- stephencanon 10y ago
  That's a bit of an oversimplification; static scheduling is used in extremely low-power architectures (The ARM Cortex-M series, for example), as well as GPUs and DSPs. It has its uses. However, the evidence is pretty compelling that it's not a great fit for "conventional" CPUs doing latency-sensitive tasks. It's a good fit for low-power single-issue architectures and DSPs, because ... well, there's only trivial scheduling to be done because the machine is so dead simple. It's a good fit for GPUs because they are primarily throughput oriented, and can make scheduling issues "go away" by running lots of threads / warps / whatever marketing wants to call them to hide latency.
  - 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 ago
      The 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 ago
        Something 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.

stephencanon 10y ago

While it's not my day-to-day job, I've been an occasional contributor to llvm and clang for almost a decade (though most of my more significant contributions have been in the form of behind-the-scenes conversations with folks who are more regular contributors).

AstralStorm 10y ago

Static scheduling has been tried in VLIW architectures, such as Itanium. You got both worse assembly too understand, compiler that is hard to write and finally worse performance. Essentially you also lose they advantage of runtime optimization Compare plain java compiler with a java JIT compiler.

stephencanon 10y ago
That's a bit of an oversimplification; static scheduling is used in extremely low-power architectures (The ARM Cortex-M series, for example), as well as GPUs and DSPs. It has its uses. However, the evidence is pretty compelling that it's not a great fit for "conventional" CPUs doing latency-sensitive tasks. It's a good fit for low-power single-issue architectures and DSPs, because ... well, there's only trivial scheduling to be done because the machine is so dead simple. It's a good fit for GPUs because they are primarily throughput oriented, and can make scheduling issues "go away" by running lots of threads / warps / whatever marketing wants to call them to hide latency.
- 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 ago
    The 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 ago
      Something 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.