Reiner Pope – Chip design from the bottom up

New blackboard lecture with Reiner Pope: how do chips actually work - starting with basic logic gates, and working up to why GPUs, TPUs, FPGAs, and the human brain each look the way they do. Reiner https://reiner.org/ is CEO of MatX https://matx.com/, a new chip startup (full disclosure - I’m an angel investor). He was previously at Google, where he worked on software https://arxiv.org/abs/2211.05102 efficiency https://jax-ml.github.io/scaling-book/, compilers, and TPU architecture. Watch this one on YouTube https://youtu.be/oIk3R-sMX5o so you can see the chalkboard. Read the transcript https://www.dwarkesh.com/p/reiner-pope-2. Sponsors * Crusoe https://crusoe.ai/dwarkesh was one of only five GPU clouds that made the gold tier in SemiAnalysis' most recent ClusterMAX report. Gold-tier providers like Crusoe delivered 5-15% lower TCO than silver-tier clouds, even with identical GPU pricing. This is because optimizations like early fault detection and rapid node replacement don't necessarily show up in the sticker price, but still matter a ton in the real world. Learn more at crusoe.ai/dwarkesh https://crusoe.ai/dwarkesh * Cursor https://cursor.com/dwarkesh is where I do most of my work—from reading research papers to visualizing technical concepts to coding up internal tools for the podcast. Most recently, I used it to build two different review interfaces for my essay contest, one that anonymizes submissions for scoring and another that lets me see applicants' essays next to their resumes and websites. Whatever you're working on, you should try doing it in Cursor. Get started at cursor.com/dwarkesh https://cursor.com/dwarkesh * Jane Street https://janestreet.com/dwarkesh let me ask Ron Minsky and Dan Pontecorvo, two senior Jane Streeters, a bunch of questions about how they use AI. We discussed everything from the types of models they're training to how they think about the future of trading to why they're more bullish than ever on hiring technical talent. You can watch the full conversation and learn more about their open positions at janestreet.com/dwarkesh https://janestreet.com/dwarkesh Timestamps 00:00:00 – Building a multiply-accumulate from logic gates 00:16:31 – Muxes and the cost of data movement 00:26:10 – How systolic arrays work 00:39:11 – Clock cycles and pipeline registers 00:51:51 – FPGAs vs ASICs 01:03:25 – Cache vs scratchpad 01:07:27 – Why CPU cores are much bigger than GPU cores 01:12:00 – Brains vs chips 01:15:33 – A GPU is just a bunch of tiny TPUs This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.dwarkesh.com https://www.dwarkesh.com?utm_medium=podcast&utm_campaign=CTA_1

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Dwarkesh Patel?

  I'm back with Ryan or Pope, who is the CEO of Maddox, which is a new AI chip company. Last time we were talking about what happens inside a data center. Now I understand what happens inside an AI chip. How does a chip actually work? Full disclosure, by the way, I am an angel investor in Maddox. So hopefully you have designed a good chip.

• 0:20Dwarkesh Patel?

  Also, if you're listening to this on an audio platform, it's much preferable to watch this blackboard lecture on a platform where you can see what's happening. So switch over to YouTube or Spotify.

• 0:31Speaker 01

  So I'll start with sort of the very smallest fundamental unit of chip design, and we'll sort of build up into what an overall, like actual production chip, what are the components of that? At the very bottom level of a chip, the primitives that we work with are logic gates, which are very simple things like and or not. And then these are connected together by by wires that have to be laid out physically as metal traces on a chip. The main function that AI chips want to compute is multiplication of matrices. And really inside that is the fundamental primitive is multiply accumulator, just like of pairs of numbers. So we're going to sort of demonstrate what that calculation looks like by hand,

• 1:14Speaker 01

  and then sort of infer what what a circuit would look like for that. It'll turn out to be sort of easiest if I do multiplication accumulator, something like a four bit number with another four bit number. And then we're going to, the actual clearest primitive is actually multiply accumulate. So there's a multiply these two terms. And then we're going to add in. So product of these two terms. And then we're going to add in an eight bit number.

• 1:51Dwarkesh Patel?

  And can I ask a clarifying question? Why is this the natural primitive for, you know, whatever computation happens inside a computer?

• 2:02Speaker 01

  Yeah, so there's a few reasons for this. It's a little bit more efficient. But the reason it's natural for AI chips is that if you look what's happening during a matrix multiply, the what is matrix multiply in very short? It is there's a for loop over I and over J.

• 2:24Dwarkesh Patel?

  Yep.

• 2:24Speaker 01

  And over K.

• 2:28Speaker 01

  Of output i k plus equals to input i j times other input j k. And so multiply accumulate happens at every single step of a matrix multiply.

• 2:48Dwarkesh Patel?

  Makes sense.

• 2:49Speaker 01

  And then the other observation is that the precision will almost always be higher in the accumulation step than in the multiplication step. This is maybe specific to AI chips, but you're multiplying low precision numbers. But then when you accumulate errors accumulate quickly and so you need more precision here. So this is why we've chosen to do a four bit multiplication and an eight bit addition.

• 3:09Dwarkesh Patel?

  Let me make sure I understood that. There's two ways to understand that. One is that the value will be larger than the inputs. And the other is that if it was a floating point number, it would be maybe that that part is like less intuitive to me, but it's maybe the same principle.

• 3:25Speaker 01

  It is really the same principle. I guess the sort of, I mean, I guess the separate principle is that as you are summing up this number, you are summing up a whole bunch of numbers. And so you've got a lot of rounding errors accumulating. Whereas in this case, there's like, there's, there's only one multiplication in that chain. And so there's not a lot of rounding errors accumulating in the multiplication.

• 3:43Dwarkesh Patel?

  Why are you summing up a whole bunch of numbers? It's just two numbers, right?

• 3:45Speaker 01

  Just, I mean, the summation happens, it's repeated j many times.

• 3:49Dwarkesh Patel?

  So yeah, any errors accumulate. I see. Yep, makes sense.

• 3:52Speaker 01

  So how would we perform this calculation by hand? I mean, as a human, we would probably separate it into two, but we can sort of do it all in one using long multiplication. So the multiplication term first, we're going to multiply this number, this four bit number here by every single bit position in the other four bit number. So we write that out first 1001 multiplied by this bit position.

• 4:21Speaker 01

  That is this number itself. Then shifted across by one, we're multiplying by zero. That gives us an all zeros number.

• 4:31Speaker 01

  Shifted across even one more to multiply by this one. We get 1001.

• 4:39Speaker 01

  And then finally, for this last last bit position, we get an all zeros number again.

• 4:47Speaker 01

  So this sort of gives us a bunch of terms that we're going to have to add for the multiplication. And then while we're doing that summation of this, we might as well add in the actual accumulator term as well. And so we just copy that directly across.

• 5:09Speaker 01

  So this is the sum. It's a five-way sum that we're going to want to compute.

• 5:17Speaker 01

  So firstly, what logic gates did it take us to even get to this intermediate step? We needed to produce all 16 of these partial products. How do I produce one of these partial products? So let's take this number one, for example, here. It is one. So how do we produce this number? By multiplying this number by this one over here. We can actually produce that by an AND gate. This number is one if both this bit is one and this bit is one. If either of them is zero, then the multiplication of 0 times anything is zero. So to produce all of this stuff, we ended up consuming 16 AND gates.

• 6:00Speaker 01

  Or in the general case, if I were doing a like a P bit multiply times a Q bit multiply, then this will be like P times Q, many ANDs.

• 6:17Dwarkesh Patel?

  Exactly.

• 6:21Speaker 01

  Finally, I sum them. Actually, most of the work is going to happen in the summing. And so let me describe sort of the other logic gate that we use here. AND is almost the simplest logic gate that exists on a chip. It's almost the smallest.

• 6:37Speaker 01

  At the other extreme, typically, the very largest logic gate that you'll use is something called a full adder.

• 6:47Speaker 01

  And what this does is sort of it does like coming from software, you might think that a full adder adds 32 bit numbers together. In this case, it just adds three single bit numbers together. And so you can think of it as like adding 0, 1, and 1 together.

• 7:01Speaker 01

  Now, when I add these together, the result can be 0, 1, 2, or 3. So I can express that in binary using just 2 bits. So it has input, it has 3 bits, and as output, it has 2 bits, which in this case are 1, like the number 2 in binary is 1, 0. So this is also known as a 3 to 2 compressor.

• 7:26Speaker 01

  Because it takes 3 bits of input and produces 2 bits of output.

• 7:30Dwarkesh Patel?

  The 2 inputs are an x and a y value, and then some carry that came in from like...

• 7:37Speaker 01

  The, sorry, the 3 inputs are all bits that are in the same sort of bit position, like 3 bits that are in a column here.

• 7:45Dwarkesh Patel?

  Yeah.

• 7:45Speaker 01

  And then the 2 outputs, I have sort of drawn them vertically here and horizontally here to kind of match this vertical versus horizontal layout here, which is expressing that things that are in the same column are in the same like bit position.

• 7:58Dwarkesh Patel?

  Yeah.

