Reddit mentions of Computer Architecture: A Quantitative Approach

You might have some better luck if you go top down. Start out with an abstracted view of reality as provided by the computer, and then peel off the layers of complexity like an onion.

I would recommend a "bare metal" approach to programming to start, so C is a logical choice. I would recommend Zed Shaw's intro to C: http://c.learncodethehardway.org/book/

I would proceed to learning about programming languages, to see how a compiler transforms code to machine instructions. For that, the classical text is the dragon book: http://www.amazon.com/Compilers-Principles-Techniques-Tools-Edition/dp/0321486811

After that, you can proceed to operating systems, to see how many programs and pieces of hardware are managed on a single computer. For that, the classical text is the dinosaur book: http://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/1118063333 Alternatively, Tannenbaum has a good one as well, which uses its own operating system (Minix) as a learning tool: http://www.amazon.com/Modern-Operating-Systems-Andrew-Tanenbaum/dp/0136006639/ref=sr_1_1?s=books&ie=UTF8&qid=1377402221&sr=1-1

Beyond this, you get to go straight to the implementation details of architecture. Hennessy has one of the best books in this area: http://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X/ref=sr_1_1?s=books&ie=UTF8&qid=1377402371&sr=1-1

Edit: Got the wrong Hennessy/Patterson book...

https://www.amazon.co.uk/Computer-Architecture-Quantitative-Approach-Kaufmann/dp/012383872X/ref=sr_1_1?ie=UTF8&qid=1496689447&sr=8-1&keywords=Computer+architecture

If you want textbooks, Hennessy and Patterson's Computer Architecure 5th ed. is the de facto standard taught at most universities. It's a pretty good book, and shouldn't bog you down too much with equations. It won't help you evaluate components, but you will learn a lot of the underlying principles that are used in modern processors.

Yes, but computer architecture is way more than just a set of instructions. If you wanna learn computer architecture, I would recommend the Patterson book: https://www.amazon.com/Computer-Architecture-Quantitative-John-Hennessy/dp/012383872X

> Textbooks aren't much of a thing because so much information is available online and technology changes so fast.

That's

• really
  
• not
  
• true
  
  and I'm not just pointing out that those books exist. They're really good resources!

Low level stuff is pretty academic. You need textbooks just to get started.

These were my college textbooks (I have earlier editions):

Computer Architecture: A Quantative Approach

Computer Organization and Design: The Hardware/Software Interface

The material is pretty dry but if you can slog through it you will gain good insight into how and why chips and systems are designed the way they are.

Below this level is logic gate design where if you don't have a background in semiconductor physics you'd never get through it.

Hennessy & Patterson: Computer Architecture, a Quantitative Approach

Lee: The Design of CMOS Radio-Frequency Integrated Circuits

Gray et al: Analysis and Design of Analog Integrated Circuits

Coley: An Introduction to Genetic Algorithms for Scientists and Engineers

Fletcher: Practical Methods of Optimization

Not sure about EE-related topics, but for CE you're almost guaranteed to use these textbooks:

• Computer Organization: Patterson and Hennessy.
  
• Computer Architecture: Hennessy and Patterson. Same people as the computer organization textbook, but this one goes a bit deeper into architecture.
  
• Algorithms: Cormen, Leiserson, Rivest, Stein, AKA CLRS. Standard algorithms textbook for 99% of CS/ECE algorithms courses.
  
• C: Kernighan and Ritchie, AKA K&R. Ritchie is the original creator of C and a co-creator of Unix, so this content comes straight from the source.
  
• C++: Stroustrup. Like Ritchie, he's the original inventor of C++.
  
  And of course, the most important and useful textbook of them all for almost anything coding-related.

The short answer is "because it doesn't increase performance".

The long answer involves the Von Neumann bottleneck, memory wall, power wall and ILP wall. For the long story I refer to the relevant chapter in Computer architecture: a quantitative approach

Adding more cores like we've been doing with multi-cores is a stop-gap measure, allowing manufacturers to keep claiming increased performance.

