 Hello, can everybody hear me in the back? You're okay? Okay, excellent. Somehow my screen flickers, but what to do? Okay. Good to meet you, Ant. Excuse my German, Swiss German. Unfortunately, I'm still learning. Maybe you can help me learn. Welcome to Digital Circuits or Digital Technique. I hope you're here for this. If you're not, this is the right time to leave probably. Unless you're welcome to stay if you want to learn more about what's written over here. I assume all of you are first year. I guess I started early. It's better to be early than late. You're all first year students? Yes? Excellent. You're excited about this? Yes. Okay. That was not a strong yes, but hopefully it'll be a yes by the end of the course. I'm very excited about all of this stuff, so hopefully I will convey why I'm excited about this to you. And the goal of the first two lectures today and tomorrow is really to give you an overview or to cover, to discuss what we're going to be talking about for the rest of the course. Now this course is going to be a very tough course, not to scare you, but to show you that we're serious here at ETH about computer science and everything, but I want to give you an overview of why this is an exciting time to study what we're going to study in this course. Because this is going to be really the building block for the rest of computer science that you're going to see in the future in your career. If you know this really well, then I believe you're going to be able to solve any kind of problem that comes in front of you. So hopefully you'll pay a lot of attention. If you can pay attention while playing computer games, that's okay too. Just make sure the computer game doesn't cause interference to people around you. Okay, so let's get started. I'm Onur Mutlu, I'll introduce myself later in the course. I've been here very little before I used to teach at Carnegie Mellon University. I came here in May and September and I'm teaching here now. But I'll introduce myself and the other course staff hopefully today, if not tomorrow. So let's start with some puzzles actually. I'll challenge you in the first few parts of the lecture. And hopefully you'll answer me. What is this? Well, this is a slide of course, but clearly that's not what I'm asking. I'm asking you what this is. Oh, you guys are good. It's subtle often, right? It's a beautiful view. It's another view of it, right? What comes to your mind when you look at this thing? Nothing? Circuits? Yes, that's a good thing, yes, exactly. Architecturally anything? Do you guys know who it is designed by? Yes, exactly, Kalatrava. Okay, I'll tell you more about Kalatrava. You spoiled it because I thought a few people would know, but not everybody. Who knows about Kalatrava? Excellent, so the first assignment is to learn about Kalatrava. And I will give you that assignment in a little bit. But when I first went there actually, I first went to Stadlhofen when I interviewed at Etihad last year, or the previous year. And I really enjoyed it, it's beautiful. I think it's one of the most beautiful train stations that I've been to in my opinion. Well, of course that's my opinion because I'm telling you that. But it's small, but there's this beauty to it. Look at these things that are supporting the upper platform over here. They're not straight, they're really angled, and you can see other, look at the bridge over here. There's some sort of aesthetic beauty in it that's hard to talk about. I'll show you some other examples. There's another view of it, hopefully. If you didn't recognize it the first time, hopefully it's coming to you. This is the opposite view. How many people recognize this place now? It's Bono Stadlhofen. Okay, excellent. How many people don't recognize it? You have never been there. Or, I guess it's a different question, right? How many people don't recognize it? And how many people don't recognize it that they've never been there? Okay, that's a small group. So I will encourage you to go there and think about it in a different way. It didn't always used to look like this. This is what it used to look like in 1983. How many of you were there in 1983? Yeah, you can raise your hand, that's okay. I was certainly not there in 1983. I was still alive. How many of you were alive in 1983? I see one hand, I think. That's okay, there's no, we don't discriminate here. You can be old, young, it doesn't matter. It can take this course, no problem. But you can see the difference, I think. Well, this picture doesn't convey it that much, these two, but others do. And this is 1967, even older, right? There's some other sort of beauty into it, but it's not the same, perhaps. Okay, I'll ask you another question. I think you've spoiled it, but what is the following having common going forward? So this is another place in Lisbon, Guaia do Oriente with my terrible Portuguese. Internals look kind of similar, right? You can kind of see there's a principle here, right? It's like the skeleton of a bird or something like that. That's really supporting the platforms. You haven't been there, but you can, imagine there's some similarity here. Well, another one, a newer work, Milwaukee Art Museum. It's becoming more grandiose, maybe. But the principles are looking similar. Maybe they're growing in different ways, and maybe they're becoming more expensive also, by the way. This is Athens Olympic Stadium 2004. This is another beautiful building. Has anyone been to any of these? Which one, this one? Oh, okay, cool. I intend to go to all of them. It's another one. It's actually alive, if you will. That's like a bird flying. And another view of the same building that's flying bird, right? Maybe it's not a bird, but it's some bug over here that's consumed by some other bug or something like that. I don't know. You can interpret it in different ways that you would like, right? Well, it's clear that, leave your interpretations to yourselves. But this is another one. This is one of the last and perhaps the most controversial ones, right? The Oculus. This picture actually doesn't do justice to it, I think. And I worked really hard to find a picture that does justice to this. I couldn't find one. If you find one, please let me know. It's very hard to do justice to this with a single picture. You have to really be there and go look around. And I guess the fact that it's situated underneath all of these skyscrapers make it harder to find a picture or take a picture that does justice to this. So, what do all of these have in common with Ban of Stadlhofen? No one? Who's hand? You gotta shout. It's hard to see everyone here. Yes, exactly. The architect is Kalatrava. So all of these were done by Kalatrava. Last one being probably the most controversial one. It cost about $4 billion. Yeah, I'll show you another architect who actually likes more expensive buildings, but these are all beautiful buildings. So this is Ban of Stadlhofen and all designed by a famous architect. Actually, an ETA alumnus in civil engineering. Did you know this too? About Kalatrava? Yeah, he came here after he got his architecture degree in Spain. He did a PhD in civil engineering. And of course, Stadlhofen actually was one of his first big jobs, if you will. It's considered a big job. He started, I believe, in 1983 and he finished in 1989, 1990 or so. And you can see an explanation of this. The train station has several of the features that became signatures of his work. Straight lines and right angles are rare. And it's more zoomorphic architecture, which we will talk about. And this is him. And this is what Wikipedia tells us about him, assuming you believe it. But it's relatively believable in this case. He's a Spanish architect, structural engineer, sculptor, and painter. He actually has an office in Zurich. I think he partially lives in Zurich right now too. But you can see that whose sculptural forms often resemble living organisms. And you can argue which one is his best works. This is where you can argue with Wikipedia and go and change it. And somebody else changed it again. And so you have the consistency problem, right? It's just like processors. We're gonna talk about processors. People have the consistency problem over here in Wikipedia. You change it and someone else changes it and you get garbage, maybe. Processors do the same thing, right? If two processors are operating on the same memory location, one of them can update it and the other can update it. And if they're updating it, not inside the exact same location, but in some other copy that they created, now they may have a problem with the consistency of the data. Right? And this is actually one of the big problems in computer architecture, how you scale systems to a larger number of cores, number of processors. How do you solve that consistency problem becomes difficult. We'll get to this. I don't understand this perfectly, no problem, but I like thinking about analogies of life when I think about architecture because in the end, what we design is a reflection of what we do in life also at some level. Don't take that too far. Okay, so your first assignment, even if you may have been there, is to go and visit Banff-Stadlhofen. It's not that hard, I think, for many of you. An extra credit, repeat for any other Kaltrava building until you reach the end. By the way, this is an example of an algorithm also. We will talk about an algorithm in a little bit. An algorithm has precise steps, and I tell you a precise step. Go and visit Banff-Stadlhofen. And the second is repeat for any other Kaltrava building. Assuming you have a finite list of Kaltrava buildings, you can define a precise step for each of the steps of this algorithm, right? And an algorithm has three properties. I'm foreshadowing some of the slides, but each step has to be precise. Each step has to be effectively computable, meaning you should be able to carry it out as a human in this case. It's a human algorithm. If it's a computer algorithm, the computer should be able to carry out each step, right? In this case, I hope you are able to carry out and go all of the buildings. Of course, that's dependent on financial constraints and whatnot, but it is possible to carry it out, assuming other conditions are satisfied. And the last important piece of an algorithm is, what is it? Have you guys learned about what an algorithm is in the past? Probably not. Yes? So you can tell me what it is. Maybe not. Where did you learn about an algorithm, by the way? Yeah, exactly. It has to terminate. That's the third critical thing. And in this case, because the list of buildings is finite, the algorithm should be able to terminate, right? Okay, well, now you can execute this human algorithm as part of your first assignment. I'm happy if you just go to Bono Stadlhofen. And I would encourage you to appreciate the beauty and the out-of-the-box and creative thinking of the structure, and think about the trade-offs and the design of the Bono. And you will come out with many, especially after this course, but I think even before taking this course, you can come out with many in terms of the trade-offs that are made in terms of cost, space, functionality, dot, dot, dot. We apply these to computers also, actually. Cost is a big consideration in any computer we design here. But you can trade-off cost for other things sometimes, right? Energy efficiency is a big consideration. Performance is a big consideration. Reliability is a big consideration. Availability is a big consideration. How much it burns your hand is a big consideration, right? Whether it actually catches fire should not be a consideration probably, but these things happen, right? Because people trade-off in different ways. Maybe they go too aggressive in some of the trade-offs as a result, like they may sacrifice reliability, right? And you can think about the strengths, weaknesses, and the goals of the design. It's always good to think about that whenever you go to an architectural building or think about a computer, like these two are different things, and that's clearly a different thing that has some computational power in it also. And due date is any time during this course, and you can feel free to email us about it. But later during the course is better, I think, because the weather is better probably, but also you will hopefully learn more about how to make these trade-offs. And you will also see the basic building blocks of computers going forward. And you can apply what you've learned in this course, and hopefully, going forward, think out of the box. But I really love about these kind of architects as they're really thinking out of the box, and they're really pushing the boundaries of architecture or people who are doing computer architecture, they're pushing the boundaries of computer architecture, engineering, science. And I think that's critical. As ETA students, that's, I think, critical for you to learn. Because that's actually one of the big missions of ETA, it's founded to create people who can leap Switzerland forward in both government and management and science. All of those at the same time. Okay, but first, let's come to today. Is everybody happy with this assignment? That's easy to do? Okay, who's going to do it? Excellent, I'd like to see more hands later on. Or maybe the rest is not listening to me. Okay, let's look at some things. Find the differences of this and that. That's another puzzle I like to play. This you've already seen, that is something else. Do you know what this one is? Probably not. Probably you can try to guess what that is. You can read it over there, but it's blurry enough that you're not going to read it hopefully. You can apply algorithms to actually discover what that is perhaps with some probability. There's something that's written over here, right? Or maybe your brain is good enough to actually do that processing and comparison to all of the names in the world and figure out what this is. But I think, I mean, I'm not going to go through what are the differences between this and that, but you can see that this is a regular, if you will, train station that's not constructed with the same goals or same care or same idea and same trade-offs that Kalatrava had in mind clearly. And of course it cost much less, I assume, than this one. So there are trade-offs clearly, right? And maybe there are some other trade-offs. There's more space here. You don't have to be as careful as you have to be in Stadlhofen. Well, I'm sure there's some regulation that says it has to be this much space, but you can have more, right? So that's the concept of margin, right? We use the concept of margin in computers also. You don't clock your computer at the highest frequency possible, but you leave some margin. Instead of clocking that three gigahertz, you clock it at 2.6 gigahertz because you think something may happen. You may not have tested it well, so you leave this margin. So these are very, actually, these are engineering principles that you will find in this course also. So clearly this margin, well, depending on how you look at where you should really stand, but assuming this is what you consider, where you should stand behind, which you may not consider, but this is the margin, which is probably larger than this margin over here, which means that the danger in this design is probably higher compared to the danger in this design. And later in this talk, we're gonna talk about faults. Computers have these faults also. You can get errors in memory. And part of that maybe because there was not enough margin. Some people argue that some of the cell phones in the world burn because there was not enough margin in the case between the case and the battery, right? If that margin was large, then you would not get, the thing would not burn basically. So that's the concept of margin. Okay, so there are many trade-offs between the two designs. Of course, when you make trade-offs, you need to have a basis to make trade-offs. And that's really the evaluation criteria for the design, right? And there could be many evaluation criteria. We will talk about that hopefully in the next lecture if we get to it. If not, we'll do it later in the course. But at least for these two different designs, I jotted down these. This is not meant to be a comprehensive list. Functionality, does it meet the specification, does it work? Reliability, does it work reliably? For a given specification, space requirement cost, can you expand it? That could be a consideration in the design of a system, right? Can I expand this, Bonhoff? Actually, the reason it was rebuilt in 1983 was because they wanted to expand it because the train routes in Zurich changed if you look at the history of those routes. They wanted to change the routes. As a result, they want to expand Stadlhofen. And I think there's still discussion on whether people want to expand Stadlhofen even more, right? I'm not sure if it can happen within that space, but people get creative, right? That's the beauty of architecture and engineering. And there are other things, comfort level of users, right? If you care about that, that's important, right? And a lot of the success of something like this has come about because people really cared about that, right? Happiness level, which may be different from comfort. Aesthetics, dot, dot, dot, right? So I think my point is, how to evaluate the goodness of design is always a critical question. And you've got to come up with some metrics to evaluate the goodness. And we will come up with metrics later in this course to evaluate the goodness of digital circuits, computer architectures. And you will see that it's not as easy to do, there's no single metric to optimize for. And you usually trade off between different metrics. Okay, key question. I'll ask this also to get you thinking a little bit. How was he able to design, especially as key buildings? Stadlhofen is a good one, sure, but it's probably not his masterpiece yet. What about the other ones? What do you think, what went into it? I mean, this is a very open-ended question, of course. I don't expect a single answer, but anybody want to mention a single guess? What's the most important thing? Yes? Inspiration. Inspiration, that's a good one, actually. Practice, that's good. Now you can discuss which one is more important, right? Well, maybe all of them are important. What else? Yes? That's good, yes, out of the box thinking, which may be related to both, I don't know. May not be, yes? Money, that's good. That's important, yeah? You gotta have some funding to be able to design, especially something like the Oculus. What else? Observation, learning about the past, right? Maybe, or maybe not past, well, I guess what exists is past or present, but observing what's happening in the outside world and applying it, right? Or maybe observing the past designs that people are made and saying, no, this is not good, right? I don't want this. That's also fine, right? Let's have things improve, that's critical thinking, that's critical way of looking at things. So yeah, you brought up many good points, some of which I cover over here, some of which I don't. I'll put this, there's no ordering here. I just jotted that now, basically hard work, perseverance, dedication over decades, experience, creativity, a good understanding of past designs or nature also, good judgment and intuition, strong skill combination. If you look at his history, he's not only an architect, but he's also an engineer, also a sculptor, right? And funding, all of these. And luck probably, luck actually affects things also. You will see that sometimes, luck affects the designs that you make in the real world also as computer architects. Sometimes because you're too early in designing a very aggressive microprocessor, you just cannot sell it, you cannot find customers. If you were 10 years later, maybe you will find a lot of customers. So that's part of the luck or timing. So there are a lot of things in the equation. And I think, I will talk about these two going forward in this lecture, but there's no, keep these in mind when we talk about design in this course. You will be exposed and hopefully develop and enhance many of these skills in this course. I'm not promising you any funding, sorry. But hopefully some of these other ones I can help you with, especially the last two over here. And I think luck, I will have a comment later on. There's some very famous person who says, luck or chance favors a prepared mind. So you can actually turn the dice toward yourself if you're actually prepared with perhaps some of these ways. Okay, okay, principle design, let's take a look at it because I think this is really common across many architects, but also computer architects as well. What is principle design? This is, in Kautrava's words, to me there are two overriding principles to be found in nature which are most appropriate for building. One is the optimal use of material. The other, the capacity of organisms to change shape, to grow and to move. And you can interpret it in different ways or ask him what are the details. But clearly he has principles in designing these things. And I think I took this from Wikipedia, but Kautrava's constructions are inspired by natural forms like plants, bird wings and the human body. Actually it's not Wikipedia, it's this arc space site. So this is one example and principle in action, right? Can you guys see something here? Animals, humans, insects, yeah? What? A turtle. A turtle, yeah, it could be a turtle also, yeah, that's right. That's the beauty of architecture, you can interpret it in different ways, especially beautiful architecture. What do these things look like? Like you can see a head, arms, legs. What if I superimpose something like this from his drawings? It's really humans or whatever animals, whatever imagination that you come up with that's really keeping this upright. So you start with the sketch and it turns out into this. Actually I don't, this is really interesting because this is exactly how computers get designed also because you will start with sketches, maybe not exactly artistic in the way they are here, but they are going to be artistic in some way and form. And one other example of this is, how many of you have been to the Sydney Opera House? I know it's far, so that's, okay, I'll introduce another principle in architecture because this is probably the right time and that's the principle of locality. Do you guys know the principle of locality? Locality means you access things, you basically, it's likely that you're going to access things that are closed by to what you've accessed. Basically the fact that you've been to Stadlhofen means that you're really exploiting the principle of locality or accessing things that are closer. Whereas Sydney Opera House, I saw only three hands, right? It's far, it's not local, if you will. So a lot of the computer architectures today are designed to exploit locality. It's if you're going to access things, you put things together and access things that are around it a lot. Whereas you don't access things that are far away a lot. Okay, you can think of this as a principle of locality. And we'll see why this happens, but it's clearly, it happens because of the proximity. And you will see that, I think, well I don't know if it'll happen with this class of the size, but and maybe you'll prove me wrong now that I'm going to say it. Most of the time you will sit next to someone whom you've sat next to before in the past. Or you're going to sit in the vicinity of where you've sat before. That's, again, the principle of locality. In computer architecture, we exploit principle of locality by using what's called caches. If a processor accesses a memory location, you bring it to a small piece of memory that's close to the processor, that's much faster. And because the principle of locality holds, when the processor requires it the next time, that location next time, now it's in the cache. You get very quickly. Instead of going all the way to the hard disk or memory to get that value again and again and again and again. Okay, that's a very fundamental principle and all of the processors that we know of today are designed based on that principle. Okay, so Sydney Opera House, let me pull back. If I do this without moving, you should tell me, oh, you told us about the Sydney Opera House, what about it? I was about to move to the next slide. So Sydney Opera House is also amazing. It's actually one of the most difficult buildings that have been constructed, I believe, in the century. But it started out from a sketch like this. I wish I had it. Maybe I'll try to have it for the next lecture. And everybody said it's impossible to build. But it was built and if you look at it, if you go there, you will enjoy it, I think. Okay, so a principle design. Basically, we're going to design based on principles. This was one of the principles of called Java. I guess people call it zoomorphic architecture. But basically it's the practice of using animal forms as inspirational based and blueprint for architectural design. And you can read the rest, if you will. And you can see that called Java's buildings are listed as part of the zoomorphic architecture. So what does this remind you of? I guess I've already told about this, but it looks like a bird, right? Yeah, and in fact, it was imagined as a bird and if there were more money than $4 billion, this would be opening and closing also. But unfortunately, I guess the city of New York was not rich enough to pay for more than $4 billion. Okay, same puzzle, different example. I'll go through this relatively quickly, but I think this will give us another example, architect, if you will. Does anybody know this? Yes? Wow, you guys are amazing. How do you know it? Oh, what is it, first of all? Do you like something? Yes, absolutely. Do you know what it's whereabouts? Do you know what it's whereabouts? No, where is it? It's in the US. It's actually from where I come from, from very close to Carnegie Mellon University, close to Pittsburgh, not exactly there. It's one and a half hours almost. It's called falling water, actually. If you wanted to cheat, you could have cheated. That's okay. It's good that you don't cheat. We don't want to cheat here. But it's a beautiful building. And if you look at this, this is not only on top of waterfalls, but also it's really imitating the waterfall itself. If you look at the top cantilever over here, it looks like this. The bottom one looks like this. And there's more in the building. But it's really in harmony with the nature that's around it over here. It's an amazing building, I think. I've been there many times. And actually, when I used to teach a version of this course at Carnegie Mellon, I used to start with this building. Clearly, because Americans don't know anything about anywhere else other than America, right? That's, so, especially going forward, it's going to be that way, probably. More. And this is another view of it. It's another beautiful view, I think. This is another view of it. Okay, I'll stop. So do you know who built this one? Okay. Silence. Oh, I see. Absolutely, excellent. You get brownie points. It's Frank Lloyd Wright. He is one of the most famous American architects. And basically this falling water. You can read about it. Basically, it's actually cited as one of the most beautiful buildings in the world, even though it's, you could consider it almost in the middle of nowhere, right? It is in the middle of nowhere if you're not close to Pittsburgh. But he was also a principled architect. We'll get to this. And I'll do the same game if you want, same puzzle. You could do this with many architects. We could do this for the rest of this course and I'm not going to do it. But you could do it if you want. So this is this and this is that. Now you can apply the same thing to trade-offs, right? Clearly, this is more costly again. And again, this is one of those buildings where the architect didn't ask for some amount of money, but they figured out that they cannot complete what they envisioned with that amount of money. So they asked for more and then they asked for more. And this was funded by a family. It's the Kauffman residence, actually. I don't know if it's somewhere here. The Kauffman family is not here. Oh, there you go, Kauffman residence. That family funded it. And eventually they said, no, we are not going to pay for more. Let's get it done. We want to live here. It's similar to the Oculus, Oculus actually. The wings are not moving up and down because they said, no, we're not going to pay for more. Okay, but this clearly, this is not a bad house. It's okay. Maybe I don't mind living there if I like the surrounding area, but I prefer living here probably. Although this depends on your choice again, right? So clearly there is a space for different types of buildings or architectures also, right? Sometimes you want a very powerful computer, but you cannot carry it with you to do climate simulations. Maybe nobody can carry it with them, right? But sometimes you don't want a powerful computer. You just want a good enough computer that you can carry with you, right? That's good to think about. Sometimes you want a really cheap computer, like less than once with Frank so that you can do something really, really simple and stupid with it, but it would be useful for you, right? So clearly there are benefits to different buildings also. That's not to say that this building is useless. There is a space. And we will see that a lot in this course also. You have all types of computers. You have all types of processors, right? Some processors are extremely fast. Some processors are extremely slow. Some processors use sophisticated techniques like auto-order execution to get high performance. They basically execute the instructions in the program. Out of the order, the programmer specified them so that they get much more parallelism out of it as a result, much more performance. As a result, they are more expensive. They occupy more area and they occupy more power. Some other processors are very simple. They execute everything in order. They actually can execute only one instruction at a given time. No more than one instruction can be present in the pipeline. And we'll talk about pipeline also, but if you can think of it as an assembly line, you get the instructions. So that's a much cheaper processor. And there may be benefit to that processor, right? If all you do doesn't have parallelism, then you'd want that simple processor, perhaps, right? It's cheap, it's energy efficient, and it gets the job done. So that's the concept of having different kinds of types of architectures for different purposes. And now you can say, oh, I want all kinds of jobs. I have a job that has both characteristics, right? That's good for auto-order that I want high performance and I'm fine with paying more energy. And I have parts of my program that are really simple. I don't need auto-order execution. And when I'm executing parts of my program that are really simple, I want this processor to be there. And when I want really high performance, I want this processor to be there. So why don't we put the two processors together? A large processor and a small processor and design the upper layer such that it orchestrates the movement of the program between those two so you get the best of both worlds. And that's the concept of heterogeneity. Basically you have a heterogeneous system that consists of multiple different types of processors and you manage it to get the best of those processors. Of course, clearly this adds more cost and also management complexity. So there's a trade-off here that you're making. Instead of a single type of design, you want some heterogeneous design. You may see that in the buildings also, actually. But this exists, for example. ARM's big, little architecture is an example of this. At least in the first incarnation, I believe they had one big core and four small cores and they're able to move the program that's executing from the big core to the small cores when they're, let's say, running out of battery, if you will. It depends on the operating system, of course, to figure out how to manage this big, little system. And we will see later that we may have heterogeneous memory systems. One type of memory may not be good enough for everything. We may want some other types of memory next to it also. Okay, let me get back over here from the examples. You can list these trade-offs later on also, but you don't have to do that. I'm starting to hope that it's good enough if you do it. So I'll do the same thing. You can have many guesses as to how Wright was able to design his masterpiece. In this case, this is his masterpiece. It's considered that way. Clearly, a principle design is one of it and I'll give you another example. So all of these architects had principles. Wright's principle was a little bit different. Basically, he was not a proponent of doing business as usual, basically. And he had very strong views on this. You don't want to base your architecture upon precedent. Maybe you don't want to be influenced too much by precedent. You want to learn from the precedent, but you want to base your architecture on your principles. And that's how he was able to come up with it. So this is a precedent. This is a more principle design, at least for him. So what's his principle? In this case, it's an organic architecture. It's basically a philosophy of architecture which promotes harmony between human habitation and the natural world through design approaches so sympathetic and well integrated with its site that buildings, furnishings, and surroundings become part of a unified interrelated composition. Oh, that's a mouthful of words. But it's very, all of this is very present in the falling water picture that we've seen. Okay, any questions so far? Anybody bored of this? Saying we should move on? Yes, you are. Okay, we will move on, don't worry. We're almost there. Okay, so principle design, we talk about it, but also there's a strong understanding of and commitment to fundamentals which is also going to be a hallmark of this course. So this clearly did not come about immediately, right? You started with this and then it somehow turned into this. And then later on, when Kalatrava took it, you start with basic building blocks, right? Clearly these basic building blocks is not something magic. In the end, what may end up may look like magic, magic like Oculus, right? But you start with wood, right? You start with steel. You start with basic materials and you start with methods of connecting them. Just like we will start in this lecture with transistors, logic on top of that, devices on top of that and the logic on top of that. And you'll learn how to construct architectures that way. Of course, there's other things that go into this like civil engineering, but we're not here for the real architecture course. But clearly these things got constructed from some basic building blocks and you really need to know those basic building blocks to do something really creative. And the end result is this basically. So takeaways, basically it all starts from the basic building blocks and the design principles. And the goal of this course is to teach you that in digital logic and knowledge of how to use and apply them. And we'll talk about that. Actually, that's why we have labs in this course that are really important. I know you're not here for grades, hopefully not, but 25% of the grade will be determined based on labs. And you will figure out how to use them and apply them in those labs. I will definitely encourage you to attend those labs. And underlying technology might change. You might do it with steel, wood, or something, whatever. In computer architecture, you might do it with different types of devices. It doesn't have to be CMOS devices that we have. It might be quantum devices. It might be some other devices that may come. Paste change devices, which we may talk about later in the course. That may change, but the methods of taking advantage of technology bears resemblance. Those principles do not really change. Methods used for design depend on the principles employed. And you will see that in this course. So let's look at some computer architecture now. Basically, the same thing applies to processor chips. Basically, there are basic building blocks and design principles. Whatever you design over here, and these are actually very different processors. It's a multi-core processor. This Intel's multi-core, IBM's heterogeneous processor, IBM's multi-core, Intel's single chip cloud computing, NVIDIA's GPU, some other multi-core, and some other multi-core. Basically, the design principles, the basic building blocks are the same. You start with digital logic in the end. And we'll take a look at that. And again, it's the same over here. It's the same over here. And you can see this. This is a beautiful architecture, right? This is one of the, I think, Verizon's data centers. Okay, so basic building blocks. Clearly, electron is one basic building block. And we will talk about the transformation hierarchy in a little bit. But we cannot manipulate electrons, unfortunately, right? We cannot take one electron and put it next to the other one and make it move, right? That's not how we do. So we create abstraction layers on top of this. We build a transistor that can actually work with the electrons, if you will. Basic principles of electrons. Logic gates on top of those transistors. And on top of those combinational and sequential logic circuits and storage elements and memory. And on top of that, cores, caches, interconnects, and memories, and on top of that, computers, right? It's really a very principled way of building things. So I'll give you your first other assignment, if you will. Startle-hofen is good, but it won't teach you anything about computer architecture other than thinking about things and imagining how it applies. So these are your first reading assignments. This is for this week. We have two books you can do either one. If you do both, you will learn more. This is the required one. So if you do this one, that's good. It's chapter one in Harris and Harris and chapters one and two in Pat and Patel, basically. How many of you have the first one? You can actually get the PDF. Okay, great. Probably not many of you have the second one, but we have it in the library and we may actually put the PDFs in a secure place. And the third reading assignment is the supplementary lecture slides on binary numbers. We're not gonna cover binary numbers in this incarnation of this course. You've probably seen binary numbers, right? I mean, yes? Who's known binary numbers? Okay, excellent. Yeah, but if you want to brush up, we will put lecture slides on binary numbers, like how to do arithmetic on binary numbers. Should be a piece of cake for everyone here. You're a TEHA student, so. The bar is high. Okay, so let me give you a little bit more about this course and we'll take a short break and then we'll continue after that. So these are the major high-level goals as I see them. Basically, we're gonna focus on digital, circuit design and computer architecture and we will see how these things fit together in a little bit, but we'd like to understand the basics. That's the goal. The first goal is to really understand the basics, the principles of design and some precedents also, like how people design things. Actually, you're going to build, at the end of this course, you're going to have a design implemented on an FPGA that's based on a precedent, basically, someone designed this for you, basically, and you're going to implement it. And that's going to be very instructive because you're gonna go all the way into the details of the design and make it work. And based on such understanding, we'll learn how a modern computer works underneath. We'll learn how to evaluate trade-offs of different designs and ideas, hopefully, and I think this is really critical for engineering. And we'll implement a principle design, a simple microprocessor, as I mentioned. It's not going to be a full microprocessor because that's going to take a long time. It's going to be a subset of an ISA, Instructions at Architecture, that's used today. And you will learn to systematically debug increasingly complex systems. That's going to be important because a lot of what you will do in this course will be debugging your designs. Sorry for the news, but that's exactly how things work in computer science and engineering, all the fields. It's not only about designing and then implementing. Actually, it's really about debugging. If you look at a company like Intel, when they design a processor, the latest processor, it doesn't matter which processor. Actually, the latest one has a higher number. What fraction of the cost of that processor actually goes into test and verification and debug, you think? Anybody, when should I guess? 30, I heard. 70. 80. 80, okay, increasing, it's like an auction now. So I don't know the exact number and I don't think Intel wants to disclose those exact numbers, but it's clearly more than 50% at this point in time. It used to be 40% at some point, but it's increasing basically. The time spent on testing and verification and debugging is increasing. And there are many, you do this testing during design, during implementation, and after the processor is actually out. The first thing that is done in a Silicon lab is post-silicon debug, right? You basically take the silicon and make sure it works or check if it works. That's the post-silicon debug process. And if you actually put things into your design that makes the process easier, you pay less cost, perhaps, on that post-silicon debug, right? Okay. And hopefully, in the end, this course will enable you to develop novel out-of-the-box designs. That's not a requirement of this course because it's a very introductory course, but hopefully in the chain of events, it will enable you to develop those designs. So our focus is on basics, principles, presence, and how to use them to create and implement good designs. So let me cover this slide and then I'll take a break for five minutes and then we'll continue. So why do we want these goals? Well, clearly because you're here for a computer science degree and I believe every computer science at TAB leaves every computer scientist needs to know this stuff. But I think there is something more to it. Regardless of your future direction, I think learning the principles of digital design and computer architecture will be useful to design better hardware clearly, but also design better software and I'll give you some examples of this because understanding what goes on underneath really enables you to design the upper layers in a much more cognizant way. Design better systems in general because you know this stuff well. Make better trade-offs in design. We'll talk a lot about trade-offs. Understand why computers behave they do. Well, this is a very high bar. I don't actually understand why computers, why this computer slows down for example. If you actually solve that problem, I think you can be extremely rich if that's your goal in life. If you figure out a way of automatically telling the person or telling someone this is the exact reason why this computer slowed down and I'm gonna fix it automatically for you and make it work. That sounds like a great startup idea. If you have ideas, come to me. I'll fund your initial thing if you have a good idea. Okay, solve problems better. I think that's one of the most important things. We're gonna solve problems here. The goal of computing is to solve problems. So we're gonna see how those problems get solved underneath at the very, very low levels. Think in parallel. I think this is really important actually when industry transitioned from single core, single processor designs to multi-processor designs. One of the big issues was, oh, people don't know how to write software in parallel. And that's most of the time true probably. But hardware, if you think of it, it is inherently parallel. So you're going to design a circuit at the end of the course and during the course, you're gonna see that there will be signals that are moving data concurrently. You have to reason about them. You're not going to be able to say, oh, this signal goes first, this signal goes next, and then this signal goes next, and then this signal goes next. No, those signals will operate in parallel at the same time. And you're gonna get used to thinking in parallel. That's why having this information and this knowledge and doing this course will help you think in parallel and hopefully maybe write better, more parallel software as well. And think critically. I think we have the critical thinking initiative at Etihad, which is I think really beautiful. All of you should be thinking critically on about everything, if you will. That's how we can make the world better. Even though politicians in some part of the world may not like thinking critically. You guys are different. Okay, good, this is a good place to stop. Let's take a break for five to six minutes. No, you want 10? Okay, 15. 10 minutes, 10 minutes. Come back at 14, 15. Okay, can you hear me now? How about now? No? Not working? Okay, let's get started. These bells are nice because now hopefully they can stop me from overrunning the margins. I like operating at the margin, so. I don't know if you can close this, but maybe not. That's okay. As long as you can hear me, that's okay. Okay, so hopefully that has given you, thank you, an idea of what we're going to cover. But let's start with why do we have computers? Can anybody have a guess? Like why do we have all these computers? Entertainment, okay, excellent. What else? To get things done for us, that's good. That's good, calculations. To get things messy, okay? Netflix? Sure, yes. Anybody else? No? There's a slight, so I cannot see this. There's a blind spot here that I cannot see. So if you're over there, then tough luck, you'll have to shout. Okay, this is a good start. I will argue that except for to get things messy, but even that, perhaps, I could fit into the reason that I have over here. Basically this, to solve problems, right? Entertainment is a problem. If you want to create mess, you have a problem, and the computers can solve it for you, right? Basically, computers are created to solve problems, right? So how do computers solve the problems? Well, I guess there's a huge variety of answers here, so I'm going to give you my answer by orchestrating electrons in the end. They really, that's what they do, right? In the end, they orchestrate the principles of physics to solve the problems, yet there's a huge gap between problems and electrons, right? You cannot, as a human, say electrons, please do this for me, right? If they hear you, which is a challenge, how will they respond to you, right? It's not clear. So you clearly don't have a way of directly talking to electrons. So there is a way, and that's through the levels of transformation, but I'll introduce it with this. So there's a beautiful quote by Richard Hamming. He said, the purpose of computing is to gain insight, which is, I think, a really good way of thinking about it on problems, maybe. Do you know about Richard Hamming? How do I know? I heard Hamming Distance, good. Where did you hear about Hamming Distance? Discrete mathematics, last semester? Okay, excellent. So I can ask you questions about Hamming Distance and you'll tell me everything. Okay. Okay, that's him, with his cat. Now we can forget about him for a while, not fully. But we gain and generate insight by solving problems in the end, right? That's how we gain insight into things. The question is, how do we ensure problems are solved by electrons? That's what I mentioned earlier. Basically, we start with this problem specification at the high level and we want to make sure the electron does what we want and solve the problem. As I said, we cannot directly speak to this guy over here or girl over here who's moving. Too fast probably for us. So we transform the problem into an algorithm, right? So this is the levels of transformation we're going to go through. And all of computing is built on top of these levels of transformation. Although there are some differences at the middle layers, if you will. We will talk about that very briefly today, but you will get to see that when you actually put your designs as well. So I've already given you what an algorithm is. It's really a step-by-step procedure that is guaranteed to terminate. That's one important part, where each step is precisely defined and can be carried out by a computer. So finiteness is basically, so you have definiteness, precise definition. Finiteness can be carried out by a computer the other way, finiteness you can terminate. Definiteness, each step is precisely or definitely stated, and effective computability is effectively computable by a computer. You can have a human algorithm that needs to be effectively computable by a human, right? You can think of humans as computers also. Actually, there's a field out there that thinks about neuromorphic computing, if you will. That's essentially trying to use the principles of human brain to design computers, right? Can we somehow do that? We're not gonna talk about that in this course. That's more advanced, but if you have interest in that, you can search for it and you can look at it. But you need to know what an algorithm is. Basically, if I throw it to an algorithm, or something that looks like an algorithm, you can tell me whether or not it really is an algorithm, right? So for example, if you give me an algorithm where I have to jump over this building to get to Zurich, then that won't work for me because that's not computable by me, right? Sorry, I cannot do that. Similarly, you need effective computability for what a computer can compute. We may talk about what a computer can compute later. That's really going into the theory of computation, but that's really not exactly the topic of this course. Okay, then you take the algorithm, transform it to a language that enables the computer to understand this algorithm. Human languages don't have this property. Although computers are getting really good at understanding human languages, they're still not as good, right? Actually, one of the important tests in computing is you put the human next to the computer, but the human doesn't know that he or she is speaking to the computer. Can actually the computer fool the human that it is a human, right? That hasn't been done yet, unfortunately. If you can do it, again, you can probably be rich. Okay, but the natural language that we use is not appropriate for computers because we use a lot of ambiguity in language. And that's actually problematic for computers because they don't like ambiguity in general. Although the field is changing quite a bit, so keep this in mind, there's a lot of machine learning that's happening today that could potentially change that, maybe not in the design of the hardware itself, but think about it. Okay, so you need to translate to a program language and many of your programs with different languages, I assume. What's your favorite language? Java? C? C++? Yes, C, okay, good. C sharp, there are many of these, right? They're developed for many different purposes and when you take the languages course, you'll understand why they're there. But that gets translated or that gets run on top of a runtime system, the operating system, virtual machine, memory manager. That does all of these tasks for the program to run on a computer. So this thing exists in many computers today. Not all computers. I mean, if you actually directly put a program into hardware, that doesn't exist, but we were talking about general purpose computers over here. So the job of the OS operating system, virtual machine or memory manager is to do resource management, manage the underlying hardware resources. And the program gets compiled into ISA, what's called ISA, Instructions at Architecture. How many of you have heard of this term ISA? Okay, good. You're learning something, ISA. Or ISA. This is called Instructions at Architecture. Basically, we'll talk about it later again, but it's really the interface or contract between the software and the hardware. This specifies what's an instruction, for example, an ad instruction. How is it encoded? And what will the hardware do when it receives an ad instruction? That's part of the ISA. What will the hardware do when it receives a load instruction from memory? What will it do when it receives a multiply instruction? Okay. And there's always the question of, what are the right instructions to put into architecture? We're not gonna deal with that a lot in this course. Later, if you take a more advanced computer architecture course, we're gonna talk about trade-offs. Like what should be the grand loyalty of an instruction? Should it be at the grand loyalty of an ad, or should it be at the grand loyalty of, I don't know, encode this video for me with these inputs? That could be an instruction, right? Assuming you specify it well, and if you define the contract between the software and the hardware, precisely. But basically, this is what the programmer assumes the hardware will deliver. Hardware promises, and the programmer assumes that, and assuming, and then that interface specifies how that's communicated. And this is critical. That's part of the layer that we're going to talk about. There are many different ISAs in the world. X86 is one of them. That's probably used in many computers, many machines that you have, that's Intel's and AMD's ISA. I guess it's called IA-32 sometimes by Intel architecture. But IA-64 was another ISA that Intel developed to go to 64 bits in terms of their operands, but that didn't work out too well for Intel. We're not gonna go into the details of why not, but ARM is another ISA. A lot of embedded systems use that ISA, but these are basically interface specifications between the software and the hardware. A good way of thinking about the ISA is, what should the, this is essentially what should a programmer need to know, programmer meaning the low level programmer, to actually write programs on top of a computer. So underneath, we'll talk about this more. Underneath ISA there's another level, that's really the micro architecture. So this is what the programmer doesn't get exposed to, but this is how the ISA, the instructions are actually implemented by the hardware. These are basically building blocks, controller, for example. It's really an implementation of the ISA. For example, Intel's x86 ISA has many implementations. Pentium 4 is one of them. How many of you know about Pentium 4? It's probably too old for you. Yeah, you guys are young. Intel Core architecture, Core i7, for example, is another example of an implementation of the ISA. They all implement the x86 ISA, but they're all different organizations underneath. For example, Intel had the Pentium a long time ago, that was the first Pentium, and it was actually an in-order processor. Internally, the micro architecture was in order, meaning it executed the instructions in the order the programmer specified them. As a result, it was lower performance. But later, Intel moved to the Pentium Pro architecture, which is really the predecessor of a lot of the Core architectures. They actually incorporated auto-order execution into it. So that's a clearly different implementation. You can execute instructions in the order the programmer specifies them, and as a result, probably have lower performance. Or you can execute instructions in the hardware in a different order. You can say, oh, this instruction I can execute earlier, even though it comes at a later time or later place in the program. But I can say that if I execute it right now, it's okay because other instructions don't depend on it. Or because I don't need the inputs of other instructions to execute it. So if you can do that, that's a much faster processor, but that's a different implementation. So this is a clear example of how the same ISA can be implemented underneath. Another example is how do you implement the add instruction, right? Even something as simple as that is interesting, and you'll implement adders in this course. I'll foreshadow it a little bit. You can have an adder that's really slow, that adds bit by bit. Every cycle, every clock cycle, we'll talk about that also, you add one bit. So if you wanna add 32 bits, you wait for 32 cycles. It's small, but it's cheap, right? It's small and cheap, but it's slow, right? That's the trade-off. Or you can design a humongous adder that basically adds many, many bits at the same time. 32 bits in parallel, right? More costly, but faster, right? These are two different implementations of the same add instruction, right? That's part of the microarchitecture. It's really the implementation. How does the hardware implement things to satisfy the contract? Because hardware doesn't need to do it exactly the way it's specified, or the programmer thinks it may happen, as long as it satisfies the contract, as long as it delivers what it's supposed to deliver to the programmer, there's no problem, right? This out-of-order execution is fascinating, for example, because the programmer thinks that things are executed in order, but actually they're executed out of order. Now of course there's a contract in many ISA saying that you can execute things, saying that the results that are exposed to the programmer eventually have to be in order. So if I'm actually debugging this program, I have to see that things happen in order, right? So the microarchitecture needs to, obey that contract in the end. And how we do that, we'll see that later in the course. It may sound like magic right now, but that's one of the fascinating things about architecture design. And many systems today are actually out-of-order processors. This is most high-performance designs. Of course they're more costly and higher performance at the same time. So this is out-of-order processors, for example. Okay, so underneath there's a logic layer. Basically these are digital logic circuits. These are the building blocks of microarchitecture. For example, gates, logic gates. To build an adder, you need to use gates to build that adder. So this is another level of abstraction, a lower level than microarchitecture. And we will start actually around that level soon. You'll see more examples of this. And underneath there are devices basically, which we will not talk about that much. But if you do your reading, which is required, you'll see that there are different types of devices, CMOS devices, NMOS devices, and PMOS devices. How many of you know about this? Okay, some of you do, but some of you don't. But you will need to do your reading to actually know it, and we will get to it starting from next week. I don't wanna dedicate this lecture and make it the entire course. Supposed to be introduction. So this is what we're going to cover in this course. Basically we're gonna start very little with devices, if you will. We're not gonna go down into it. If you want to learn more about it, you should go to the ITET department and take device courses. Those are also fascinating. But we will mainly start with the transistor as a light switch, as basically the abstraction level on which all of everything else is built upon. And then we'll talk about micro architecture, ISA, and I put a little bit more from the blue part because I think that blue part is especially important. You really need to know the interaction between the software and the hardware. So we're gonna touch upon the runtime system, the operating system a little bit later on. But in a site, I guess I have to do this. Richard Hamming had a lot of impact other than his picture in the previous slide on computing. And this is actually the work where he introduced the error correcting codes, ECC, and where he introduced really the concept of Hamming distance. So since you know Hamming distance, I'm not gonna cover it. How many of you know Hamming distance again? Oh, excellent, there you go. Basically you can tell me this definition, but I'm not gonna bore you with it. Basically it's really the number of locations in which the corresponding symbols of two equal length strings are different, right? And this turns out this is really useful in error correction, right? Because you can actually have Hamming codes. And he developed a theory of codes used for error detection and correction. We may get to error correction later tomorrow, very little, just as an introduction of something. But I would also recommend, he has a lot of inspirational talks on how to do research, how to actually have the right mindset to do research. If you're interested in that direction, I would definitely recommend his lecture that he delivered at Bell Labs in 1986. He did a lot of his research at Bell Labs. Okay, so I'll give you another view. So critical thinking is important, as I said. Maybe I'm not as smart as you guys. When I first saw that transformation hierarchy, it was good to me. But over time, I thought, oh, maybe there's more into this transformation hierarchy. So this transformation hierarchy is actually different from what you would see in your book or in any of the books. It's basically on my slides. You're not gonna find this anywhere else unless they copied my slides or unless they had the same kind of thinking, perhaps. But I think there is another way of looking at the transformation hierarchy, and I think that's increasingly important. So I'd like you guys to think about these things in this lecture or in this course. It's really the user-centric view of the transformation hierarchy, right? And today, especially more than ever, we need to think about as computer designers, regardless of whether or not you design software or hardware, right? How does the user view this hierarchy? Yeah, that's not aligned, I'll fix that. But basically, perhaps the entire stack should be optimized for the user, right? This is not something we do a lot today. And if you do it well, like some people have done, this actually is good, right? It's good for the user. Of course, the question is who is the user? It always comes about. But I think about it when you actually, the user can be the programmer, the user can be the problem definer, the algorithm definer, or a user can be interacting with the system. And sometimes the user, the hardware designer, actually, I should actually change it, right, see? I'm thinking critically right now. Probably the user may interact with the ISA just like you guys, because you guys will be doing that, the assembly, programmer, and micro-architecture and the logic and the circuits. Okay, so there are implications of this also in programming languages. How do you design the programming language to input what the user wants, right? For example, can the user ask for a quality of service from a program? How do you design the operating system such that the user actually can convey their input while it's running? Today, I think the operating systems don't have that kind of view as much. Clearly, there are interfaces, but maybe we're not able to communicate with them well our intentions on what we would like to do in computing. Okay. So all of this takes us to the power of abstraction. Really, we're doing this to abstract away things, if you will. So these levels of transformation create abstractions. What is an abstraction? Basically, a higher level needs to know only about the interface to the lower level and not anything about what's happening underneath. ISA is a perfect example of this, right? The higher level above ISA, when you write programs, assembly programs, let's say, you don't need to know anything about underneath. Now, I'll qualify that later. But for a functional program, you don't need to know anything about what goes on underneath. Micro architecture, you don't care, right? It just works, hopefully. Yeah, for example, even at the higher level, the high level language programmer does not really need to know what the ISA is even, right? If you write in Java, why do you care what the ISA is as long as you want a functional program, right? And how a computer executes instructions. You probably care about that less if you write in Java or JavaScript, right? So abstraction is great because it improves productivity, right? Otherwise, you would go crazy. If everybody in the world needed to know about how to communicate with the electrons, good luck, right? We're not going to be productive at all. You don't need to worry about the decisions made in the underlying levels. That's good because it's somebody else's problem. Yeah, for example, programming in Java versus C versus assembly versus binary versus by specifying control signals of each transistor every cycle. You probably are better off programming in Java as opposed to by specifying control signals of each transistor every cycle, right? There are not many people in the world that can do that. So then why do we want to know what goes on underneath or above? Like why do we have this course other than the fact that it's in the CS curriculum? Why we think it's important? Well, you would like to cross the abstraction layers in some cases. So as long as everything goes well, not knowing what happens underneath or above is not a problem, actually. Unless you want to have an optimization goal that's actually, you really want, you don't want just functionality but extremely high performance. Then you need to know what's going on, actually. And actually you could consider that as a problem, something not going well. Basically, you write a program. It's functional, it's great, it works, you get the right answer, but runs like a dog. It's extremely slow, right? Then that's a problem. Now, how do you fix that problem? You need to know what goes on underneath. Like why is this program is behaving? Maybe you will figure out that when you're running this program, you're not using your cache efficiently, right? You didn't write this program such that it fits into your memory. But now you need to know how the fact that memory exists, how big it is, how you need to lay out the data such that it fits that memory, it fits the cache. That's exactly why you need to know the underneath. But also there are other cases. Well, I gave you one example. What if the program you wrote is running slow? It doesn't run correctly. How do you debug it? Knowing underneath helps a lot, actually. The program you wrote consumes too much energy. Oh, good luck, right? Now you need to measure the energy somehow and figure out how to do that also, right? Your system just shut down and you have no idea why. This happens to me a lot, right? And someone just compromised your system and you have no idea how or why. And I'll give you an example of this actual later. Probably not today since we're going to run out of time, but tomorrow. But by the way, this lecture is supposed to be two lectures, I designed it that way. So we're not gonna cover all of the slides for today. Okay, and on the other hand, what if the hardware you designed is too hard to program? So this cuts across both ways. It's not just the software always has problems. It's also sometimes the hardware has problems. What if it's too hard to program? And we've seen that in many, many cases. This is a place where knowing the precedent helps a lot. For example, the IBM cell processor, I want to pick on cell, even though we're being recorded, that's okay. Basically, IBM cell processor that I showed in one of the previous slides was a monster to program. Nobody could program it as far as I know who was not an expert in the cell architecture, basically. And that's a problem. Then you need to know how to fix it, right? And we'll talk about perhaps, actually I will talk briefly about why it was hard to program. In my opinion, one of the reasons that why it was hard to program was because there was no coherence. So a cell had this large processor that was supposed to do operating system tasks or system tasks or task distribution. And then these smaller processors. But these smaller processors did not have something called coherence. Remember, I told you about two computers modifying the same data and making sure that it's consistent. Coherence is a mechanism that's designed in micro-architecture and hardware that makes sure that if this processor modifies this data element at this location, this other processor won't get the old value. They will get the correct value. Now if the hardware provides that seamlessly saying, okay, in the micro-architecture I'm going to provide you that such that the programmer doesn't need to worry about it, that makes life a lot easier for the programmer. Because now the programmer doesn't need to know, doesn't need to worry about, oh, if I manipulate this data over here in this processor, it should really not be manipulated over here also, right? That's a nightmare for the programmer. We cell had. Whereas if the hardware does that, the programmer can say, I'm going to manipulate the data however I want and the hardware will magically enable that data to be seen by the other processor. That's the idea of cache coherence or data coherence in general. We'll talk about that later in the course. But that's one clear example of a hard to program hardware, not having cache coherence. But that's another place where if you're programming the hardware and if you see these errors where, oh, you're manipulating this data over here but you're getting some wrong results, knowing how the cache coherence protocol may work would be useful or how the model works would be useful. But if the hardware you designed is too slow because it doesn't provide the right primitives to the software, that's another thing, right? It's actually getting harder right now. And again, this is what if you want to design a much more efficient than higher performance system? Clearly not knowing only one part of the system, one part of the stack will not work in this case. So if you're designing a supercomputer, for example, here there's a big initiative for the Swiss National Supercomputing Center, right? You may go and visit them. But they're not clearly saying oh, we're designing high performance software. They're designing high performance stacks. Because there's no way they're going to just focus on the software level and get a extremely efficient and high performance system. Okay, so crossing the abstraction layers. So I would like to leave the last five or six minutes to Daryon who just arrived. You need just five or six minutes, right? Okay, excellent. So you guys asked me some questions about the lab. So he will tell you a little bit more about the labs. So make me stop six minutes before. Okay. So you will learn all about the labs, don't worry. Okay, crossing the abstraction layers. There are two goals of this course in this, especially toward the second half. Although I think in the first two lectures I want to get you in this mindset because more than anything else, I believe this crossing of the abstraction layers is about the mindset that you put yourself into. If you start with the mindset saying, so a lot of people start with the mindset, I want to be a software engineer or I want to be a hardware engineer. I don't like that mindset and I wouldn't recommend that you go that way. It's better to have the mindset, I want to know both as much as possible such that I can cross the abstraction layers because you don't really know when you need one or the other. In fact, it's much better if you can cooperate between the two. So there are two goals of this course. One is to understand how a processor works underneath the software layer and how decisions made in hardware affect the software and programmers. So these are two things. And the second is to enable you to be comfortable in making design and optimization decisions that cross the boundaries of different layers and system components. Now we won't be able to do it perfectly in an introductory course. So to be able to do this really well, you need to take the next course from me in the computer architecture. But we will sprinkle in some things that will enable you to think about this. Okay, let me, I guess we have time for one mystery, if you will. Because some things may look mysterious if you don't know what's going on underneath. And I'll give you some examples of this from my experience. And I think these are interesting and good examples. But let's see if we really have time to do that. Okay, who wants me to do that or who wants me to stop? Do it. Well, it's hard to, we need a clicker. Who wants me to stop? Stop, I have enough of you. You can tell me. No, this is not going to affect your grade, don't worry. I'm not going to look, maybe you're going to look and count. Do you want to do that? Look and count. So who wants me to stop? I'm not looking. Yeah? You count it. One, okay. I'm not going to ask who that is. Okay. So I'm assuming you're honest. You can tell me actually if you want me to stop and I won't be offended, don't worry. I can talk for hours and hours. That's not a problem with me. I can understand that it could be a problem with you. As a result, please tell me when it's too much. So I'm taking you that, I'm taking that you're honest in what you tell me right now. So I'm going to move on, continue. Okay, I'll continue. So I'll give you one example of mystery. We're going to do two more. I want to do justice to this because, so okay, we have time. That's good. Eight minutes, not bad. So this is a multi-core chip and we're going to cover a lot of it actually in this lecture. Basically it has these cores. It has some caches that we briefly talked about. This AMD Barcelona actually. It's a really old chip now. That's a picture from ages, like 2006 or so. Maybe some of you were not born then. That's shared caches, memory controllers, DRM interface, memory interface, and memory banks. You don't need to know about all of this terms at this point, but you can see that there are layers and layers of caches. In fact, there are caches inside these cores also. And memory controller, we will go and talk about later in the course. That's an important piece of the architecture that interfaces with the memory itself. And you've probably seen memory like this. How many of you have seen memory like this? Okay, excellent. That's good. That's not new, but you will see it at some point and you will see it in this course. Don't get scared. If you don't understand a lot of what I'm going to talk about again, don't get scared. We're going to build up to it at some point. But I've shown you the slide before. It didn't always used to be like this. In the past, there used to be just a single core on a chip, but people started putting more cores. And this is the infamous IBM cell processor that's hard to program. But basically people start putting simpler and low power cores that are simpler and low power than a single large core. As a result, you get parallel processing on chip. You can do multiple things at the same time, right? Sounds beautiful. You can actually put your entire data center on a chip, maybe. Well, maybe that's too much, but people are thinking of things like that. So it's faster and it can enable new applications if you do this. So what do you want? Ideally, it's always good to think about the ideal when you're an architect, I think. If you put these two cores on a chip, ideally you want two times of performance, right? You want both to speed up. At least together you want both to speed up by a similar amount such that you get overall two times of performance. Basically you want n times of system performance with n times of cores. So what do we get today? This is a result of an experiment that we did a long time ago while I was at Microsoft Research in Seattle. Basically, we wrote up it as a security paper. But basically this was on a system that was designed by Intel at the time, but we replicate on AMD also. If you have two cores, you run two applications, MATLAB for some simulation and GCC is a compiler. Don't worry if you've never used it. But we measured how much each of the applications slowed down when you're running them together on two cores. Basically, two applications are running on two processors at the same time compared to when each application is run alone on a single core. So the baseline for MATLAB is you run it alone, you get an execution time, let's say 100 seconds, and then you run it together with GCC, it runs for 107 seconds. So it slows down by only 7%. Sounds pretty good, right? And GCC, when you run it alone, it runs for, let's say again, 100 seconds. When you run it together next to MATLAB, it runs for 304 seconds. So it took three times longer. Sounds bad, right? First of all, neither of them improve in performance, but at least you should have both of them happen at the same time. So if they happen at the same time, if they both finish at 100 seconds, you get perfect speed up, right? 2x speed up. Both of them are slowing down, maybe you expect that. First of all, why are they slowing down? Why shouldn't they both finish at 100 seconds, right? Wouldn't that be nice? That's the ideal goal. But clearly they're both slowing down, but one is slowing down a whole lot more. So you actually in the end have a much worse system than what you've designed, right? You could run these two programs sequentially. First GCC, first MATLAB, and then GCC, and you get 200 seconds plus or minus change. Now, both programs take 304 seconds to run. That sounds bad, right? So you change the operating system, you change stuff, basically whatever you do in the software, this stays the same. So we call this the memory performance fog. I'll ask you a question, and maybe two questions. Can you figure out why there's a disparity in the slowdowns if you don't know how the system executes those programs? I hope your answer is no. I guess this was a rhetorical question. Basically, you need to know what's going on underneath to explain a situation like this. And if you want to fix it, you need to know even more, right? So why is this an important problem? Basically, people want to use these multi-core systems to execute multiple applications on the cloud. Let's say you have cloud computing today and you submit your jobs, and somebody can be running MATLAB, somebody can be running GCC. And it turns out, if they run it together, if the two people run it together, you'll get much slower performance. So why not execute on your computer? That's slow anyway. Why put it on the cloud, right? So it doesn't make sense to build a slower computer. So clearly something is happening underneath. There are two questions. Actually, there are three questions that I figured right now. Why is there a slowdown to begin with? Second, why is there a disparity in slowdowns? Why are they different slowdowns? And why are they so wildly different? And how can we solve the problem if we do not want that difference in the slowdowns? I don't know if you want me to answer these right now. I don't think we can do justice to it. Maybe I'll leave you with this. Maybe I'll do something. Oh yeah, okay. Why is this important? I have one more slide that I can build up so that you can think about this at home. And I'm not going to put up the slides for tomorrow's lecture, so maybe you can think about it. So why is this important? Again, we want to execute more applications in parallel and multi-core systems. We want to consolidate more and more. Cloud computing is an example, but mobile phones is another example. Increasingly, people want to do more and more over here. When you're speaking, you want something else to happen also. And also, one of the big reasons for having high-performance computers is you want to enable new applications. So we don't, maybe, I'm not an application designer, so I cannot imagine applications well, but if we can design computers much faster, there are a lot of smart people in the world that can take advantage of it. And also, we want to mix different types of applications together. Those require quality of service guarantees. For example, video or pedestrian detection. If you have a self-driving car, you'd better have a quality of service guarantee in your pedestrian detection, right? Or car detection or whatever detection you have around there, right? And those that are important, but less so. You want to mix all of these things together. And even within an application, if you have multiple different threads, they may have different requirements. And there are even less important applications like a virus checker, right? In fact, we did the same experiment with virus checkers. If you're running a very intensive virus checker, it can slow down something that's really important for the user. So we want the system to be controllable in the end. Okay, I'll give you with this picture and then you can think about why there's a disparity in the slowdown. So this is the system design we examined. This was the core. This was another core. Caches were different. There was some interconnects. There's a memory controller. There's a shared bus that goes to memory. And there are a bunch of banks that you can operate in parallel. You don't know this, don't worry. Basically, you don't know all of these probably. Don't worry about that. But basically you can think of this as cash keeping the data here. That's what you need to access to get the data out of them. So this part was shared. I'll give you the problem. That was the problem, basically. But I think we'll pick it up tomorrow to talk about exactly what was the problem. But we're not done yet. Daryon will take five minutes to talk about the labs. In the meantime, think about those three questions. Like why is there a slowdown? Why is there a disparity in slowdown? And how can you fix it? I'll ask you tomorrow. So basically,