• 7:59Speaker 01

  Whereas things that are in adjacent columns, like this is a carry out, whereas this was the sum.

• 8:03Dwarkesh Patel?

  So if the inputs in the full adder are, for say, like 1, 0, 1, then the output would still be 1, 0. If it was 1, 1, 1, it'd be 1, 1. If it was 0, 0, 0, it'd be 0, 0. If it was like 0, 1, 0, it'd still be 0, 1.

• 8:17Speaker 01

  So yeah, it's just counting essentially the number of things and expressing that in binary.

• 8:23Speaker 01

  So this circuit actually can sort of capture what we as humans naturally do when we're doing something along a column. So I can show that sort of, I'll show you sort of one iteration of using the full adder to sum. The way I sum here is going to be a little bit unnatural for humans. Humans, we would sort of sum along the column and then remember the carry. But instead of remembering the carry, we'll actually just explicitly write it out. So in this, we proceed from the rightmost column towards the left. On the rightmost column, we sum the 1 and the 1, and that produces like a 0 here and a carry of 1. So we've sort of used this full adder circuit on this pair of bits and produced a pair of bits as output.

• 9:10Speaker 01

  Now, we can do the same thing with this column. We've got a column of 1, 2, 3, 4 numbers. And so maybe we'll like take the first 3 of them, run a full adder on them, and that gives us a 0 and a 0 as output. So like the sum of these is 0, 0. So that's the full compressor, uh, full adder applied to all of these bits. As I've used up bits, I'm going to sort of just cross them out to indicate that I've handled them. Let's just keep going a little bit more. So we'll go here. I'll take these 3 numbers, I add them, that gives me a 1 and a 0. I've dealt with these 3 numbers. And now I take 1, 2, and I can even take these 3 numbers, for example, right now,

• 9:52Speaker 01

  and add them, and that gives me a 1 and a 0, and I've dealt with these numbers. So I can sort of, like, the way I should view this is that I have this whole grid of numbers that need to be added. I'm going to just keep applying full adders to all the bits that are here, constantly removing 3 numbers from a column and then writing out 2 numbers as output. Keep going with this over and over and over and again, until I eventually get like some, just 1 single number coming out here. Something like that. This is probably the wrong sum. So this approach that I've described here, this is called a

• 10:32Speaker 01

  data multiplier. And this is sort of like the standard for how you do area efficient multipliers using full adders. Let's try and quantify the circuit size of this, just so we have got a sense of like how big things are, so we can compare to them later. How many full adders did I use? I started with, how many numbers? I have the 16 partial products, which is the product of all of these terms with all of these terms, plus the 8 terms that I'm adding here. So I started off with 24 bits.

• 11:17Speaker 01

  And then I produced eight bits on the output eventually. And in every step, I was sort of crossing off three numbers and writing two numbers out as a in result. And so every single use of a full adder eliminates one of the bits here. And so how many full adders it must be the 24 minus the eight. So that there were 16 full adders in this circuit. In general, this is true in the general case as well. There will be P times Q many full adders in this circuit.

• 11:47Dwarkesh Patel?

  Are you sure I understand the logic of that? So the input bits 24 is P times Q plus P plus Q.

• 11:56Speaker 01

  That's right.

• 11:57Dwarkesh Patel?

  And the output bits is just P plus Q. And so P times Q plus P plus Q minus P plus Q equals P times Q.

• 12:08Speaker 01

  That's right. So I think this explains sort of, or at least hints that the second reason why we chose to do a multiply accumulate. First reason being that's actually what shows up in matrix multiplication. But second reason being it gave us this very slick P times Q, very simple algebra.

• 12:28Speaker 01

  So we've sort of described like this, this whole procedure, every single atomic step that I took here becomes a logic gate. And then sort of the wires connected together. Like when I had these three inputs that that I salvaged to produce these two outputs, like if I think of mapping this to a physical device, there would be a wire that runs sort of connecting all three of these things together into a logic gate that produced this output.

• 12:53Speaker 01

  Okay, so this is the the main primitive at different bit widths that that is that is inside an AI chip. We're going to build up from here to how would you use that to run all of the other operations you may want?

• 13:08Dwarkesh Patel?

  This might be the wrong time to ask this question, but whenever Nvidia reports that this chip can do X many FP4 or half as many FP8, it seems to imply that those circuits are fungible, that there's not as dedicated like FP4 versus FP8. But the way you're mapping it out here, it seems like you would need, if it has to be mapped out in the logic, you would need a dedicated FP4 multiply accumulate and then a dedicated FP8 accumulate?

• 13:41Dwarkesh Patel?

  Basically, can you can you fudge them?

• 13:44Speaker 01

  As drawn, they're actually not particularly fungible. This is actually one of the main choices you have to make when designing a chip, which is how much of FP4, how much of FP8 do I have? And then sometimes I'll make that consideration from the point of view of like, what do I think is the customer requirement? Another way to take an angle on that is to say, what is the what is the power budget for? Equalize the power budget between FP4 and FP8.

• 14:05Dwarkesh Patel?

  But so then when they report those numbers, and they just happen to be the case that like, it does 2X as many FP4 as FP8. They just happen to choose like, give equivalent diareas to all the floating points? And as a result, that ended up being?

• 14:21Speaker 01

  Like, why is the ratio exactly 2X?

• 14:22Dwarkesh Patel?

  Yeah, exactly.

• 14:23Speaker 01

  Yeah, so part of it is, I mean, surely that won't be exactly like exactly equivalent diarea. There's a data movement reason, actually, and we'll maybe come back to this when we sort of look through how it goes into and out of memories. There's something really nice, just from a software level, of the fact that I can pack two 4-bit numbers into the same storage as an 8-bit number. And so when I store that to a memory or something like that, it's the sizing of the buses that I wire within the chip that actually makes that work out really nicely.

• 14:55Dwarkesh Patel?

  Actually, come to think of it, it's not just 2X. It would be

• 15:00Dwarkesh Patel?

  the amount of area it takes, it sounds like, is quadratic.

• 15:05Speaker 01

  It's quadratic, in fact.

• 15:06Dwarkesh Patel?

  With the bit length. So that's why smaller precision is like even more favorable.

• 15:12Speaker 01

  There's a really big reason. So, in fact, Nvidia made a change. Historically, up until B100 or B200, every time you have the bit precision, you double the flop count. That ratio is exactly like, for the reason you said, because of this quadratic scaling, that ratio is actually slightly wrong. It should be like an even bigger, you should get an even bigger speedup than you than you might otherwise think. Nvidia's like product specs have sort of started acknowledging that in B300 and beyond, where the FP4 is three times faster than the FP8.

• 15:47Dwarkesh Patel?

  Though it should be 4X.

• 15:49Speaker 01

  Yeah, what I've shown here is like the simplest case of integer multiply. When you're when you're dealing with floating point as you do in FP4 and FP8, there's this sort of other term, which is the exponent that just complicates this calculation. So what can we see already from this? It's like, I think the big observation you've made is that there's this quadratic scaling with bit widths, which is like very effective and is the single reason why low-precision arithmetic has worked so well for neural nets.

• 16:19Speaker 01

  But the other thing we're going to do now is we're going to compare sort of the area spent on the multiplication itself with all of the circuitry that is around it.

• 16:29Speaker 01

  So we'll walk back in time a little bit and see how did GPUs prior to tensor cores work, which is the same way as the way that CPUs worked, in fact. So which is like, where do we stick this multiply accumulate unit? So generically, I'll describe like a CUDA core or a CPU. You'll have some register file,

• 16:57Speaker 01

  which stores some number of entries, maybe it's like eight entries

• 17:04Speaker 01

  of like, in this case, I guess, four bit numbers, but typically like 32 bit numbers or something like that, which are not numbers. So this is the like, inside the CUDA core, I'll have some register file of some depth. And then I will have my multiply accumulate circuit, multiply and accumulate circuit.

• 17:25Speaker 01

  And what it's going to do, it's going to like, it's going to take three arbitrary registers from this register file, perform the multiply accumulate, and then write back to the register file.

• 17:35Speaker 01

  So it's going to maybe write to this one, but it was able to read from this one, this one, and another random one. So it'll take three inputs like this.

• 17:46Speaker 01

  So this is the core data path of many processes. Most processes look like this. You've got some set of registers and then you've got some set of logic units or ALUs.

• 17:59Speaker 01

  We want to analyze the cost of the data movement from the register file to the ALU and back.

• 18:07Speaker 01

  So ultimately, there's going to be some circuit that says, well, I don't always have to select this guy. I might select any of the registers in any point in time. And so a first question is, how can I build a circuit? The circuit that I'm going to look for is a mux. So in this case, it's going to have eight inputs, one from each entry of the register file. And it's going to have one output, which is actually producing this output.

• 18:36Speaker 01

  And then, like, what is the cost of this thing? It's like, all we have to build it out of is and and or. And so how do we build it? We do the dumbest thing possible. We like form a mask saying, okay, when we want to read like the third entry, we're going to and every single entry with either 1 or 0, based on whether that's what we want to read. And then we're going to or all of them together.