This is a great start, as it explains and goes into great detail regarding cpu/gpu architectures: Computer Architecture, Fifth Edition: A Quantitative Approach

Another one that goes to low level is: Code: The Hidden Language of Computer Hardware and Software

>"He starts with basic principles of language and logic and then demonstrates how they can be embodied by electrical circuits, and these principles give him an opening to describe in principle how computers work mechanically without requiring very much technical knowledge"

-wiki

The other answer in this thread is a bit simplistic, and not quite correct in some cases.

First, let's look at where differences in IPC (instructions per cycle) can arise. In essence, all Intel and AMD CPUs are Von Neumann machines, meaning, they perform computations by reading data from memory, performing an operation on that data, and then writing the result back to memory. Each of those actions take time, more specifically cycles, to perform. Computers can read from memory using load instructions. Computers operate on data through logical instructions (add, subtract, multiply, divide, bit shift, etc.) or control instructions (conditional/unconditional branches, jumps, calls... basically instructions to control what code gets executed). Computers write data to memory through store instructions. All useful programs will use all 4 types of instructions to some degree. So in order to improve IPC, you can implement features which will speed up the operation of those instructions, at least over the lifetime of the program (in other words, they improve average performance of an instruction)

So how can you improve the operation of these instructions? Here's a crash course in (some) major features of computer architectures:

1. Pipelining: Instead of doing an instruction in 1 cycle, you can do 1/Nth of an instruction in 1 cycle, and the instruction will take N cycles to complete. Why do this? Let's say you split an instruction execution into 3 parts. Once the first 1/3 of the instruction 0 is completed on cycle 0, you can execute the 2/3 of instruction 0 in cycle 1 as well as the 1/3 of instruction 1. The overall benefit is that if you can execute 1 instruction in t time, you can execute 1/n of an instruction in t/n time. So our 3-stage pipeline can now on average do 1 instruction per cycle, but it can run 3 times faster. Practical impact: the processor frequency can be greatly increased. In this case, by 3x.
   
2. Caching: Believe it or not, loads and stores to memory take far far far longer than logical or control instructions. Well, at least without the caching optimization. The idea of caching is to keep a small, fast memory close to the processor and the larger, slower memory farther away. For example, if you sat down at your desk and wanted a pencil, where would you want to have it? On the desk? Inside the desk drawer? In your storage closet? Or down the street at the office supply store? You have a small number of things you can fit on top of your desk, but keeping your pencil there is the best if you use it frequently. Practical impact: the average time it takes to access RAM is somewhere between 50 and 120 cycles. The average time to access the L1 cache (the fastest and smallest cache) is 3-5 cycles.
   
3. Superscalar processing: Let's say that you have the following code:
   
   a = b + c
   d = e + f
   This code will form two add instructions. One key thing to note is that these two instructions are completely independent, meaning that the instructions can be performed in any order, but the result will be the same. In fact, the two instructions can be executed at the same time. Therefore, a superscalar processor will detect independent instructions, and try to execute them simultaneously when possible. Practical impact: allows the processor to reach an IPC higher than 1. Code varies a lot, but the theoretical IPC maximum for most single-thread programs is somewhere between 2-5.
   
4. Branch prediction: When we introduce pipelining, we run into a problem where we might not be able to execute the first 1/3 of an instruction because we don't know what it is yet. Specifically, if we have a control instruction, we need to complete the control instruction before we can figure out what the next instruction to execute is. So instead of waiting to finish the control instruction, we can predict what the next instruction will be and start executing it immediately. The processor will check its prediction when the control instruction finishes. If the prediction is correct, then the processor didn't lose any time at all! If it guesses incorrectly, it can get rid of the work it did and restart from where it went guessed wrong. Practical impact: modern processors predict correctly 98+% of the time. This saves many, many cycles that would otherwise be spent waiting.
   
