3 ms·

Younger programmers may not appreciate how big a revolution the quantitative approach to computer design was. It now seems like an obvious idea: since all machi

by tlb 9y ago

Younger programmers may not appreciate how big a revolution the quantitative approach to computer design was. It now seems like an obvious idea: since all machines are Turing-complete, instruction sets and architecture should be optimized for performance across some representative workloads. Since the instruction set is one of the variables, the tasks must be specified in a high-level language and the compiler becomes part of the system being optimized. Before that, instruction sets were driven more by aesthetics and marketing than performance. That sold chips in a world where people wrote assembly code -- instructions were added like language features. Thus instructions like REPNZ SCAS (ie, strlen) which was sweet if you were writing string handling code in assembler. H&P must have been in the queue for the Turing award since the mid-90s. There seems to be a long backlog.

kps 9y ago
The VAX instruction set, and the difficulty of building a pipelined implementation, was one of the topics in the first edition of Computer Architecture. (The second edition was already a substantially different book.)
- ChickeNES 9y ago
  Hmm, now I need to track down a copy of the first edition, that sounds really interesting.
userbinator 9y ago
Before that, instruction sets were driven more by aesthetics and marketing than performance. That sold chips in a world where people wrote assembly code -- instructions were added like language features. Thus instructions like REPNZ SCAS (ie, strlen) which was sweet if you were writing string handling code in assembler. REP MOVS is still the fastest and most efficient way to do mempcy() on most Intel hardware, and likewise REP STOS for memset(), because they work on entire cachelines at once. It's worth noting that, if it weren't for a brief period of time during the late 70s/early 80s when memory was faster than the processor, RISC as we know it may have never been developed; the CISCs at the time were spending the majority of the time decoding and executing instructions, leaving memory idle, and that's what the RISC concept could make use of --- by trading off fetch bandwidth for faster instruction decoding and execution, they could gain more performance. However, the situation was very different after that, with continually increasing memory latencies and now multiple cores all needing to be fed with an instruction stream putting RISC's increased fetch bandwidth at a disadvantage. Now, with a cache miss taking tens to hundreds of cycles or more, it seems a few extra clock cycles decoding more complex instructions to avoid that is the better option, and dedicated hardware for things like AES and SHA256 obviously can't be beat by a "pure RISC". It was almost "game over" for "RISC=performance" in the early 90s when Intel figured out how to decode CISC instructions quickly and in parallel with the P5/P6, and rapidly overtook the MIPS, SPARCS, and ALPHAs that needed more cache, higher clock speeds, and power consumption to achieve comparable performance. Certainly, it makes one wonder whether, had that brief moment in time not existed and memory was always significantly slower than the processor, would CPU designs have taken a completely different direction?
- jabl 9y ago
  > REP MOVS is still the fastest and most efficient way to do mempcy() on most Intel hardware, and likewise REP STOS for memset() Would that be the original REP MOVS/STOS, or the "fast strings" (P6)? Or the "this time we really mean it fast strings" (Ivy Bridge)? Or the "honestly, just trust us this time fast strings" (Ice Lake)? > Now, with a cache miss taking tens to hundreds of cycles or more, it seems a few extra clock cycles decoding more complex instructions to avoid that is the better option You can have both, actually. E.g. RISC-V with the compressed instruction extension achieves higher code density than x86-64. > and dedicated hardware for things like AES and SHA256 obviously can't be beat by a "pure RISC" Well, if you're really looking for minimal instruction sets, RISC is way bloated; IIRC single-instruction computers can be Turing complete. Obviously they are not very useful in practice. I think a better approximation of the RISC philosophy is "death to microcode", that is, the instruction set should match the hardware that the chip has. So if your chip has dedicated HW for some crypto or hashing algorithm, I wouldn't consider it "un-RISCy" to expose that in the ISA.
- tlb 9y ago
  Behold the OSX library version of memcpy, 177 instructions long: https://gist.github.com/tlbtlbtlb/6f6fdc5154210dc72950d8ef02ca009f https://gist.github.com/tlbtlbtlb/6f6fdc5154210dc72950d8ef02.... It unrolls to 128 byte chunks. Presumably it's enough faster than REP MOVS to justify the memory footprint. I believe most libc implementations are similar, such as glibc: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/memmove.c;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=strin...
cafard 9y ago
In fairness, RISC was made feasible in part because suddenly there was more memory available. In some interview, Gordon Bell spoke of David Cutler saying, Gee, why didn't we go RISC in the first place, and Bell replying, Remember how scarce memory was? Having said that, Hennessy and Patterson definitely deserve the award.
- agumonkey 9y ago
  cafard means bug in French. just in case