• 19:01Dwarkesh Patel?

  Okay, just to make sure I understand the basics. What the mux is doing is just like selecting.

• 19:05Speaker 01

  Just selecting.

• 19:06Dwarkesh Patel?

  Just selecting an input.

• 19:08Speaker 01

  Yeah, so like invisible to software is like you say, I want input number three. That means there's a mux.

• 19:12Dwarkesh Patel?

  Yeah.

• 19:13Speaker 01

  And so like, what is the cost of this mux? So an n input mux

• 19:21Speaker 01

  operating on p bits.

• 19:26Speaker 01

  Well, I'm going to.

• 19:30Speaker 01

  So I have n rows, that's this eight rows, and I've got like each row is p bits wide. Well, I have to and every single bit. So I get n times p many and gates. Every single input, I have to say, am I going to like mask it out or not? And then, and then I'm going to or them all together. And so there's going to be like n minus 1 times p many or gates.

• 19:55Speaker 01

  Which is saying, I've got all of these different things, almost all of them are zeros, but I need to sort of collapse them down into, into like from my eight options down into one option. And so every step I need to or like one row into, into an existing row.

• 20:09Dwarkesh Patel?

  Got it, yeah. It's actually kind of funny that you would sort of, you don't think at the level of hardware, you sort of just think like, oh, I'll just select element three and something as simple as that is a sort of like, in and of itself, a quite complicated circuit.

• 20:24Speaker 01

  Yeah, I mean, this is the first step of all of the hidden data movement costs that the shop, yeah.

• 20:29Speaker 01

  And so like the thing, like we're, we're just going to like compare, like I have to pay this cost and I've got one marks here and then in fact I have two more copies of that for each of the three inputs to my multiply accumulate operation. And so I have this cost, which is like, like three times N times P and gates over here compared to this P times Q, like sort of gates in the actual circuit that I, that is doing the thing I care about.

• 20:57Speaker 01

  And if we plug in actual numbers like this N being eight, like I get like 24 times P gates over just, just in the data movement compared to like if Q is four, like four times P gates just in the, in the adder, multiply adder.

• 21:14Dwarkesh Patel?

  And sorry, where is the three coming from?

• 21:16Speaker 01

  Three different inputs here.

• 21:18Dwarkesh Patel?

  Got it, yeah.

• 21:20Speaker 01

  So the case I like really just what I'm hinting at here is that like all of this work, which scales like as, as the size of the register file, and this is a very small register file, all of this work, just moving the data from the register file to the, to the, to the logic unit

• 21:36Speaker 01

  is many, many times more expensive than the logic unit.

• 21:39Dwarkesh Patel?

  In the most recent ClusterMax report, Semi Analysis ranked almost 100 different GPU clouds. Crusoe was one of only five that made the gold tier. Semi Analysis found that gold tier providers like Crusoe had a total cost of ownership those five to 15% lower than silver tier ones, even when they had identical GPU pricing. This makes sense because total cost of ownership is downstream of a bunch of different things that don't necessarily show up in the sticker price, but that Crusoe has optimized. Things like how well you detect faults and how quickly you replace failed nodes. For example, Crusoe was one of the first clouds to adopt Envy Sentinel, Nvidia's own GPU monitoring and self-healing software for enhanced GPU uptime, utilization, and reliability. This sets Crusoe to make use of everything that Nvidia has learned about why chips fail

• 22:24Dwarkesh Patel?

  across all their different fleets and deployments so that Crusoe can catch faults earlier in the process. And once they identify a failure, Crusoe can swap in a healthy node in less than 10 minutes. Because they're not running bare metal, Crusoe doesn't have to spend time installing an operating system or configuring drivers. They can just spin up a new VM on an already running and pre-qualified host. If you want to learn more about this or the other reasons that Crusoe made gold tier, go to crusoe.ai/thoracash. It may be helpful to just see what a mux looks like, maybe like a 2-bit or 4-bit mux.

• 22:57Speaker 01

  Yeah, great. So we'll take some inputs. We'll have maybe like, we'll just do a two-way mux. So we've got two different numbers.

• 23:10Speaker 01

  We've got these two inputs. And then we have a, so these are the inputs that are being selected between. And then we have a selector,

• 23:24Speaker 01

  which says, which can either be like, I want this one, or it could be, I want the other one. So this is a one-hot encoding.

• 23:35Speaker 01

  So this is what we all start with.

• 23:40Speaker 01

  And then the output we want to produce, like, let's focus on this case. So this is the actual input we got.

• 23:46Dwarkesh Patel?

  Yeah.

• 23:48Speaker 01

  We just want to produce this guy as the result. And so, like, sort of very laboriously what we do is we and this bit with all of these. And so that produces like adding this bit with this row. And likewise, we and this bit with this row. That produces all zeros.

• 24:09Speaker 01

  So this was the, there's four ands here.

• 24:14Speaker 01

  There's four ands here.

• 24:17Speaker 01

  And then finally, we just or these two together. This gives a 1, we or these two together, this gives a 1. We or these two together, gives a 0. We or these two together, and it gives a 1. And so this is the four ors.

• 24:32Speaker 01

  So like this actually ends up looking a little bit like addition. In fact, like we did exactly the same set of ands here. Sort of we've added all of these things together. But then instead of collapsing it by using these full adder circuits, we just could get a very simple collapsing with or gates.

• 24:49Dwarkesh Patel?

  And I guess that doesn't look like n times p.

• 24:52Speaker 01

  So yeah, so this was with n equals 2 inputs.

• 24:57Dwarkesh Patel?

  Ah, great.

• 24:59Speaker 01

  In the general case, we will have n.

• 25:06Speaker 01

  Like, and sorry, this is n rows. And then we'll have p bits per row. So that gives us the n times p many and gates. So this circuit I've described here, almost all of the cost, like 7 eighths of the cost is in the reading and writing the register file. And only a tiny fraction of the cost is in the logic unit itself. So this is the problem to solve.

• 25:35Speaker 01

  This essentially was the state of play prior to the Volta generation of NVIDIA GPUs. This is what this kind of thing is what was inside the CUDA cores. And this and this sort of problem statement is what motivated introduction of tensor cores, which are more generically called systolic arrays. So if we think about how are we going to solve this problem? Like we're spending almost all of our circuit area on something that we just really don't care about and is hidden to the software programmer. And the thing that we actually care about is not much of the area. Well, make this one bigger somehow while keeping this at the same size. That's the goal. So sort of the evolution was like we had baked this much into hardware in this stage that this single line is a multiply accumulate.

• 26:19Speaker 01

  And this was this single thing was baked into hardware. The idea of a systolic array is to sort of go two levels of loop up and bake this entire loop out here into hardware. And so the idea being that if we have a much bigger granularity fixed function piece of logic, maybe the taxes we pay on the input and output are much smaller.

• 26:40Dwarkesh Patel?

  It sounds like you're suggesting that if you have, if you go up one step in the.

• 26:47Dwarkesh Patel?

  In the matrix multiply loop that there's some you can tilt the balance more towards compute than communication.

• 26:54Speaker 01

  That's right. So there's two effects that we're going to take advantage of here. One is just that we can do more stuff before per every trip through our register file. And then the other thing we're going to take advantage of is in fact, in some of this loop, we can take advantage of, for example, some certain things staying fixed.

• 27:15Speaker 01

  So let's sort of visually, we're going to look at this matrix multiplication. So this portion of the loop corresponds to a matrix vector multiplication, in fact. So we'll take a matrix and multiply it by a vector.

• 27:32Speaker 01

  So how do we do this? We take every column gets multiplied by the vector and then summed. So we're going to sum sort of along columns. So this zero and three gets multiplied by the three and seven and gets summed. And then the one and two gets multiplied by the three and seven and gets summed.

• 27:47Speaker 01

  So there is a multiply accumulate associated with every single one of these entries in the matrix. So we'll just draw out these four multiply accumulates.

• 28:04Dwarkesh Patel?

  And just to make sure I understand why there's four multiply accumulates. So if each entry in the column that corresponds to the output vector is a dot product, and in this case, it'll be like two multiplications and then the addition of those two multiplications. So like you're accumulating.

• 28:28Speaker 01

  Yeah, so the addition, so really, there's only one addition per dot product, but like we like to start with zero.

• 28:33Dwarkesh Patel?

  The initialization of zero.

• 28:34Speaker 01

  Yeah.

• 28:34Dwarkesh Patel?

  Yeah.

• 28:35Speaker 01

  So what we're going to aim for is to have, so we've got, we want to have quadratically more compute. We do, we have, we have got sort of X times Y as much compute.

• 28:48Speaker 01

  As we had before.

• 28:52Speaker 01

  But we're going to want to somehow aim for having only X times as much like communication.

• 29:01Speaker 01

  And this is sort of the intention so that we get this advantage term going as Y. So we've laid down the multiplications. Bringing in like, we're going to want to bring in a vector of size two. And so that sort of already is in line with our comms target. That's fine. However, we need to somehow manage the communication of this matrix, which exceeds our budget of X. And so the idea is that in an AI context, this matrix is actually going to stay fixed for a long period of time. And so instead of like bringing it in from the outside, so we've got some register file sitting over here.