5. Out of order / speculative processing: Building on superscalar processing, processors can try to guess on a lot of things in advance. Let's say there's a load instruction 10 instructions ahead of where the processor is currently executing. But, it doesn't look like it depends on any of the previous 9 instructions? Let's execute it now! Or, what if it depends on instruction 5? Let's guess at the result of instruction 5 and use it to execute instruction 10 anyways! If the processor guesses wrong, it can always dump the incorrect work and restart from where it guessed wrong. Practical impact: it can increase IPC significantly by allowing instructions to be executed early and simultaneously.
   
6. Prefetching: A problem with caching is that the cache can't hold everything. So if the processor needs data that isn't in the cache, it has to go to the large, slow RAM to get it. Think of like when you look in your refrigerator for milk, but you don't have any, so you have to spend time going to the store. Well, processors can try to guess about the data it will need soon, and fetch that data from RAM to put it in the cache before it need it. Think of it like realizing your milk is low, so you stop by the store and pick some up on the way home from work. That way, when you actually need the milk it will already be there! Practical impacts: prefetching can significantly reduce the average time it takes to get data from RAM, this increasing IPC.
   
   The conclusion
   Knowing exactly why AMD's architecture doesn't have the same IPC as Intel's is a bit difficult to tell, because there are necessarily no people who have access to the internal design details for both Intel and AMD simultaneously. It would be like trying to tell how someone got sick - you can come up with a lot of educated guesses and theories, but there's not really a way to tell for sure.
   
   Another reason is that many of the inventions that go into CPU microarchitectures are patentable. So it could easily be that Intel has certain patents that they are unwilling to license or AMD doesn't want to license.
   
   To put things in perspective, both Intel and AMD perform all of the above items I listed. The main difference between the two is how they are implemented. Their architectures will differ in how many pipeline stages they use, how many instructions they can execute at the same time, how far ahead they can look for independent instructions, how they decide which data to prefetch, etc. These will cause minor differences in IPC.
   
   The bottom line
   One of the larger differences between the two recently, in my opinion, has been small differences and techniques on how they implement speculation related to load instructions. Intel pulls more tricks related to trying to guess the value of a load before it is known for sure, and doing so quickly and correctly. It's hard for AMD to replicate these because the techniques are either trade secrets or patented.
   
   Edit: many of these techniques can are described in the "bible" of computer architecture:
   J. Hennessy, and D. A. Patterson. Computer architecture: a quantitative approach. Elsevier, 2011.

Ah. I would start with computer architecture before getting to systems programming then. Hennessy and Patterson is the book that (I think) most Computer Architecture classes use to teach the material. Before that, however, you may want to learn circuit basics and introductory computer organization though.

It's going to be pretty difficult material to teach yourself unfortunately. Computer Architecture is hard and requires a lot of foundational knowledge (circuits, organization, logic, etc.), but once you understand how hardware works, then you should be able to move into systems programming with more ease.

It's about 40 years too late for any one person to have mastery of all the different parts of a computer.

For computer architecture, Hennessy and Patterson is the classic volume. For the software algorithms that are used everywhere, CLRS is the classic guide. For Operating Systems, The Design and Implementation of FreeBSD is a good book. I'm sure there's something similar for networking.

You could read the PCI spec, and some Intel data sheets, and the RFCs for networking protocols if you want to learn those things. For most parts of computers, I strongly suspect that most material is either too high level (yet another "Introduction to") or too low level (reading an RFC doesn't tell you whether it's used that way in practice or has been superseded).

The only way I've gotten to know things is to play with them. Change the code, make it do something else. Personal research like that is very educational but time consuming, and there's way too much out there to know everything, even for a single small piece of hardware and its associated software.

Patterson and Hennessy's textbooks, Computer Architecture and Computer Organization and Design are pretty much the standard textbook used in every computer architecture class, everywhere.

> When we say dual core of quad core processor, what we really mean is a single integrated chip (CPU) with 2 (dual) or 4 (quad) processors on it. In the old days processors were single core so this confusion didn't arise as a single core processor was just a processor.
>

Many CPUs can be included in a single integrated die.

In "the old days" there were multi-chip modules includinged multiple CPUs (and/or other modules) in separate ICs.

> A processor consists of a control unit (CU) and a arithmetic logic unit (ALU).