wolfgke 9y ago
> since all machines are Turing-complete No real computer is Turing-complete, since it has only a finite amount of memory.
zurn 9y ago
This is indeed a powerful idea. The software equivalent is to forget about the distinct human-invented concepts of programs, input data, memory representation of data, and languages - it can all be optimized together with global visibility to all aspects. Like partial evaluation optimizations, without the partial part. Our compiler technology still has ways to go with this one.

by tlb 9y ago

kps 9y ago

The VAX instruction set, and the difficulty of building a pipelined implementation, was one of the topics in the first edition of Computer Architecture. (The second edition was already a substantially different book.)

ChickeNES 9y ago
Hmm, now I need to track down a copy of the first edition, that sounds really interesting.

userbinator 9y ago

Before that, instruction sets were driven more by aesthetics and marketing than performance. That sold chips in a world where people wrote assembly code -- instructions were added like language features. Thus instructions like REPNZ SCAS (ie, strlen) which was sweet if you were writing string handling code in assembler. REP MOVS is still the fastest and most efficient way to do mempcy() on most Intel hardware, and likewise REP STOS for memset(), because they work on entire cachelines at once. It's worth noting that, if it weren't for a brief period of time during the late 70s/early 80s when memory was faster than the processor, RISC as we know it may have never been developed; the CISCs at the time were spending the majority of the time decoding and executing instructions, leaving memory idle, and that's what the RISC concept could make use of --- by trading off fetch bandwidth for faster instruction decoding and execution, they could gain more performance. However, the situation was very different after that, with continually increasing memory latencies and now multiple cores all needing to be fed with an instruction stream putting RISC's increased fetch bandwidth at a disadvantage. Now, with a cache miss taking tens to hundreds of cycles or more, it seems a few extra clock cycles decoding more complex instructions to avoid that is the better option, and dedicated hardware for things like AES and SHA256 obviously can't be beat by a "pure RISC". It was almost "game over" for "RISC=performance" in the early 90s when Intel figured out how to decode CISC instructions quickly and in parallel with the P5/P6, and rapidly overtook the MIPS, SPARCS, and ALPHAs that needed more cache, higher clock speeds, and power consumption to achieve comparable performance. Certainly, it makes one wonder whether, had that brief moment in time not existed and memory was always significantly slower than the processor, would CPU designs have taken a completely different direction?

jabl 9y ago
> REP MOVS is still the fastest and most efficient way to do mempcy() on most Intel hardware, and likewise REP STOS for memset() Would that be the original REP MOVS/STOS, or the "fast strings" (P6)? Or the "this time we really mean it fast strings" (Ivy Bridge)? Or the "honestly, just trust us this time fast strings" (Ice Lake)? > Now, with a cache miss taking tens to hundreds of cycles or more, it seems a few extra clock cycles decoding more complex instructions to avoid that is the better option You can have both, actually. E.g. RISC-V with the compressed instruction extension achieves higher code density than x86-64. > and dedicated hardware for things like AES and SHA256 obviously can't be beat by a "pure RISC" Well, if you're really looking for minimal instruction sets, RISC is way bloated; IIRC single-instruction computers can be Turing complete. Obviously they are not very useful in practice. I think a better approximation of the RISC philosophy is "death to microcode", that is, the instruction set should match the hardware that the chip has. So if your chip has dedicated HW for some crypto or hashing algorithm, I wouldn't consider it "un-RISCy" to expose that in the ISA.
tlb 9y ago
Behold the OSX library version of memcpy, 177 instructions long: https://gist.github.com/tlbtlbtlb/6f6fdc5154210dc72950d8ef02ca009f https://gist.github.com/tlbtlbtlb/6f6fdc5154210dc72950d8ef02.... It unrolls to 128 byte chunks. Presumably it's enough faster than REP MOVS to justify the memory footprint. I believe most libc implementations are similar, such as glibc: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/memmove.c;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=strin...

cafard 9y ago

In fairness, RISC was made feasible in part because suddenly there was more memory available. In some interview, Gordon Bell spoke of David Cutler saying, Gee, why didn't we go RISC in the first place, and Bell replying, Remember how scarce memory was? Having said that, Hennessy and Patterson definitely deserve the award.

agumonkey 9y ago
cafard means bug in French. just in case

wolfgke 9y ago

> since all machines are Turing-complete No real computer is Turing-complete, since it has only a finite amount of memory.

zurn 9y ago

This is indeed a powerful idea. The software equivalent is to forget about the distinct human-invented concepts of programs, input data, memory representation of data, and languages - it can all be optimized together with global visibility to all aspects. Like partial evaluation optimizations, without the partial part. Our compiler technology still has ways to go with this one.