• 29:43Speaker 01

  We don't want to have like the amount of stuff coming out of this register file. This is the term that we want to go sort of as X in some sense.

• 29:54Speaker 01

  We don't want to bring this full matrix in from the register file every cycle because we don't have enough. That would cost too much in terms of wiring from the register file. And so instead, we're going to store. Our key trick is that this matrix can be stored locally to the systolic array. And so where we will store these numbers, zero, one, two, and three.

• 30:21Speaker 01

  In just like a gate called a register that like physically stores these numbers. And we're going to reuse these numbers over and over again for a large number of different vectors.

• 30:31Dwarkesh Patel?

  And so the optimization here is that like the nature of matrix multiplication is you can store this like square quadratic thing directly where the logic is happening.

• 30:48Dwarkesh Patel?

  And which is like higher dimension than the. Or has an extra dimension compared to the inputs which you keep swapping in and out.

• 30:56Speaker 01

  That's right.

• 30:56Dwarkesh Patel?

  I mean, this is the nature of what a matrix multiplication is, is that you do a lot of multiplication to get one value out. Like a dot product is the result of a lot of multiplications. And so that optimization means that you're just like, you can stuff a lot of like multiplication in before you get some value out of it.

• 31:13Speaker 01

  That's right, that's right.

• 31:14Dwarkesh Patel?

  Yeah.

• 31:15Speaker 01

  So like, just to complete the picture here of concretely how that looks.

• 31:20Speaker 01

  I swapped the three and the two here. Three and two.

• 31:25Speaker 01

  So just like this zero and three is going to multiply by the three and seven. And so

• 31:32Speaker 01

  we're going to form a dot product sort of along columns here. So somehow we're going to feed a three and a seven in here. These participate in kind of, this feeds into this multiplication and also feeds into this multiplication. Likewise, the three feeds into here and also into here. And then we're going to sum

• 31:57Speaker 01

  sort of along here with like, starting at the top of a column, we feed in zeros and then coming out the bottom, we get results coming out. So sort of just to visually see what we've got.

• 32:09Speaker 01

  There's a dot product that is performed along columns in a matrix. And that that sort of maps exactly to what is done spatially in the systolic array here. So this is one dot product summed vertically, and this is a second dot product also summed vertically. And then what is the data that needs to go into and out of the register file? We have

• 32:30Speaker 01

  X amount of data that's coming out here on the output. And we also have sort of this data coming from the input, X amount of data from the input. And so with respect to the input and output vectors at least, we've sort of met our goal of having only X as much data going in and out of the

• 32:53Speaker 01

  the register file.

• 32:55Speaker 01

  This leaves open the question of like, I said that the weight matrices, weight matrix is stored locally in the systolic array. How did it get there in the first place? Is sort of a like, at some point, you need to boot your chip and populate this data. And so where did that come from? The trick is just, we just do it very slowly. So we very slowly trickle feed it in into the systolic array. The sort of the simplest strategy is that we we sort of run this daisy chain that says like, feed a number into here and then and then on the next clock cycle, it'll move down to the next entry of the systolic array. And so we can do that in every in in every column in parallel. And that gives us the sort of, this is also going to come from here.

• 33:37Speaker 01

  And this is going to be another factor of approximately X units of bandwidth coming in.

• 33:42Dwarkesh Patel?

  Can you just, would you mind repeating that sentence?

• 33:45Speaker 01

  So like, we're sort of like, we know that we're going to be bringing in numbers only rarely into the matrix.

• 33:51Dwarkesh Patel?

  Yeah.

• 33:52Speaker 01

  And so we just want to come up with any construction at all such that the amount of wiring that actually feeds into sort of crosses this boundary of the systolic array, like this boundary right here, we just want to keep that bounded to X and not be not go as XY. And so a particularly simple strategy is that we we sort of bring in a number into the top row of this systolic array. That's what we can do in one clock cycle. And then for like, for Y consecutive clock cycles, we're going to be bringing in the top row every time and then sort of shift all of the other rows down by one. And that keeps the the sort of the wiring that needs to come from this expensive register file only down to a factor of X rather than X.

• 34:34Dwarkesh Patel?

  I see. Okay. So there's two questions in terms of communication. There's like communication time and then there's communication bandwidth.

• 34:44Speaker 01

  Yes.

• 34:44Dwarkesh Patel?

  And you're saying, since we're only going to be loading this in once, let's maximize, let's minimize bandwidth.

• 34:49Speaker 01

  That's right.

• 34:50Dwarkesh Patel?

  Because bandwidth equals diarrhea. And let's just like load it in slowly over like smaller lanes. Because we're just going to keep this value in there for a while.

• 34:59Speaker 01

  Exactly.

• 35:00Dwarkesh Patel?

  Interesting. So it's interesting to me that when we were talking last time about inference across many chips, the big, high-level thing we're trying to optimize for is increase the amount of compute per memory bandwidth, that is to say, per communication. And here also, we're trying to increase the amount of like actual multiplies or actual additions relative to transporting information from registers to the logic. So in both cases, you're trying to maximize compute relative to communication.

• 35:30Speaker 01

  Yeah, this shows up sort of all the way up and down the stack. This is sort of close to the bottom, sort of like to the gates. There's sort of a version that's maybe even closer to the gates of just like even the precision of number format that you choose to use. We saw that same effect. There's like a square-cube law or like squared versus linear term going on both in just purely the precision of this ALU, but then also in terms of the size of this, the matrix.

• 36:01Dwarkesh Patel?

  Yeah, very interesting.

• 36:03Speaker 01

  So this unit is sort of the next bigger unit. We had like the multiplication circuit. And then on top of that, we have a like a pretty large systolic array. I drew it as two by two, but in like, for example, older TPUs, they were described as 128 by 128 of this circuit shown here. And this circuit ends up being, this is the most efficient known mechanism for circuit for implementing a matrix multiply.

• 36:31Dwarkesh Patel?

  I see. So we've talked about sort of, it seems obvious that you should try to maximize compute relative to communication. What are non-obvious trade-offs that actually you are, you know, keep you up at night about, should we do X or should we do Y? And it's not obvious what the answer is.

• 36:50Speaker 01

  Yeah, so, I mean, I think most of the decisions in chip design are sizing decisions. And so already in what we've drawn so far, like, so AI chips all have this, this circuit. You know, they have a systolic array and then somewhere near it a register file, providing inputs and outputs. The two sort of, like even within this scope, sizing questions that you have are, how big should I make my systolic array? And how big should I make the, the register file? And then the trade off for the size of this

• 37:30Speaker 01

  size of the systolic array, actually, these two questions are coupled is one way to think of it is to say, I'm gonna like have a budget for how much, what percentage of my chip area I want to spend on data movement. So maybe I just say that I want this to be 10% and the systolic array to be 90%. And then sort of I can size my register file. Bigger register files are more flexible. They allow me to run sort of more, I can get more application level performance out. But but then they sort of take away from this area spent on the systolic array. Yeah, makes sense.

• 38:05Dwarkesh Patel?

  I recently ran an essay contest where I asked people to write about what I consider to be some of the biggest open questions about AI. The submission window closed last week, so I used Cursor to create a couple of different interfaces to help me review the entries. One interface anonymizes submissions and hides unnecessary information. It lets me group responses by question, add notes, and record my scores. The other interface helps me review entrants who also want to be considered for the researcher role that I'm hiring for. The UI puts the applicant's essay right next to their resume and their personal website so that I can see everything at once. Cursor's harness is really good at helping these models see and improve their UIs. I watched it render these interfaces in the built in browser, take screenshots, click through sections, and keep iterating. At this point, Cursor is where I do most of my work.

• 38:49Dwarkesh Patel?

  Whether I'm reading and visualizing a bunch of research papers, or coding up an interface to review applications, or making flashcards for my blackboard lectures, Cursor just makes it very easy for an AI to look at whatever I'm looking at and help me understand it and work with me on it. So whatever you're working on, you should do it in Cursor. Go to cursor.com/thorkesh. Where does the clock cycle of a chip come in? What determines what that is? Yeah. And what is a clock cycle of a chip?

• 39:20Speaker 01

  So I guess at baseline, it's sort of worth observing that chips are incredibly, incredibly parallel, right? You've got 100 billion transistors in a chip. A key thing that you need to do whenever you have like massive parallelism is you need to synchronize between the different parallel units. In software, typically, you like you, you have these very expensive synchronization methods like a mutex. So one thread will finish what it's doing. It will like it will grab a lock somewhere stored in memory and then notify the other thread that it's done. On chips, we take a very different approach and say that

• 39:55Speaker 01

  Every nanosecond or so, all circuitry in the chip will kind of pause for a moment and then synchronize every. So it actually synchronizes every single nanosecond or so. And so that is the clock cycle.

• 40:09Speaker 01

  The entire chip, typically all in one fell swoop, goes in lockstep to the next operation that happens. And so what this looks like in circuitry is that you will have.

