By: juanrga (nomail.delete@this.juanrga.com), March 21, 2021 5:46 am
Room: Moderated Discussions
Moritz (better.delete@this.not.tell) on March 20, 2021 5:21 am wrote:
> What if you could completely rethink the general processor concept?
> There are concepts that were without alternative in the days of little memory and few transistors:
> Sequential instructions by storage address and jumps based on that address
> Implicit dependency based on above principle
> Explicit naming of storage place rather than data item
> Explicit caching into registers
> Implicit addressing of registers
> Mixing of memory, float, integer instructions in one instruction stream
> that must be analyzed to remove the assumed sequentiallity.
> The ISA used to represent the physical architecture, today that
> is no longer the case in high performance microprocessors.
> The data modifies the program flow at run-time, instead of explicitly generating the data stream
> that reaches the execution units. The CPU steps through the program issuing the data to EUs instead
> of the program explicitly generating multiple data streams with synchronization markers.
> ... and many other implications that are so "natural" to us that we can not see/name them. As usual
> we can not even question the ways, because we are so used to them. There are infinite bad ways of doing
> it, but some of those forced/obvious (legacy) design decisions of the past might no longer be that
> necessary/without alternative. Some ways that seem cumbersome and wasteful might on second thought
> turn out to be hard on the human, but open new ways to the compiler, RTE, OS, CPU removing as much
> complexity as they add, but increasing throughput or energy efficiency beyond the current limit.
Thread level speculation plus value prediction seems to be the only way to increase single thread IPC by about one order of magnitude. For the rest of code, massive parallelism.
> What if you could completely rethink the general processor concept?
> There are concepts that were without alternative in the days of little memory and few transistors:
> Sequential instructions by storage address and jumps based on that address
> Implicit dependency based on above principle
> Explicit naming of storage place rather than data item
> Explicit caching into registers
> Implicit addressing of registers
> Mixing of memory, float, integer instructions in one instruction stream
> that must be analyzed to remove the assumed sequentiallity.
> The ISA used to represent the physical architecture, today that
> is no longer the case in high performance microprocessors.
> The data modifies the program flow at run-time, instead of explicitly generating the data stream
> that reaches the execution units. The CPU steps through the program issuing the data to EUs instead
> of the program explicitly generating multiple data streams with synchronization markers.
> ... and many other implications that are so "natural" to us that we can not see/name them. As usual
> we can not even question the ways, because we are so used to them. There are infinite bad ways of doing
> it, but some of those forced/obvious (legacy) design decisions of the past might no longer be that
> necessary/without alternative. Some ways that seem cumbersome and wasteful might on second thought
> turn out to be hard on the human, but open new ways to the compiler, RTE, OS, CPU removing as much
> complexity as they add, but increasing throughput or energy efficiency beyond the current limit.
Thread level speculation plus value prediction seems to be the only way to increase single thread IPC by about one order of magnitude. For the rest of code, massive parallelism.
