Hennessy and Patterson win Turing Award(acm.org)
acm.org
Hennessy and Patterson win Turing Award
https://www.acm.org/media-center/2018/march/turing-award-2017
35 comments
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?
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?
Behold the OSX library version of memcpy, 177 instructions long: 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=strin...
I believe most libc implementations are similar, such as glibc: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=strin...
> 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.
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.
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.
Having said that, Hennessy and Patterson definitely deserve the award.
cafard means bug in French. just in case
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.)
Hmm, now I need to track down a copy of the first edition, that sounds really interesting.
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.
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.
> since all machines are Turing-complete
No real computer is Turing-complete, since it has only a finite amount of memory.
No real computer is Turing-complete, since it has only a finite amount of memory.
Who else studied with their book called "Computer Architecture" and what are your thoughts on it ?
I enjoyed that it was a simpler read then a lot of the circuits-type of books that are part of a EE/CE curriculum, but I always felt there was this lack of "hard science"/physics in the book.
And perhaps it was just not a topic they felt fit with the vision of what this book is suppose to be, and it likely came to be a better decision to abstract that part away for readability.
I enjoyed that it was a simpler read then a lot of the circuits-type of books that are part of a EE/CE curriculum, but I always felt there was this lack of "hard science"/physics in the book.
And perhaps it was just not a topic they felt fit with the vision of what this book is suppose to be, and it likely came to be a better decision to abstract that part away for readability.
I read both Computer Architecture and Computer Organization and Design in college and I really enjoyed them.
I would recommend COaD to any beginner who wants to learn some basic concepts of computer design (and if working with FPGAs why not build one).
CA deals with more advanced concepts but doesn't overwhelm you with math and circuit theory (as you noted) so it's a natural progression (from COaD). I think something more advanced and "hard science" should be part of a post-graduate curriculum
I would recommend COaD to any beginner who wants to learn some basic concepts of computer design (and if working with FPGAs why not build one).
CA deals with more advanced concepts but doesn't overwhelm you with math and circuit theory (as you noted) so it's a natural progression (from COaD). I think something more advanced and "hard science" should be part of a post-graduate curriculum
I strongly prefer Computer Organization and Design over their Computer Architecture book. I had to read both while at Berkeley. I've considered picking up the new RISC-V edition of the former but I can't justify spending that kind of money when RISC-V is so similar to MIPS. Could be a fun bit of history if RISC-V ever takes over :-)
I read these two as well. Computer Organization and Design and Computer Architecture on my 2nd and 3rd-level computer architecture courses respectively. Glad to hear Hennessy and Patterson getting the Touring award, always had a good hunch about Computer Architecture despite not knowing as much back then.
I thought it was a great book because it proposed sensible benchmarking strategies and applied them thoroughly. That seems like a good way to determine things like how much better 8-way set associative caching is than 2-way.
It's a long time since I read it, but from my memory that's the kind of thing the book is about. I'm not sure how you'd determine those kinds of things in a more "hard science"/physics fashion.
It's a long time since I read it, but from my memory that's the kind of thing the book is about. I'm not sure how you'd determine those kinds of things in a more "hard science"/physics fashion.
I think that's because in a full EE/CE program you would have some earlier course that covered that based on a book like Sedra/Smith "Microelectronics" (but disclosure, I was CS so most my EE is self acquired)
When I was in grad school, we used the 4th Edition in the Senior/Masters level computer architecture class. I still have it on my book shelf. I've re-read large chunks of it a number of times in the past 10 years (often inspired by making sure my bases are covered during job interviews).
Given that most of my career has been pretty far removed from the compiler/assembly instructions, much of the content wasn't directly relevant to what I've been doing, but I still find myself using many of the tools that are outlined in the first chapter ("Quantitative Principles of Computer Design") when dealing with performance problems or analysis in high-level-language-world, which happens pretty often.
Given that most of my career has been pretty far removed from the compiler/assembly instructions, much of the content wasn't directly relevant to what I've been doing, but I still find myself using many of the tools that are outlined in the first chapter ("Quantitative Principles of Computer Design") when dealing with performance problems or analysis in high-level-language-world, which happens pretty often.
The only issue is that I am hoarding a bunch of copies of the original Computer Architecture editions as the comparisons between the architectures of the day are quite valuable.
I'm currently using it for my Computer Architecture class(MIPS edition). It's rather unfortunate that I'm just grokking the book for the grades, it's a very good book and explains a lot of concepts quite well. I may not grasp it the first time I read a section, but after going over it, I almost always understand.
We used Computer Organization and Design in college. Great book, did well in the class, felt I had a grasp of the material.
But man, 6 months out and I retained nearly nothing. It's just so esoteric and not very relevant to my every day schoolwork(then) and career(now) that it's slowly seeped out of my brain.
But man, 6 months out and I retained nearly nothing. It's just so esoteric and not very relevant to my every day schoolwork(then) and career(now) that it's slowly seeped out of my brain.
It is one of the classics as far as I'm concerned. Anyone doing systems work should read it.
Two years ago, David Patterson interviewed John Hennessy for Communications of the ACM. They discuss the changing job landscape, MOOCs, and the future of education.
https://doi.org/10.1145/2880222
https://doi.org/10.1145/2880222
Thanks for the link. Full interview at https://vimeo.com/146145543
Really happy about this! Their book "Computer Architecture" (along with Tanenbaum's book) played a huge role in my development as an engineer.
Interestingly, four Turing Award winners are now affiliated with Google: Vint Cerf, Ken Thompson, John Hennessy and Dave Patterson.
MSR has a few also (Lamport, Lampson, Thacker, Gray), though ATM a couple are deceased. Supposedly there is a fifth one, but I can't figure it out (must have gotten the award before entering MSR).
MSR also has Tony Hoare.
Hats off to Patterson
In a just world, they'd also be as well-known as Bill Gates and Steve Jobs.
John Hennessy was the president of Stanford is now the Executive Chairman of Alphabet. He has been and is being well rewarded for his work.
I think most famous people find being famous a burden, so I'm not sure they're missing out by being well known only among people who can actually understand their accomplishments.
Different business segments.
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.