• 40:25Speaker 01

  It's typically drawn. So the clock is mediated by registers, which are these storage devices that we've drawn elsewhere. And the way to think of it is that I have some storage, which is storing a bit, which might be zero or one. And then I have some cloud of logic, which maybe is like this systolic array or this multiplier or something like that.

• 40:47Speaker 01

  And then I've got some, and that's going to produce some output. So my inputs, I've got a bunch of inputs feeding through this cloud of logic. And then eventually later, there's going to be some output register that this writes to.

• 40:59Speaker 01

  There is a global clock signal

• 41:03Speaker 01

  which drives all of these registers. And it says, at a certain instance in time when the clock strikes,

• 41:14Speaker 01

  whatever value happens to be on this wire at that instant, that's what's going to get stored in there. And so the challenge here is like, I would like to have my clock speed run as fast as possible because if I can run at 2 gigahertz, I can get twice as many operations done per second than if I run at 1 gigahertz. But what that ends up meaning is that I am very sensitive to the delay through this cloud of logic. Because any computation that is going to happen in here needs to finish before the next clock cycle hits. Right.

• 41:50Speaker 01

  So a major point of optimization on any chip then is to make this delay delay from here as short as possible.

• 42:04Dwarkesh Patel?

  Interesting. And is there ever, because the constraint here seems to be that if you add too much logic, then you might risk missing the clock cycle.

• 42:15Speaker 01

  That's right.

• 42:16Dwarkesh Patel?

  But if you don't add enough, then you're leaving potential compute on the table. Is there ever a situation where you're like, you'd take a probabilistic chance that a computation finishes? And or is it just like, no, either it's going to finish by clock cycle or not?

• 42:35Speaker 01

  Yeah, in standard chip design, you margin it such that, I mean, there is a probability, but it's like many, many standard deviations, like way standard deviations out such that for all intents and purposes, it is a reliable part. It will always meet the clock. There are some weird exceptions to that. There are clock domain crossings where you go from one clock to the other clock, and then you actually do have to reason about this probability.

• 42:58Dwarkesh Patel?

  Interesting.

• 42:59Speaker 01

  In the main paths, you just like, you margin it such that you'll get there like 25% of the clock cycle in advance. So it's very unlikely.

• 43:09Dwarkesh Patel?

  In this, in this, the clock, where the clock synchronize, I guess, where the registers are, this is not something you determined as a chip designer. This is sort of just like an artifact of, hey, I want whatever sequence of logic. And then the software you use to convert your verilog into the thing you send to TSMC, that just determines like, hey, in order to make this work, you gotta put a register here, here, and here to make sure that there's no one step that is like too long such that it makes the whole clock cycle of the entire chip longer than it has to be.

• 43:47Speaker 01

  Yeah. So this is actually a huge part of the work of designing a chip, actually, is inserting them. So it is done in a combination of manually and automatically. So, I mean, like, just like to show the very sort of dumb version of like what you can do here, you can take this logic and split it in half. And so like, say, actually, instead of just one cloud of logic, I'm gonna have two smaller clouds of logic, which do the same thing, but split them up by a register.

• 44:16Dwarkesh Patel?

  Right.

• 44:18Speaker 01

  Feeding in like this. And this is like, like if you split it like in the middle, you can hit twice the clock frequency. That's great. You get twice the performance at the cost of this extra register. And so at the cost of some more storage.

• 44:32Dwarkesh Patel?

  And so stepping back, why do we need to synchronize the whole chip? Like if you have, like, if you imagine playing factorial or something, there's no like global clock cycle. It just shit is done when it's done. There's iron on the plate. You can take it if you want.

• 44:43Speaker 01

  Yeah, so taking that analogy, the, the, the thing that you need to be mindful of is if I've got two different pads through some logic. So I have to do a computation like F here and then computation G here. And then they're going to come and meet for computation H somewhere here.

• 45:01Dwarkesh Patel?

  Yeah.

• 45:03Speaker 01

  And so

• 45:07Speaker 01

  there's going to be manufacturing variance here. In some chips, F will take a little longer. Maybe in some chips, G will take a little bit longer. And so if I've got some signal that's propagating through here and the result from F and G have to sort of meet up at H. What can, the, the thing that can go wrong is that F can get there early and it meets like the previous value of G or the next value of G.

• 45:29Dwarkesh Patel?

  Ah, and H needs to know when to start.

• 45:31Speaker 01

  Exactly.

• 45:32Dwarkesh Patel?

  Like when, when has this next iteration of? And so this explains why different chips made at the same process node, the same like TSMC

• 45:42Dwarkesh Patel?

  technology can have different clock cycles. They got two chips made at 3 nanometer, right? At different clock cycles based on whether they were able to optimize, making sure that like there's no one critical path that is so long that it slows down the whole chip's clock cycle.

• 46:01Speaker 01

  That's right. This optimization that I, that I showed here, this is just the, this sort of pipeline register insertion, it's called.

• 46:08Dwarkesh Patel?

  Yeah.

• 46:09Speaker 01

  We've inserted in the middle of the pipeline or register here. This is a sort of pure trade off between clock speed and an area.

• 46:15Dwarkesh Patel?

  Yeah.

• 46:17Speaker 01

  This is the easy case. There is a harder case too, which is

• 46:23Speaker 01

  sort of drawn it as a pipeline of logic here. But in, in other cases, you may have some.

• 46:29Speaker 01

  Some calculation which actually feeds back in on itself. So it runs some function F and then writes back to itself like this. So for example, this might be this addition, like you've got some number that you're adding into every clock cycle. And so this this could be like a this could be like plus. We're adding in some number every clock cycle.

• 46:53Speaker 01

  So this like this little socket. It essentially is just going to sum all of the numbers that are presented on it on different clock cycles. And the challenge is if this plus takes too long. What can I do if I like split it in if I try and put a pipeline register like right in the middle of it? Like like here in the middle of it.

• 47:15Speaker 01

  This will end up changing the computation that's done. Instead of forming a running sum of everything that comes here. I will actually have two different running running sums. I'll end up having a running sum of the even numbers and a running sum of the odd numbers. So sort of this constraint where I have a loop in my logic, which all chips have somewhere. This is actually the thing that is the hardest thing to to to address and and sets the clock cycle.

• 47:39Dwarkesh Patel?

  I don't understand why it would be a problem to have that. Or I'm not sure even what it would mean to have a register there. Like, is this is this sort of atomic operation, right?

• 47:47Speaker 01

  Yeah, well, so plus is not really atomic. Like, I think.

• 47:50Dwarkesh Patel?

  As we just demonstrated.

• 47:51Speaker 01

  Yeah, yeah, it took a whole lot of work to do a summation. And so like you can take the early parts of that work and then and then stick a register in the middle and then do take the late parts of that work.

• 47:58Dwarkesh Patel?

  Okay, yeah. And I guess it's then up to so TSMC offers a PDK which says that I say here's the primitives of logic that we can grant you in the in the chip. And it's up to them to determine that no no primitive is bigger than like the clock cycle they're hoping a process node targets. But other than that, is there like what further optimize? Can't you just say like, hey, here's all the primitives from TSMC? And if keep adding registers in between the primitives as much as is needed until you get to your desired clock cycle?

• 48:34Speaker 01

  Yeah, as a logic designer, like the chip architect set the clock cycle. So just for for one example. The primitives you get from TSMC are on the order of like AND gates or full ladders. They depends a lot on voltage and which library you choose and so on. But generally, you can typically have about like 10 or 20 or 30 of these in a clock cycle sequentially. So these primitives are very, very fast, like 10 picoseconds or something like that. And so as a logic designer, I mean, like in principle, if you literally just had like like register and then AND gate

• 49:14Speaker 01

  kind of in a loop like that, you could get insanely fast clock speed, like more than four, five, six gigahertz, something like that.

• 49:22Speaker 01

  But if you take this this like really sort of like simple circuit and you look at the area you're spending here, like this is maybe like one, I mean, this is this is called one gate equivalent in size. So like unit of one in area and this thing is like unit of eight in area or something like that. And so like this is just, again, almost all of your cost has been this like synchronization or communication cost compared to the actual logic. And so so this would be a case where you've gone too far. You've made your clock speed really, really fast at the cost of spending almost all of your area on pipeline registers.

• 49:58Dwarkesh Patel?

  Interesting. So what you're hinting at is a dynamic where you can have really fast clock speed, but you're not getting that much work done.

• 50:05Speaker 01

  Yeah, yeah.

• 50:07Dwarkesh Patel?

  And so you can have like low latency, but but low bandwidth or throughput, rather.

• 50:12Speaker 01

  Yeah, it hurts your throughput, in fact, because like the throughput of your chip, you can think of as the product of how much I get done per clock cycle, which is based on this area efficiency thing, times how many clocks I get per second.

• 50:25Dwarkesh Patel?

  This is this is actually so similar to the thing we were discussing last time about like batch size,

• 50:32Dwarkesh Patel?

  where if you have a low batch size, then you can, any one user can receive their next token really fast. But the total number of tokens that are processed in, say, an hour will be kind of lower than it could otherwise be.