And many other things, which it sometimes shares (MMUs, I/O controllers, memory controllers, etc). Don't be too picky over what a processing unit includes. For those that want to dive in, grab this or this book and read on.

> The combination of components is why just having more cores or more GHz doesn't always mean a faster CPU - As the onboard cache and other factors can also slow the processing down, acting as a bottleneck.

Bit of a superfluous contrast, these days. Using anything external to the CPU slows it down, by virtue of propagation delays alone. That's one of the reasons we want many cores / CPUs. The more CPUs or faster clocks question is a red herring - here's an article that explores why (the context is CAD, but the observations are valid in most areas of application).

Not a video/site, but Henn Patt is standard text

http://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X/

If you wanna go deeper with the hardware, this is the book my university used. It contains a lifetime of knowledge. However, it is nowhere close to the readability of Code. Where I found code to be friendly and inviting, this book is more of a grind through 100 pages in 2 months and question your existence type of thing. For OS stuff, we used this one. I'd say its a lot more friendly to read than the architecture book, but really as you go deeper into both of these subjects, they don't get friendlier.

You may like these two books and the associated lectures

The Elements of Computing Systems: Building a Modern Computer from First Principles-

[Book] (http://www.nand2tetris.org/book.php)

[Lectures] (https://www.coursera.org/learn/build-a-computer)

Computer Systems: A Programmer's Perspective-

[Book] (http://csapp.cs.cmu.edu/)

[Lectures] (http://www.cs.cmu.edu/afs/cs/academic/class/15213-s16/www/schedule.html)

Honorable mentions
[Computer Architecture, Fifth Edition: A Quantitative Approach] (https://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X/ref=sr_1_1?s=books&ie=UTF8&qid=1468739653&sr=1-1&keywords=computer+architecture+a+quantitative+approach)

[Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture] (https://www.amazon.com/Inside-Machine-Introduction-Microprocessors-Architecture/dp/1593276680/ref=pd_sim_14_5?ie=UTF8&dpID=51naTOjysjL&dpSrc=sims&preST=_AC_UL160_SR121%2C160_&psc=1&refRID=X1KV7PFRWJVZ11YZ0TJ7)

Buy this book. If you find it interesting/motivating then you'll like the general field. Because it sits at the intersection of CS and EE you'll have a toolkit that would allow you to pursue a very broad spectrum of work.

Typically companies do not publish full details about their IP, because then it would be easy to copy them and they would lose any competitive advantage they have. However, there is a remarkable amount of detail about how processors work, as many of the old techniques for branch prediction, caching and so forth are still around. There is a good (and free!) Udacity course called "High-Performance Computer Architecture" where some of these things can be learned. I can also recommend the books "Advanced Computer Architecture: A Design Space Approach" (Sima) and "Computer Architecture: A Quantitative Approach" (Hennessey & Patterson). The website Real World Tech post some very informative articles where they dive deep into the microarchitecture of Intel processors (such as this Haswell writeup) and others. Another port of call is the ecosystem of RISC-V, an open-source instruction set. They have a partial list of core and SoC implementations that you could pick through. If you fancy looking into GPUs, the book "Real-Time Rendering" (Akenine-Moller et al.) will start you off with the basics of the graphics pipeline. Both AMD and NVIDIA publish varying amounts of information about how their GPUs. The Broadcom VideoCore-IV has had full microarchitecture specs published, which you can find easily with Google.

​

If you really want to learn this stuff in detail, I would highly recommend designing a CPU/GPU and writing a simulator of it. Start by designing an instruction set, then building a very simple scalar in-order processor. Then add features such as branch prediction, register renaming, out-of-order execution and so forth. At University I wrote a CPU simulator for my Advanced Architecture class, then a cutdown GPU simulator for my Master's Thesis project. From these I managed to land an awesome job writing GPU simulators, so if computer architecture is something you want to pursue as a career I can strongly recommend completing a project like this. You will learn plenty and have something to talk about with potential employers.

Good luck!

CS 5000 - https://www.amazon.com/Object-Oriented-Programming-Java-David-Barnes/dp/0130869007

CS 5020 - https://www.amazon.com/gp/product/1449626343/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1

and

https://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X/ref=sr_1_fkmr1_1?ie=UTF8&qid=1497827601&sr=8-1-fkmr1&keywords=Computer+Architecture+Hoganson

CS 5030 - https://www.amazon.com/Modern-Database-Management-Jeffrey-Hoffer/dp/0132662256/ref=sr_1_fkmr1_1?ie=UTF8&qid=1497827653&sr=8-1-fkmr1&keywords=Relation+Database+Management+11th

CS 5060 - https://www.amazon.com/Data-Structures-Algorithms-Made-Easy-ebook/dp/B01N32J05C/ref=sr_1_6?s=books&ie=UTF8&qid=1497827689&sr=1-6&keywords=data+structures+and+algorithms

> Thanks for the comprehensive reply.

No problem.

> I'm already familiar with the basics of computer architecture, although I could certainly stand to know more. If you know of any good medium-level textbooks on that, I'd appreciate it.

I learned computer architectures using this book (but with an earlier edition): http://www.amazon.com/Computer-Architecture-Fifth-Edition-Quantitative/dp/012383872X. I think this is the same book they use in MIT.

> I realize that this is the case notionally, but I've come across posts in various places on the internet that claim compiler optimizers will sometimes inline recursive functions up to some arbitrary compiler-dependent depth so that a single stack creation can handle a recursion depth up to that arbitrary count, making the performance difference between recursion and iteration much less significant for relatively small scales. Then there's also tail recursion optimization where the recursion can go arbitrarily deep without needing to increase the stack.

You said it yourself twice:

• up to that arbitrary count
  
• can go arbitrarily deep
  
  That is the thing, because it is arbitrary, the only way you will be able to tell is to look at the compiled code and check if the recursion/iterative loop was optimized as you expect it to. Compilers have many levels of optimization. There is compile time optimization, which we are all familiar with. There is also link time optimization where optimization happens during link stage. There is also a technique performed by LLVM where the compiler creates an intermediate language bit code then perform optimization during link time based on the generated bit code. I am sure there are other optimization stages/techniques that exist on other compilers. These different levels of optimization stages use varying criteria to judge how a code will be optimized. You will need to check the resulting binary, using the optimization switches of your choice, whether the compiler's technique is used or not.
  
  > The problem is that I don't have any authoritative sources on any of these optimizer techniques, so there might be lots of useful tricks that I'm not exploiting.
  
  To be honest, many of these things are learned more through experience. You are on the right track on being curious about what the compiler does (or specifically, how it optimizes code), but in most cases, you will probably learn them through your own experiments (e.g. getting curious about whether solution y works better than solution x, then doing it, and then profiling and verifying through the internet forums).
  
  > So I guess compiler documentation is where I need to look to find these things out?
  
  Cannot say that it isn't, but I doubt compiler manuals/documentation will talk about these things in detail. It is your best bet, but most likely, you will have to go through the source code of the compiler (if it is open source), or find some white papers talking about how such optimizations are achieved by the said compiler.

I don't know of any resources on emulation in general, sorry. What aspect of emulation are you interested in? Dynamic recompilation? Binary translation? Cycle-accurate emulation?

If you're interested in cycle accurate emulation, it helps to have a background in computer architecture. H&P is a great textbook:
https://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X

Very long and unusual story which I'll have to write about some day. I'm actually a high school dropout that was already working in the technology research industry. I was already working on high performance computing (supercomputers) systems, and thought of everything that was wrong with the current systems that was out there, which lead me to learning the history and why systems were built that way. I then got deeply interested in computer architecture design, and after reading this (and many other) books, I decided I wanted to make build my own processor. I got the opportunity to start a company, and am currently working on building that business (and goof off on reddit on the side). As for what it is like, it involves 10 to 16 hours a day in front of a computer and series of whiteboards, and frequently wanting to throw that computer out the window.

I would not recommend dropping out of school in most circumstances, but the information needed to do something like this is readily available, and isn't all that complicated/expensive to do. The cheapest way to start is buying a book on Verilog/FPGAs ($20-$60... there are also ones online for free and classes on Udacity/Coursera/edX/etc), and looking into the history. Modern processor design is only 50 years old, and they were doing roughly the same thing 50 years ago with equipment that was significantly worse. Recreating a simple 8 bit ALU should take a couple of hours if you understand basic circuitry, and recreating an old 80's (16bit) processor would take maybe a week of half-assed effort while learning and making mistakes.

It varies in industry. I think it's a great idea to have a general understanding of how processors execute out of order and speculate, how caches and the cache consistency protocols between cores work, and how the language implementation transforms and executes the source you write.

The Hennesy and Patterson book covers almost everything hardware wise. Skim the areas that seem interesting to you. For language internals I like Programming Language Pragmatics. Compared to other "compiler course" textbooks like the famous dragon book it's got a lot more of the real world engineering details. It does cover quite a bit of theory as well though, and is written in a really straightforward way.

Skimming these two books will give people a pretty accurate mental model of what's going on when code executes.

I learned mostly from:

http://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X

But this has alot of information in it, and was the book for the prerequisite of the class I took that Used the above book:


http://www.amazon.com/Computer-Organization-Design-Fourth-Architecture/dp/0123744938

Just because people use other words most of the time doesn't mean one word doesn't cover the other.

Storage is memory.

If you read Hennessy & Patterson (and you should) a big feature of the book is the Memory hierarchy which includes mass storage. It even includes off-line storage.

my bachelors is in physics from a no name university in my home state of alabama. im mostly self taught when it comes to cs but i made a serious effort to learn the formalism school covers too. i was a nontraditional student (graduated age 29) and serial drop out. had kind of a hard start.

i did a bit of graduate study before i dropped out again for my current job. i did this mostly abroad at the university of oslo in the computational physics program there. they're good people, but it was just an exchange. my physics and cs interests didnt overlap with theirs sadly so the program wasnt a good fit but i felt compelled to take it because money. always been poor until recently.

i learned a lot by keeping my ear to the ground. i read a lot. things like slashdot back in the day, or hackernews, and when i found something interesting i would pull on that string. i spend several hours a day reading about peoples reactions to things i find interesting. i get bored easily and throwing a wide net is the best way to fix that. i tend to change disciplines every 6 months. recently ive just been bouncing around inside of computer vision, sometimes straying into computer graphics but not really any farther.

the thing that academia (for graduate studies) gives you is freedom to do (kinda) whatever the fuck you want with your research: for better or worse. in industry most every other aspect is better, except you probably do what your boss wants... there are some places where this is less true, but getting in to these places is not easy. (im still working on it!)

some fun links i thought of

https://gist.github.com/jboner/2841832

https://www.akkadia.org/drepper/cpumemory.pdf

there was a coursera graduate class on computer architecture from princeton. something like that. this is one of two books my university uses for undergrads:

https://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X

of course programming is not computer architecture. but it is still good to know.

i mean, do you think Euler or the other greats would have never used computers if they had access?

if you want to get a grad degree do it. i recommend computational physics, computer vision, or computer graphics. im biased, but they are all math heavy, cs heavy, and frequently deal with tricky things, like shape and probability and approximately tackling else-wise impossible tasks. these are pretty core skills. just be aware that academics tend to be pretty bad programmers and are out of touch with industry.

you dont need it but a graduate degree is probably the easiest path to the types of things i was talking about.

A college textbook. I used an earlier edition of this book and thought it was excellent:

http://www.amazon.com/Computer-Architecture-Fifth-Edition-Quantitative/dp/012383872X

Unless you're trying to squeeze every last ounce of performance out of a fixed system (e.g. say you're reprogramming the firmware for Voyager I and II), writing software to only work for a specific piece of hardware is generally a bad idea. Yeah, it's nice and interesting to know how Sandy Bridge's branch prediction or reordering buffer works, but if your code is depending on that, then you're signing yourself up for software maintenance nightmare.

As for where to learn about CPUs, go with textbooks. Go with Hennessy & Patterson. That edition is from 2011. I graduated more than a decade ago and have the 2nd edition, which talks alot about MIPS architecture. I don't know if this latest edition has recent updates. However, as my professor like to say, most of the ideas of speeding up CPUs have been invented in the 60s. It's just that fabrication technology has improved enough in recent times that allow those ideas to actually be implementable. The more recent trends are all for low power savings, clock scaling, turning on and off parts of the processor when it is not in use, so a lot of micromanaging of all the different parts of the CPU.

Wikipedia has lots of details too, but you have to know the terms to search to find the articles. Here's a few terms off the top of my head that might help you get started: Branch Prediction, mis-prediction penalty, instruction bubbles, Cache, Memory Subsystem, TLB, Register Renaming, Reorder Buffer, ALUs, execution units. Vector processors vs. Scalar processors, Super-scalar processors. SIMD (single instruction multiple data), data hazards, instruction prefetching, simultaneous multithreading (SMT) aka hyperthreading, IO virtualization.

Computer Architecture: A Quantitative Approach

This is THE classic textbook on CPU design. It was written by John Hennessy the creator of MIPS CPU who went to Stanford and David Patterson the creater of the SPARC CPU from Berkeley. I've probably talked to 50 engineers over the years and everyone used the same book. I interviewed new grads last year and they are still using the same book.

https://en.wikipedia.org/wiki/John_L._Hennessy

https://en.wikipedia.org/wiki/David_Patterson_%28computer_scientist%29


This is the current 5th edition.

http://www.amazon.com/Computer-Architecture-Fifth-Quantitative-Approach/dp/012383872X/

I used the 2nd edition back in 1997. You can get it for 1 penny used. Considering that 3 of the students I interviewed last year did the exact same 3 projects I did 18 years before I'm not sure that you need the new edition!

http://www.amazon.com/Computer-Architecture-Quantitative-Approach-Second/dp/1558603298/


There are other books on analog circuits, logic design, layout etc. I linked to a very basic intro to layout book elsewhere in the thread.

The sophomore level intro to digital logic design class used this book. This explains AND / OR gates and flip flops which are the foundation of any CPU, GPU, ASIC.


http://www.amazon.com/Contemporary-Logic-Design-Randy-Katz/dp/0201308576/

Yes. Here is the classroom bible.

My usual CS book recommendation is Foundations of Computer Science, but if you do not yet know a lot about programming, most of the material is going to be out of your reach.

Also, CS is mathy, if you're interested in learning how computers work under the hood, you want to look into computer engineering books, like Hennessy and Patterson

> I know basically nothing about x86 internals to make an accurate statement

If you're interested in learning about the internals, check out some real world technologies articles. For instance, Intel’s Haswell CPU Microarchitecture. On page 3, Haswell Out-of-Order Scheduling, it talks about the register renaming that goes on to support out-of-order execution.

It's more detail than most people really need to know, but it's interesting to understand what modern microprocessors are doing under the hood during program execution.

For anyone else reading, an even easier introduction to the topic is in the awesome Computer Systems: A Programmer's Perspective. It'll get you comfortable with the machine language representations of programs first, and then move on to basic architecture for sequential execution, and finally pipelined architecture. It's a solid base to move forward from to modern architecture articles like on real world technologies. There are more detailed treatments if you're really interested, e.g. Computer Architecture, A Quantitative Approach, but I have never read it so can't say much about it.

With all due respect (I don't own either, by the way), while you can see a correlation of "speed" by using numbers like texture fill-rates, pipelines, memory throughput and so on; they are not the whole story, and can easily mislead a prediction.

For a fun bedtime read, check out a cheap used copy/old edition of Computer Architecture: A Quantitative Approach. The book is 10% benchmarks, and 90% reasons why benchmarks can mislead you because you failed to consider X, Y, and Z. It is the bible of computer architecture.

So I'm not saying you're wrong, nor am I saying your right, I'm saying there's not enough information presented to really say either way.