• 50:45Speaker 01

  Yeah, exactly. You get you get less parallelism out if you if you drive your clock speed up really high.

• 50:50Dwarkesh Patel?

  Language models are starting to compete against the best human forecasters. I sat down with two senior Jane Streeters, Ron Minsky and Dan Pontecorvo, and asked, at some point, does AI just do what Jane Street does?

• 51:01Speaker 02

  There's a world that we should take seriously where we're going to build large language models or some other AI systems that are strictly smarter than all humans on the planet and more capable at all cognitive tasks. Trading in particular feels to me as like kind of AGI complete, sort of like NP complete, because at the end of the day, trading involves figuring out what things are worth, which means making predictions about the future.

• 51:27Dwarkesh Patel?

  Jane Street isn't betting against AI. They just signed a $6 billion compute deal. But Ron's view is that the edge keeps moving.

• 51:33Speaker 02

  I have never been more desperate to hire more engineers and more traders than I am today. You have the usual thing of the other hard parts that we don't yet know how to automate. Well, that ends up being where the competitive edge lies.

• 51:45Dwarkesh Patel?

  You can find these open positions and watch the full interview at janestreet.com/thoracash. Okay, so I remember talking to an FPGA engineer at Jane Street, Clark, who actually helped me prep for the previous interview we did together. And he was explaining why they use FPGAs. And I imagine that for high-frequency trading, throughput is less important than latency. And so having very specific control over the clock cycle in a deterministic way is the most important thing. Maybe it'd be interesting to talk about how you, why you can't just achieve that with an ASIC, or why FPGA is the,

• 52:28Dwarkesh Patel?

  yeah, why you might use an FPGA to have deterministic clock cycles for high-frequency trading?

• 52:34Speaker 01

  Yeah, so firstly, let's consider the business case for an FPGA versus an ASIC.

• 52:42Speaker 01

  FPGA's and ASICs use largely the same conceptual model, which is that I have a series of gates built from ANDs, ORs, XORs, those very small primitives, connected together with a fixed clock cycle and connected together with wires that are running in a fixed clock cycle. So anything you can express in an FPGA, you can express in an ASIC too, and it'll be about an order of magnitude cheaper and better energy efficiency on an ASIC than an FPGA. The trade-off is that the first FPGA costs you $10,000, whereas the first ASIC you make costs you $30 million because it requires an entire tape-out. So the business use case for an FPGA would be that I want something

• 53:27Speaker 01

  that has this very deterministic latency and fast runtime and high parallelism. But I'm going to change it very frequently. I change what I do every month or something like that. And so then I don't want to pay the tape-out cost every time. Now, how does an FPGA actually implement? It emulates the ASIC programming model, but in a fixed piece of hardware. And so how does that work, actually? So what it has at the base is it's got the two components we just talked about. It's got these registers as storage devices.

• 54:09Speaker 01

  And then it's got these are called LUTs, lookup tables, which actually provide all of the gates. And then we're going to see even the third component. We then have a swarm of these registers and LUTs.

• 54:35Speaker 01

  And all of these are available and then they're connected by sort of this big set of sort of muxes. So in front of every single one of these, we've got something like one of these muxes, which selects one input from everywhere else, sort of selecting from all of these things. You know, we've got a whole bunch of different options feeding into all of these things. So what this allows is essentially a, when I program my FPGA, I can say that I'm going to take all of these components and I'm going to sort of superimpose on top of this a particular wiring which like goes through this lot

• 55:19Speaker 01

  and then feeds into this lot and then goes to this register and then feeds into this lot or something like that.

• 55:26Speaker 01

  So what I've drawn in orange is like how you, like FPGA means field programmable gate array. This is the, the orange is what has been programmed in the field, whereas the white is all of the wires that must exist in the FPGA in order to actually to make the device in the first place.

• 55:41Dwarkesh Patel?

  What does it mean to be programmed into a field?

• 55:43Speaker 01

  Like programmed in the field. So like the device has been deployed in a data center. It's sitting in the field and then you can come and program.

• 55:48Dwarkesh Patel?

  Not field as in like electric field or field as in like out there in the world field. Okay. And so if I see, look at the, how the, the field programming comes out of the first lookup table and goes in a second one.

• 56:05Dwarkesh Patel?

  How is it, yeah, how?

• 56:07Speaker 01

  Like where are the wires that made that happen?

• 56:09Dwarkesh Patel?

  Yeah.

• 56:10Speaker 01

  Yeah. So I got a little bit like lazy in drawing all of these. Every single device here has a mux sitting in front of it,

• 56:19Speaker 01

  which can select from all of the like nearby like circuits that are available.

• 56:26Dwarkesh Patel?

  Yeah.

• 56:27Speaker 01

  And so the actual configuration of the FPGA is like

• 56:33Speaker 01

  Amounts to it is the mux control. So like we, in this mux here, we have the data inputs. And then we have like the control that selects. And so like, there's a little storage device sitting next to every single one of these

• 56:49Speaker 01

  muxes saying, this is where you're going to source your input from.

• 56:53Dwarkesh Patel?

  Got it.

• 56:53Speaker 01

  And so, programming it consists of like configuring every single one of these muxes.

• 56:58Dwarkesh Patel?

  So that makes sense. What is happening inside of the lookup table?

• 57:00Speaker 01

  Yeah. So the purpose of the lookup table, so it's going to also have a little bit of control feeding, telling it what to do as well. The purpose of the lookup table is to function, to be able to configurably take the role of an AND gate, OR gate, XOR, any of those different things. So, there's many ways you could consider doing that. The way it is done in sort of traditional FPGAs is to say, it will support,

• 57:30Speaker 01

  so it will be, a lookup table will be,

• 57:35Speaker 01

  it will have four bits of input, one bit of output.

• 57:41Speaker 01

  How many different functions are there from four bits to one bit? There are 16 different functions. And so, you can actually just tabulate this as like 16 different, like 16 different numbers. You've got a table of 0111001, 16 entries.

• 58:00Speaker 01

  And so what it does is, this table is stored in this blue configuration bit. And then,

• 58:10Speaker 01

  it views these four bits as binary, looks up the relevant row of the table, and emits that bit.

• 58:18Speaker 01

  So there's a truth table view of lookup tables, essentially.

• 58:22Dwarkesh Patel?

  Okay, so the lookup table, if you think about an AND gate, OR gate, NOR gate, XOR gate, these are all like, take as input?

• 58:29Speaker 01

  Those are like two input functions.

• 58:30Dwarkesh Patel?

  Yeah.

• 58:31Speaker 01

  Sometimes we have like more complicated, like a three input function would be a three-way XOR.

• 58:35Dwarkesh Patel?

  Right.

• 58:36Speaker 01

  Or a four-way XOR.

• 58:37Dwarkesh Patel?

  And in this case, how many, it just depends how big it is?

• 58:41Speaker 01

  Typical size for LUTs is four input, which is sort of just a sweet spot between.

• 58:47Speaker 01

  There's another computer communication trade off like here. Like if it has too few inputs, then you need to use more lots.

• 58:52Dwarkesh Patel?

  Yeah.

• 58:53Speaker 01

  If it has too many.

• 58:53Dwarkesh Patel?

  But basically, the lookup table is like a truth table.

• 58:56Speaker 01

  It's a truth table.

• 58:57Dwarkesh Patel?

  Yeah. And with a truth table, you can program in any gate you want.

• 59:00Speaker 01

  That's right.

• 59:01Dwarkesh Patel?

  And so it's a lookup table, just thinks like a programmable gate.

• 59:04Speaker 01

  That's right. And so, I mean, one of the things you can do here is you can see why, where the rule of thumb that an FPGA is like an order of magnitude more expensive than an ASIC comes from is to count how many gates would be inside this lookup table.

• 59:18Dwarkesh Patel?

  Yeah.

• 59:20Speaker 01

  So we can view this lookup table essentially as one of these muxes. And so it is a mux with, has to select between 16 different values.

• 59:30Speaker 01

  And so it is a mux with sort of n equals 16 options.

• 59:39Speaker 01

  P equals 1 bits. And so what we saw way earlier is that

• 59:47Speaker 01

  this circuit costs like n times p many gates. And so it's like, so it costs like n times p equals 16 AND gates. And also 16 ORs.

• 1:00:00Dwarkesh Patel?

  This circuit being the mux.

• 1:00:02Speaker 01

  Yeah, exactly. The mux. The mux is the core.

• 1:00:04Dwarkesh Patel?

  The mux that goes into the lookup table.

• 1:00:06Speaker 01

  So the lookup table itself, you can think of as being actually a big mux that like selects from all 16 rows down to one output.

• 1:00:14Dwarkesh Patel?

  Yeah, okay.

• 1:00:15Speaker 01

  That is the lookup table.

• 1:00:16Dwarkesh Patel?

  But the way you've drawn it here, there's like a mux and then a lookup table.

• 1:00:19Speaker 01

  It's muxes all the way down. So I mean, there's a, there is a second mux that is inside here. This mux is this mux.

• 1:00:25Dwarkesh Patel?

  Got it. Okay. And then the, the other mux is just saying.

• 1:00:29Speaker 01

  Where it came from in this sort of mess of, of gates.

• 1:00:32Dwarkesh Patel?

  Right. And then the second mux is, okay, now you have one value, but that value is still,

• 1:00:39Dwarkesh Patel?

  still a four bit value.

• 1:00:40Speaker 01

  Yeah. So I've selected four bits from the soup.

• 1:00:43Dwarkesh Patel?

  Right.

• 1:00:43Speaker 01

  And then, and then I use those four bits to select which entry in the lookup table.

• 1:00:47Dwarkesh Patel?

  Yeah.

• 1:00:48Speaker 01

  I'm gonna use.

• 1:00:48Dwarkesh Patel?

  Right. Okay. And just so like, suppose in the first mux, there's like eight nearby, eight, you're, you're pulling from eight nearby registers as input. And so that's like a total of like 32 bits going in. And then out of that, four bits come out. Those four bits go into the second mux, which is inside the lookup table.

• 1:01:11Speaker 01

  So actually, I would say, in this case, these registers are single bit registers. So if there are eight nearby registers and lookup tables, then I have eight bits total coming in nearby. I select from eight down to four different values. So there's actually like four different muxes, one associated with each of these input. Like little muxes associated with each of these input bits. Each of them is selecting one out of eight.

• 1:01:37Dwarkesh Patel?

  And where are those eight coming from?

• 1:01:39Speaker 01

  Nearby registers and other LUTs.

• 1:01:41Dwarkesh Patel?

  And each registers one bit?

• 1:01:42Speaker 01

  Yes, yeah.

• 1:01:43Dwarkesh Patel?

  And so I guess AMD or whoever makes these FPGAs still has to be opinionated about what registers are connected to which registers. And then you can program in the actual gates, but they had a wire in the communication topology, right?

• 1:02:02Speaker 01

  Yeah, so there's the sort of like, you get flexibility in a local grain thing. There's a sort of nearby neighborhood where you can select from. But then more grossly, like more coarsely, longer distant connections, they form an opinion on that.

• 1:02:16Dwarkesh Patel?

  Right, yeah. And the reason it's 10x slower is why?

• 1:02:19Speaker 01

  So if you look at the cost of like building this lookup table, it's like 32 gates.

• 1:02:25Dwarkesh Patel?

  Yeah.

• 1:02:26Speaker 01

  And then it can give me the equivalent of like, what's one, an interesting thing I can do here? I can do a four-way AND gate. And so that's like, I am using 32 gates of lookup table to sort of implement like a four-way AND means like, what is a four-way AND? I would do like AND, AND, and then AND of AND. So to input, like this is a circuit that I could implement in an ASIC directly using these three AND gates. But using a LUT, I can also implement it, but it's going to take like these 32 gates instead of three.

• 1:02:56Dwarkesh Patel?

  Right. And so the overhead is really coming from the fact that the lookup table, the mux in the lookup table is...

• 1:03:08Dwarkesh Patel?

  There's a more concise way to describe a truth table than listing out every single possible combination of inputs, which is just to write out the gate.

• 1:03:19Speaker 01

  Yeah, like to place down the polysilicon and the wires. That's right. Yeah, interesting.

• 1:03:25Dwarkesh Patel?

  One important point you made to me is that the reason they prefer FPGAs to CPUs is because they get deterministic clock cycles. They know when a packet will come in and go out. Why is it not a guarantee in CPUs?

• 1:03:39Speaker 01

  So you can actually design a CPU that has deterministic latency as well.

• 1:03:45Speaker 01

  And in fact, the processors that are inside a lot of AI chips actually also have deterministic latency too. Grok has advertised this. TPUs have that in the core as well.

• 1:03:57Speaker 01

  The challenge is getting deterministic latency and high speed at the same time. And so where does the non-determinism in latency come from? Non-deterministic latency comes from specific design choices in a CPU.

• 1:04:14Speaker 01

  It's actually possible to remove those design choices and make a CPU that has deterministic latency. Those are not very attractive in the market, and so people don't make those CPUs anymore. But actually, in some sense, deterministic latency is maybe a simpler designing starting point. And then some chip designers have added things in to be non-deterministic. To take a concrete example of that, probably the most important example is on a CPU, just like the CPU cache itself. So

• 1:04:54Speaker 01

  in a CPU, you have the CPU, this is the CPU die itself, and then there's a memory off on the side. This is the DDR memory off on the side. And then you have a cache system here inside it. There's the cache.

• 1:05:13Speaker 01

  That sort of remembers recent accesses to DDR and stores them. And so when I'm running through my CPU instructions, every time I have an instruction that accesses memory, it first checks in cache was the data stored in cache. And then if not, it goes, it fetches out to DDR. Yep. This is a huge optimization. The cache is like two orders of magnitude faster than DDR. If you never, if you never like use the cache, like basically all programs would run 100 times slower. So the presence of a cache is absolutely necessary for a CPU to run at reasonable speed. But whether or not you get a cache hit is dependent on the sort of ambient environment

• 1:05:55Speaker 01

  of the CPU, like what other programs are running, what has run recently, what is the random number generator inside the cache system doing? And so that is a big source of non-determinism in the runtime of a CPU. Yeah. So this is sort of the memory system for a CPU. The, the big thing that you can do differently is instead of having the hardware say, I'm going to like read, read memory and then decide, the hardware decides whether or not it comes, comes, comes from cache or not, you can actually bake this, this decision into software. So a different design philosophy is, is to, so, and you see this in maybe, for example, TPUs. The, the TPU instead has, I mean, I'll draw the same diagram, but I'll call it a scratchpad.

• 1:06:40Speaker 01

  And so the, the main difference is, so this would be like a TPU and then HBM in this case rather than DDR, but it's still an off-chip memory. And instead of like the software saying first access like memory and then the hardware decides, you've got some instructions that go here. This is like one kind of instruction and then a totally different kind of instruction that goes to HBM. Yeah. And so this style is generically known as scratchpad instead of cache. The key distinction being that you have like one kind of instruction that says read or write scratchpad and a totally different instruction that says read or write HBM.

• 1:07:21Dwarkesh Patel?

  So scratchpad being the cache.

• 1:07:23Speaker 01

  Yeah, this thing here is the scratchpad.

• 1:07:26Dwarkesh Patel?

  Just to be clear. So stepping way back, people say computers have the quote-unquote von Neumann architecture, where there's this serial processing of information. And maybe just because we've been talking about parallel accelerators, but I just don't like the FPGA is super parallel.

• 1:07:45Speaker 01

  Yeah.

• 1:07:47Dwarkesh Patel?

  The kinds of AI accelerators, TV users are super parallel. Even CPUs are super parallel, if you think about all the cores they have. And so is it actually, like, in what sense is modern hardware actually the von Neumann architecture? Is that actually a fair way to describe modern hardware?

• 1:08:03Speaker 01

  I think it's a fair way to describe CPUs, like just the amount of parallelism, like on a CPU, the amount of parallelism, you had is about 100 cores times maybe like 16-way vector units. So 106, about 1,000-way parallelism on a CPU.

• 1:08:16Dwarkesh Patel?

  Yeah. Is it, one question is, what is the, there is a die that is being used for the CPU. And if there's fewer threads, just as a matter of like transistor voltages are like switching on and off, is it just that there's like literally one control flow, like a small part of the die where like voltages are switching on and off, or like, in what, how do you actually occupy the die area of a CPU if there's, as opposed to?

• 1:08:45Speaker 01

  If there's so few cores, like what are you, am I spending all the time?

• 1:08:47Dwarkesh Patel?

  What is happening in there?

• 1:08:47Speaker 01

  Yeah. The cores are just much bigger and more complicated. So, I mean, like, so I guess we should compare like a CPU core which takes up 110th of the die to like, I mean, to a lot, like a lot is just only these 16 gates.

• 1:09:03Dwarkesh Patel?

  Right.

• 1:09:04Speaker 01

  So like, it's clear why there are so many more lots in an FPGA than cores in a CPU. But then sort of maybe the, like, why are there more CUDA cores, for example, than CPU cores, I think would be like, why, what's the difference between a CPU and a GPU or something like that would be a big difference. Inside the CPU, you have, so one big use of, so the sort of the top uses of area inside a CPU are the cache.

• 1:09:34Speaker 01

  Very little is actually the ALUs, like mostly it's like these register files rather than the logic units.

• 1:09:42Speaker 01

  And then the Both of these things have equivalence in a GPU, and so that's not a big difference. But the thing that does not have an equivalent in a GPU is the sort of this branch predictor. And so there is a whole big area in the CPU, which is sort of just a whole bunch of predictors that are saying, when will my next branch be? And where's the branch target for that? And so stripping a lot of that out, as well as sort of making these register files tighter, in a sense, is driving a lot of where the GPU gains.

• 1:10:19Dwarkesh Patel?

  And what is the purpose of the branch predictor? To like execute both branches at once? Or what does it do?

• 1:10:24Speaker 01

  So the issue is that when I've got a series of instructions like, instructions, instructions, instructions, instructions, if I have a branch like here, if this instruction is branch. The actual processing step of processing an instruction takes a really long amount of time. It takes like maybe five nanoseconds or something like that. So like the time to actually notice that I've got a branch and then like evaluate the Boolean, whether it's true, and then update the program counter to the new target, and then read from the instruction memory for that. That could take like actually five nanoseconds to finish.

• 1:11:07Speaker 01

  And so in reality, this may finish somewhere down here. I don't want to like, but like, I want to run a clock speed that is much faster than what five nanoseconds allows. Like five nanoseconds is 200 megahertz clock speed. I would like to run at one or two gigahertz or something like that. And so I need to run other instructions while the branch is being evaluated. And so I like, I really just want to keep running the following instructions that happen after me. But that might have been wrong. Like if the branch ended up being taken, then I need to know that instead of evaluating these instructions, I actually need to like jump to wherever the target is and run these instructions instead.

• 1:11:48Speaker 01

  And so the purpose of the branch predictor is like genuinely to predict based on like before you even get to this instruction, to be like five cycles earlier to predict there was going to be a branch that's going to happen.

• 1:12:00Dwarkesh Patel?

  So if I think about how the brain works, versus what you're describing here, at a high level, the differences might be that while you can do structured sparsity in these accelerators and then save yourself some.

• 1:12:14Dwarkesh Patel?

  Area that you would have otherwise had to dedicate to these gates. In the brain, there's unstructured sparsity. You know, any neuron can connect to any other neuron and not in like ways where they'd be column lined or whatever.

• 1:12:26Speaker 01

  Yeah.

• 1:12:26Dwarkesh Patel?

  Um, then there's the fact that memory and computer co-located. I guess you could say in a way the memory and computer co-located on.

• 1:12:34Speaker 01

  This is exactly the co-location in some sense of the.

• 1:12:36Dwarkesh Patel?

  That's right. That's right. Yeah. Yeah. So maybe that actually isn't a big difference. And the other, maybe a bigger, a big difference is that the clock cycle on the brain is much slower than on, um, on computers. And partly that's to preserve energy because the faster the clock cycle, the bigger the voltage uh, needs to be in order to identify, for the signal to settle and to like identify what state of transistor.

• 1:13:05Speaker 01

  Yeah, that's right. That's right.

• 1:13:06Dwarkesh Patel?

  I don't know if you have other high level takes about like how, any commentary on, you know, what the brain might be doing versus how these chips work.

• 1:13:16Speaker 01

  Yeah. I mean, so, so let's take the clock speed one first, actually.

• 1:13:20Dwarkesh Patel?

  Yeah.

• 1:13:23Speaker 01

  The clock speed is quite high on, on a chip because that, I mean, drives higher throughput. Um, like when we compare a, like a GPU running some, some workload, it's running batch size a thousand or something like that, whereas like the brain is not running batch size thousand. There's only one of me. And so you could sort of imagine saying, well, take a GPU and like, instead of running at a gigahertz, run at a megahertz or something like that. And, and that would start to look maybe a little bit more like, like, um, uh, sort of equivalent things that you're talking about in the brain.

• 1:13:58Speaker 01

  There is, in the way that silicon works, um, there are, like, that does not give you an 1000x advantage in energy efficiency. So, um, what it ends up looking like is you can.

• 1:14:14Speaker 01

  You sort of just end up running this circuit once to stabilization and then it'll sit idle for a long period of time. It doesn't consume a lot of energy while it's sitting idle because most of the energy is consumed in sort of toggling bits from 0 to 1 and back.

• 1:14:33Speaker 01

  So actually, let's talk about the energy consumption of a circuit like this. The way to think of a bit being stored is you've actually deposited some charge in a capacitor somewhere, sitting somewhere in the chip implicitly. So it becomes charged when it is bit becomes a 1 and then it becomes discharged when it next goes to a 0. And that cycle of like charging the capacitor and then dumping that charge out to ground, that is where the energy is consumed.

• 1:14:58Dwarkesh Patel?

  Yep.

• 1:14:59Speaker 01

  This is called the dynamic or switching power. This is most of the energy consumption of a chip. There is some other energy consumption just coming from the fact that

• 1:15:08Speaker 01

  insulators aren't perfect insulators, but we'll just discard that. Most of the energy consumption actually comes from just the charging and discharging of like toggling from 0 to 1 and back to 0.

• 1:15:17Dwarkesh Patel?

  Right.

• 1:15:19Speaker 01

  So if you run a chip much slower and you only clock it once every 1000 clock cycles or something, you will have 1000 times fewer transitions. It'll be about 1000 times less energy consumption, but not a substantial advantage in energy efficiency.

• 1:15:34Dwarkesh Patel?

  Okay, so you described how a TPU works at a high level. What is the difference at a high level between how a GPU and a TPU work?

• 1:15:43Speaker 01

  Yeah, so I mean, I think there's sort of a high-level organization principle that is different.

• 1:15:50Speaker 01

  And then there's sort of inside the cores what are different. But we'll look sort of outside the like at the high level. So we'll take a GPU and a TPU and what does like sort of the top-level block structure look like? If you think of this as the whole chip in each case,

• 1:16:08Speaker 01

  the organization of the GPU is mostly a bunch of almost identical units, which are these. These are the SMs.

• 1:16:20Speaker 01

  And then they've got an L2 memory in the middle, and then a bunch more of these SMs on the bottom.

• 1:16:27Speaker 01

  And so there's sort of this fairly regular grid, of course.

• 1:16:34Speaker 01

  And then if we look at a TPU in comparison,

• 1:16:40Speaker 01

  you end up with much coarser grained units of logic. And so you end up with something like some large number of, maybe like, maybe just a few M- Matrix units. These are the, these are the big, like, systolic arrays. And then in the middle, you've got some vector unit.

• 1:17:03Speaker 01

  And then you've got your Matrix units at the bottom. So now, sort of like, Matrix units with a vector unit in the middle, sort of, this is the whole TPU chip. You can sort of think of scaling this thing down into a really tiny unit, with a smaller Matrix unit, smaller vector unit. And that is sort of what an SM is. So, sort of, at a very high-level point of view, the GPU has a lot of tiny, tiny TPUs, sort of tiled across the whole.

• 1:17:35Dwarkesh Patel?

  Oh, interesting. So like, you're suggesting the tensor core within a streaming SM is analogous to an MXU?

• 1:17:42Speaker 01

  Yeah, it's very, very similar, yeah.

• 1:17:44Dwarkesh Patel?

  I see. And so if you had more, like, more lack of structure, having a bunch of tiny TPUs makes a lot of sense. Whereas if you kind of just have, like, huge Matrix multiplications, you're like, why don't we just, why don't we avoid the cost of having the individual SMs with their own registers and warp schedulers and things like that? Why don't we just, like, make a huge thing? And, like, amortize those costs across the whole thing?

• 1:18:12Speaker 01

  And I mean, I think this shows up in how large you can grow things. We've sort of seen this theme, like, especially with this systolic array, where larger systolic array amortizes the register file costs better.

• 1:18:22Dwarkesh Patel?

  Yeah.

• 1:18:23Speaker 01

  This sort of design allows you to have larger systolic arrays. This, whereas the sort of GPU design constrains you to having small units of everything. There is a trade-off, however.

• 1:18:37Speaker 01

  There ends up being, because of this sort of coarse grained separation of things there, you need to move a lot of data from the vector unit to the matrix units. And so you need to move a lot of data through a sort of like two lines of perimeter here. Whereas if you sort of look at the equivalent thing, here you've got vector units everywhere, and you need to move data through this line, through this line, through this line, through this line, through this line, through this line. So the amount of data you can move between a vector unit and a matrix unit is actually much higher in a GPU than in a TPU. Because instead of having to move all the data through these just two lines,

• 1:19:21Speaker 01

  you're moving all these data through like 16 lines or something of wiring instead in a GPU.

• 1:19:27Dwarkesh Patel?

  Right, but also you might have to move across less area.

• 1:19:32Speaker 01

  Which, I mean, is also a saving, like it's an energy saving. So data ends up moving, like if you can operate entirely within an SM, the data movement is much smaller. But then the moment you want to operate across SMs, it becomes sort of more complicated and expensive.

• 1:19:47Dwarkesh Patel?

  So you don't have to comment, but one might expect that a thing Matic might try to do is to get the GPU-like spaller structure of systolic array surrounded by SRAM, but also at the same time make it so that like the things you needed in SM to support the CUDA architecture, but take a bunch of space you might discard.

• 1:20:14Speaker 01

  Yeah. We've talked publicly about something which we call a splittable systolic array, which is sort of, in some sense, you can think of as like big systolic arrays that can be small systolic arrays as well.

• 1:20:24Dwarkesh Patel?

  Cool. Okay, I think that's a good note to close on. Reiner, thank you so much.

• 1:20:29Speaker 01

  Thanks, Rakesh.