WEBVTT - TechStuff Tidbits: The Laws of Tech 0:00:04.400 --> 0:00:07.800 Welcome to tex Stuff, a production from I Heart Radio. 0:00:12.160 --> 0:00:14.720 Hey there, and welcome to tex Stuff. I'm your host, 0:00:14.840 --> 0:00:17.800 Jonathan Strickland. I'm an executive producer with I Heart Radio. 0:00:18.120 --> 0:00:21.480 And how the tech are you. Well, it's time for 0:00:21.520 --> 0:00:24.320 a tech stuff tidbit. And in the world of tech, 0:00:24.440 --> 0:00:29.840 we often refer to various laws that aren't actually laws 0:00:29.920 --> 0:00:33.160 at all, either in the legal or the scientific sense. 0:00:33.760 --> 0:00:36.920 So I thought I would dedicate a Tidbits episode to 0:00:37.159 --> 0:00:40.280 some of those laws, not all of them, and talk 0:00:40.360 --> 0:00:42.960 about where they came from and what they mean. So 0:00:43.120 --> 0:00:47.479 keep in mind, these laws are really more observations of 0:00:47.520 --> 0:00:51.880 things like trends in technology, and they have a tendency 0:00:52.200 --> 0:00:55.480 to be relevant, but there's no fundamental aspect of the 0:00:55.560 --> 0:00:59.600 universe that actually forces them to be true. Also, keep 0:00:59.640 --> 0:01:02.240 in mind, again we're just looking at some of the 0:01:02.280 --> 0:01:04.640 observations we referred to as laws in tech. There are 0:01:04.680 --> 0:01:06.240 a lot more of them out there than the ones 0:01:06.280 --> 0:01:08.920 I'm going to cover, and some of those end up 0:01:08.959 --> 0:01:12.360 getting super technical. Um And in fact, we're going to 0:01:12.480 --> 0:01:14.560 take a pretty high level on most of these. But 0:01:14.640 --> 0:01:16.720 the first one we should start off with is of 0:01:16.760 --> 0:01:22.600 course Moore's law. That's perhaps the most frequently referenced law 0:01:22.959 --> 0:01:27.760 quote unquote in tech now these days, we generally interpret 0:01:27.959 --> 0:01:31.920 More's law to mean that every eighteen months to two 0:01:32.000 --> 0:01:36.640 years the computers we produced double in processing power, meaning 0:01:36.680 --> 0:01:40.440 a computer produced today has twice the processing capability of 0:01:40.480 --> 0:01:44.000 a computer that was produced in twenty Assuming that you're 0:01:44.000 --> 0:01:47.440 actually listening to this episode in two that's when it 0:01:47.520 --> 0:01:52.240 originally aired. This is a fairly loose interpretation of the 0:01:52.280 --> 0:01:56.040 observation that Gordon Moore made in his paper Cramming more 0:01:56.160 --> 0:02:01.920 components onto integrated circuits way back in n More observed that, 0:02:02.400 --> 0:02:06.800 due to many different factors, not all of them directly technological, 0:02:07.280 --> 0:02:12.720 there was this trend for semiconductor companies fabricators to double 0:02:12.960 --> 0:02:16.080 the number of transistors on a silicon chip every year 0:02:16.440 --> 0:02:18.880 in the early days, and that held true for about 0:02:18.919 --> 0:02:22.400 a decade. But More would later revise his observation in 0:02:22.440 --> 0:02:25.880 the seventies to say every two years, and that's mostly 0:02:25.880 --> 0:02:28.919 where it's sat ever since then. So, in other words, 0:02:29.680 --> 0:02:32.840 an integrated circuit in nineteen sixty five would have twice 0:02:32.880 --> 0:02:35.160 the number of transistors as one that was produced in 0:02:35.200 --> 0:02:38.799 sixty four, and an integrated circuit in nineteen sixty six 0:02:39.120 --> 0:02:41.520 would have twice as many transistors as the one in 0:02:41.639 --> 0:02:44.200 nineteen sixty five, And you could project this out and 0:02:44.240 --> 0:02:47.440 make predictions and so on, and then eventually we hit 0:02:47.480 --> 0:02:49.240 a point where this slowed down a bit, and it 0:02:49.280 --> 0:02:52.079 took two years to double the number of components rather 0:02:52.120 --> 0:02:56.440 than just one. Now, Moore's observation took into account not 0:02:56.639 --> 0:03:00.000 just the advance in technological capabilities that would be required 0:03:00.160 --> 0:03:02.960 to make this happen, right, we'd actually have to build 0:03:03.000 --> 0:03:06.839 out the systems to make these components smaller and then 0:03:07.080 --> 0:03:10.320 cram them onto a silicon chip, As he would say, 0:03:10.680 --> 0:03:13.640 we also had to take into account the economic drivers 0:03:13.720 --> 0:03:17.080 that would push companies to pursue this trend. See, there 0:03:17.080 --> 0:03:19.560 has to be a reason for the push to cram 0:03:19.639 --> 0:03:22.000 more components on the circuit, because if there's no reason 0:03:22.040 --> 0:03:25.440 to do it, companies wouldn't pour the money into making 0:03:25.440 --> 0:03:28.880 it happen. After all, building out more complex circuits means 0:03:28.960 --> 0:03:32.680 investing a lot of money, time and expertise into finding 0:03:32.720 --> 0:03:35.839 new ways to produce smaller and smaller components and then 0:03:35.880 --> 0:03:40.160 designing a chip architecture that takes advantage of those smaller components. 0:03:40.200 --> 0:03:43.080 So there has to be that economic driver or else, 0:03:43.240 --> 0:03:46.840 the expense of doing this would be prohibitive. You wouldn't 0:03:46.880 --> 0:03:50.080 do it. Now. Lots of folks have predicted Moore's law 0:03:50.360 --> 0:03:56.119 would end as semiconductor fabrication facilities started hitting increasingly challenging obstacles. 0:03:56.760 --> 0:04:00.600 A one big obstacle is truly a physical one, like 0:04:00.600 --> 0:04:04.440 like physics. It's it's once you get your components down 0:04:04.440 --> 0:04:07.440 to the nanoscale, you know, like a nanometer is a 0:04:07.480 --> 0:04:10.320 billionth of a meter. Once you get down there, you 0:04:10.400 --> 0:04:13.840 start having to account for quantum effects. And these strange 0:04:13.840 --> 0:04:16.479 effects don't happen in the macro scale, so they seem 0:04:16.480 --> 0:04:18.800 almost magical to us. It seems like stuff that would 0:04:18.839 --> 0:04:22.760 be impossible because in our daily experience we don't encounter 0:04:22.839 --> 0:04:25.760 anything like this. So, for example, there is an effect 0:04:25.760 --> 0:04:29.680 called quantum tunneling. So imagine you've got a sub atomic 0:04:29.720 --> 0:04:33.839 particle like an electron, and let's say you've got a channel, 0:04:34.040 --> 0:04:36.960 and this electron can travel down the channel. It's a 0:04:36.960 --> 0:04:38.760 one way channel, so you can just go from one 0:04:39.040 --> 0:04:41.640 end to the other, and you've built it just for 0:04:41.680 --> 0:04:44.159 this purpose. And at the end of the channel you 0:04:44.240 --> 0:04:49.200 have a gate blocking the end of it. But it's 0:04:49.200 --> 0:04:52.320 a very very thin gate, and the electron just moves 0:04:52.320 --> 0:04:55.440 down your channel and then surprise gets close to the gate, 0:04:55.480 --> 0:04:57.360 and at some point it just appears on the other 0:04:57.400 --> 0:05:00.400 side of the gate, and the electron continue is on 0:05:00.440 --> 0:05:03.599 it's very little way. Uh now it's to you. It 0:05:03.640 --> 0:05:07.359 looks like the electron somehow dug a pathway through the 0:05:07.400 --> 0:05:11.240 gate and kept on going. But the electron didn't dig 0:05:11.279 --> 0:05:13.520 a path. It was just on one side of the 0:05:13.520 --> 0:05:16.280 gate at one point and then on the other side 0:05:16.320 --> 0:05:18.920 of the gate. And the reason for this is that 0:05:19.040 --> 0:05:23.279 electrons occupy more of an area than a specific point 0:05:23.360 --> 0:05:28.559 in space, or that they can uh inhabit any point 0:05:28.600 --> 0:05:31.400 within a certain area at any given given times. So 0:05:31.480 --> 0:05:35.520 there's the small region where the electron could possibly occupy 0:05:35.640 --> 0:05:38.599 any of the points within that region. Now, if the 0:05:38.640 --> 0:05:43.200 gate is so thin that this region of possibility overlaps 0:05:43.279 --> 0:05:45.919 the gate to the other side, well that means that 0:05:45.960 --> 0:05:48.799 there is a chance. It might be a very small chance, 0:05:48.800 --> 0:05:51.479 but there's still a chance that the electron could be 0:05:51.560 --> 0:05:53.800 on the other side of the gate without the gate 0:05:53.880 --> 0:05:57.200 ever having opened or the electron physically passing through it. 0:05:57.960 --> 0:06:01.400 And if there is a chance, that means that given 0:06:01.520 --> 0:06:05.320 enough opportunities, it will happen like that's kind of what 0:06:05.400 --> 0:06:08.960 chance means. So this is a bad thing if you 0:06:09.000 --> 0:06:11.320 want an integrated circuit, which you can think of as 0:06:11.360 --> 0:06:15.440 being a very very complicated system of pathways and gates 0:06:15.480 --> 0:06:19.160 for electrons to pass through or to be held back from. 0:06:19.200 --> 0:06:21.920 So for that reason and for lots of other ones 0:06:21.960 --> 0:06:25.280 that we don't really need to get into, semiconductor manufacturers 0:06:25.360 --> 0:06:28.560 don't really reduce all the size of components the way 0:06:28.600 --> 0:06:30.919 they used to back in the sixties and seventies and 0:06:31.200 --> 0:06:34.880 leading up to fairly recent years actually, but they have 0:06:35.120 --> 0:06:38.960 kept the naming convention. That is, you designate the type 0:06:39.080 --> 0:06:43.799 of the semiconductor node, the chip node with a metric 0:06:44.120 --> 0:06:48.120 such as like you might call it a four nanometer chip. Now, 0:06:48.160 --> 0:06:50.960 not that long ago, the metric would actually refer to 0:06:50.960 --> 0:06:54.680 the size of specific components on the chip itself. But 0:06:54.800 --> 0:06:57.359 these days it's really more of a way to say 0:06:57.400 --> 0:06:59.880 this chip performs at a higher level than say, a 0:07:00.279 --> 0:07:03.960 ten nanometer chip would, So it's really more to tell 0:07:04.000 --> 0:07:08.840 you about performance, but it's not necessarily uh in reference 0:07:08.839 --> 0:07:11.800 to the actual size of anything that's located on the 0:07:11.880 --> 0:07:14.720 chip itself. Now, there are a bunch of other laws 0:07:14.720 --> 0:07:18.400 in tech that reference or build off of Moore's laws. So, 0:07:18.480 --> 0:07:22.200 for example, there's Rocks Law, which is also sometimes called 0:07:22.240 --> 0:07:26.920 Moore's second law. This observes that as computational power increases, 0:07:27.440 --> 0:07:31.600 the cost to perpetuate Moore's law also increases, So in 0:07:31.640 --> 0:07:35.640 other words, it gets progressively more expensive to meet the 0:07:35.680 --> 0:07:40.080 fabrication requirements in order to build more powerful processors that 0:07:40.200 --> 0:07:43.120 keep pace with Moore's law. Moore's law is something of 0:07:43.200 --> 0:07:46.440 almost like a self fulfilling prophecy. There are companies that 0:07:46.560 --> 0:07:50.720 push themselves to keep pace with Moore's law, even though 0:07:50.720 --> 0:07:53.840 again there's no like fundamental law of the universe that 0:07:53.880 --> 0:07:56.760 requires them to do this. And this touches on something 0:07:56.800 --> 0:08:00.000 that I talked about in a recent episode about how 0:08:00.120 --> 0:08:03.400 Taiwan play such an important part in the semiconductor industry. 0:08:03.680 --> 0:08:08.200 Taiwan began investing in fabrication facilities in the nineteen seventies 0:08:08.640 --> 0:08:12.280 and built on that considerably in the nineteen eighties. Meanwhile, 0:08:12.560 --> 0:08:15.040 you had companies in the United States that we're really 0:08:15.400 --> 0:08:20.040 starting to shift and focus primarily on chip design, but 0:08:20.320 --> 0:08:25.680 not chip fabrication, because the fabrication cycle required a huge 0:08:25.840 --> 0:08:29.840 recurring investment. You would spend millions of dollars to build 0:08:29.880 --> 0:08:32.440 out all the tools and facilities you would need to 0:08:32.520 --> 0:08:36.600 make a chip with components of a certain size. Meanwhile, 0:08:36.640 --> 0:08:38.800 your designers are coming up with the next generation of 0:08:38.880 --> 0:08:41.160 chips and those are all going to need their own, 0:08:42.000 --> 0:08:46.160 you know, special equipment and facilities. So it's just a 0:08:46.200 --> 0:08:50.319 never ending cycle of having to reinvest in your process. 0:08:50.360 --> 0:08:52.800 So you have these chip designers who are creating a 0:08:52.880 --> 0:08:56.560 chip architecture, but then they would outsource the actual manufacturing 0:08:56.559 --> 0:09:00.600 to companies around the world, with Taiwan taking the lead. Also, 0:09:01.120 --> 0:09:03.679 this implies that a lot of chip companies out there 0:09:03.679 --> 0:09:06.480 are just consciously working to keep Moore's law going, even 0:09:06.520 --> 0:09:10.000 if it might not economically make much sense to keep 0:09:10.080 --> 0:09:13.440 up that pace. Um, there's almost like the weight of 0:09:13.520 --> 0:09:19.280 expectation upon it if you're a Luisa out there. Some 0:09:19.400 --> 0:09:22.720 observations playoff Moore's law in other ways or seem to 0:09:22.720 --> 0:09:27.120 evoke More's law. For example, there's Worth's law w I 0:09:27.280 --> 0:09:30.120 R T H that's named after Nicholas Worth, who wrote 0:09:30.160 --> 0:09:34.320 an article that's titled a Plea for Lean Software. Worth 0:09:34.520 --> 0:09:39.440 observation was that as computers get faster, software is getting slower, 0:09:39.559 --> 0:09:42.640 and effect software it gets slower at a rate that's 0:09:42.720 --> 0:09:48.120 greater than hardware's improvement. So hardware is getting faster, but 0:09:48.160 --> 0:09:52.280 software is getting slower faster than hardware is getting faster. 0:09:52.920 --> 0:09:56.000 If you will, so words law explains why you might 0:09:56.040 --> 0:09:58.520 go out and buy a brand new computer and it 0:09:58.559 --> 0:10:01.760 doesn't necessarily feel that much faster than the one you 0:10:01.800 --> 0:10:04.160 had a couple of years ago. Now, it's pretty natural 0:10:04.200 --> 0:10:07.439 for us to think, like, let's say we're using a computer, 0:10:07.480 --> 0:10:08.920 and we might think, oh, if I buy a new 0:10:08.920 --> 0:10:10.600 one in a couple of years, it's gonna leave this 0:10:10.640 --> 0:10:13.400 one in the dust. It's gonna be so much faster. 0:10:13.760 --> 0:10:16.880 But this ignores the fact that within those same two years, 0:10:17.600 --> 0:10:21.280 developers are going to make increasingly complex software that gobbles 0:10:21.360 --> 0:10:25.520 up those precious resources on the new machines. The software 0:10:25.559 --> 0:10:28.240 two years from now would likely require more than what 0:10:28.400 --> 0:10:31.720 your current machine could even handle. So Worth was saying 0:10:31.760 --> 0:10:35.480 to software developers, hey, guys, chill out and uh figure 0:10:35.480 --> 0:10:39.000 out ways to create less demanding software. Don't just pounce 0:10:39.160 --> 0:10:43.800 on computational capabilities just because they're they're this. Don't treat 0:10:43.840 --> 0:10:46.240 it like everest and you're climbing it because it's there. 0:10:46.559 --> 0:10:48.840 And this always makes me think of Triple A video games, 0:10:49.400 --> 0:10:54.440 which frequently on their highest settings anyway, have extremely high 0:10:54.520 --> 0:10:57.960 graphics processing demands, and they often push even the most 0:10:58.000 --> 0:11:01.400 powerful GPUs to their limits. And then you get the 0:11:01.440 --> 0:11:04.400 next entry in the franchise, and it will be even 0:11:04.600 --> 0:11:08.640 more demanding and will push whatever the current bleeding edge 0:11:08.679 --> 0:11:12.040 GPU is to its limits, and so on. It never 0:11:12.760 --> 0:11:16.040 eases off. On a sort of similar note, and one 0:11:16.080 --> 0:11:19.840 that involves not just tech but human nature is Brooks's law, 0:11:20.240 --> 0:11:23.720 and this comes from an observation by Fred Brooks back 0:11:23.760 --> 0:11:27.920 in nineteen He says that under some conditions, adding a 0:11:27.960 --> 0:11:33.200 person to a project, particularly software development, when the project 0:11:33.240 --> 0:11:37.720 is running behind schedule, will push the project to um 0:11:38.400 --> 0:11:41.680 to even further behind. So, in other words, if a 0:11:41.720 --> 0:11:45.080 project is not going to meet deadline, adding another person 0:11:45.600 --> 0:11:48.200 will likely make things worse. And there are lots of 0:11:48.200 --> 0:11:50.280 different reasons for that. I'm sure many of you are 0:11:50.320 --> 0:11:52.960 anticipating some of them. If you've ever gone through any 0:11:53.000 --> 0:11:56.440 sort of onboarding process, either with a company or a team, 0:11:56.679 --> 0:11:59.560 or if, bless your heart, you have been in charge 0:11:59.679 --> 0:12:02.680 of on boarding someone else, you know that it takes 0:12:02.720 --> 0:12:04.800 time for a new team member to get their bearings 0:12:04.800 --> 0:12:07.880 and get understanding of how things are working and find 0:12:07.880 --> 0:12:10.880 ways to contribute to that process. And until they get 0:12:10.920 --> 0:12:13.600 to that point, while the new person is more likely 0:12:13.640 --> 0:12:16.520 to be a drain on resources rather than adding to 0:12:16.640 --> 0:12:19.760 the resources. And it's not it's not their fault. They 0:12:19.760 --> 0:12:23.240 don't magically know where the project is and it's development cycle, 0:12:23.360 --> 0:12:26.400 or what is working or was not working, or how 0:12:26.440 --> 0:12:29.440 to make it better. It's just kind of the way 0:12:29.480 --> 0:12:33.199 things are. Other issues can also contribute to a slowdown. 0:12:33.280 --> 0:12:36.080 For example, as you add more people to a team, 0:12:36.200 --> 0:12:39.640 communication becomes more complicated. And boy, how do you do 0:12:39.679 --> 0:12:42.400 I feel this one? If you've ever used any sort 0:12:42.400 --> 0:12:46.800 of project management or communication platform to communicate with a team, 0:12:47.000 --> 0:12:49.640 you know, things like Slack or base camp or whatever, 0:12:50.480 --> 0:12:52.840 you know that things can get pretty chaotic. As more 0:12:52.960 --> 0:12:56.800 people join into a project. You can get cross talk, 0:12:57.240 --> 0:13:00.320 you can get conversations that maybe should happen within a 0:13:00.400 --> 0:13:03.559 subgroup rather than the whole group. You can have points 0:13:03.559 --> 0:13:07.280 where various subgroups haven't communicated with one another, and so 0:13:07.360 --> 0:13:09.560 things get all jump lee, just a lot of stuff 0:13:09.559 --> 0:13:13.199 that gets harder as more people join in. Uh and uh, 0:13:13.320 --> 0:13:15.559 you know that's something that we're going to touch on again. 0:13:15.679 --> 0:13:17.360 A little bit later in this episode, when we talk 0:13:17.400 --> 0:13:23.240 about processors adding people or resources to some jobs sometimes 0:13:23.280 --> 0:13:27.120 makes sense if those jobs can be divided up into 0:13:27.240 --> 0:13:31.160 individual tasks, but it makes less sense if the job 0:13:31.400 --> 0:13:34.480 isn't divisible, And we'll come back to that idea in 0:13:34.559 --> 0:13:38.480 just a moment. First, before we get into more loss stuff, 0:13:38.720 --> 0:13:49.640 let's take a quick break. We're back e Room's Law. 0:13:49.880 --> 0:13:52.240 Here's another one that's all play on Moore's law, because 0:13:52.280 --> 0:13:55.839 the room is actually more spelled backwards. It's e R 0:13:55.960 --> 0:13:58.959 O O M. It describes the process of developing new 0:13:59.080 --> 0:14:03.960 drugs like pharmaceuticals, and that developing new drugs gets progressively 0:14:04.080 --> 0:14:07.959 harder over time, and that means it takes longer and 0:14:08.080 --> 0:14:11.079 costs more money to develop new drugs as time goes on. 0:14:11.240 --> 0:14:15.040 Despite the fact that you've got scientists and engineers and 0:14:15.120 --> 0:14:18.080 chemists who have developed some really super cool high tech 0:14:18.120 --> 0:14:22.000 equipment specifically for the purposes of drug development, that even 0:14:22.000 --> 0:14:27.800 though our capabilities grow, the difficulty still grows. And generally, 0:14:28.480 --> 0:14:30.800 the Rooms Law says that the cost of developing a 0:14:30.840 --> 0:14:34.920 new drug doubles pretty much every nine years. Okay, now, 0:14:35.280 --> 0:14:38.120 way back in three, which was more than a decade 0:14:38.120 --> 0:14:42.160 before Gordon Moore's article about cramming components on integrated circuits 0:14:42.200 --> 0:14:45.880 would come out, there was a person named Herb Gross 0:14:46.360 --> 0:14:50.080 who observed that computer performance increases as the square of 0:14:50.120 --> 0:14:54.640 the cost. So, in other words, as a computer's price doubles, 0:14:54.840 --> 0:14:58.720 its computer processing power should be four times as great. 0:14:59.200 --> 0:15:01.600 So if you're looking at two computers and the first 0:15:01.600 --> 0:15:03.880 one is five dollars and the second one is one 0:15:03.920 --> 0:15:07.080 thousand dollars, the second computer should be four times as 0:15:07.120 --> 0:15:10.360 powerful as the first computer. Uh. This is one of 0:15:10.360 --> 0:15:13.880 those laws that at various times wasn't you know, totally accurate. 0:15:14.160 --> 0:15:17.520 But generally it's saying that as computers get more expensive, 0:15:17.920 --> 0:15:21.280 the price of computational performance, if you were able to 0:15:21.360 --> 0:15:24.240 like divide that up on a per unit basis, is 0:15:24.280 --> 0:15:28.760 actually coming down. Then there's Kumi's law, which describes the 0:15:28.840 --> 0:15:33.480 power efficiency of hardware over time. Essentially, Kumi said that 0:15:33.680 --> 0:15:36.800 every one point five seven years, the amount of battery 0:15:36.920 --> 0:15:40.640 you would need to handle a fixed computing load would 0:15:40.720 --> 0:15:43.360 fall by a factor of two, meaning that if you 0:15:43.400 --> 0:15:46.920 were to perform the exact same computational load on computers 0:15:46.920 --> 0:15:49.120 that were made essentially a year and a half apart 0:15:49.160 --> 0:15:51.920 from each other, the more recent computer would do it 0:15:51.960 --> 0:15:56.200 without consuming nearly as much power. After two thousand, Kumi 0:15:56.360 --> 0:15:58.720 adjusted this to say the trend would actually follow every 0:15:58.760 --> 0:16:01.600 two point six year instead of one point five seven. 0:16:02.320 --> 0:16:04.600 And you might wonder, well, why doesn't this mean that 0:16:04.640 --> 0:16:08.400 we see laptop computers that have batteries that have you know, 0:16:08.480 --> 0:16:13.080 an all day operation, Like why don't they last many, many, 0:16:13.120 --> 0:16:16.640 many more hours than old laptops? After all, if we're 0:16:16.680 --> 0:16:20.120 talking about it, the battery load decreasing by a factor 0:16:20.160 --> 0:16:24.240 of two every even every two point six years, shouldn't 0:16:24.280 --> 0:16:26.480 that be the case. Well, then we have to remember 0:16:26.480 --> 0:16:29.160 Worth's law and the fact that software bloats at are 0:16:29.160 --> 0:16:32.640 really fast rate, so we're not running the exact same 0:16:32.680 --> 0:16:36.600 computational loads as time goes on. The computational loads are 0:16:36.600 --> 0:16:39.680 getting bigger as time goes on, so it all kind 0:16:39.680 --> 0:16:44.360 of negates each other, all right. Then we have Gustafson's law, 0:16:44.840 --> 0:16:47.040 which gets back to that issue I was talking about 0:16:47.040 --> 0:16:49.040 with Brooks law. You know, that was the one that 0:16:49.080 --> 0:16:52.480 says adding more people to a project doesn't necessarily speed 0:16:52.480 --> 0:16:57.080 things up. Gustupson's law covers how much faster a computer 0:16:57.280 --> 0:17:02.080 with parallel processors will complete given task compared to a 0:17:02.120 --> 0:17:06.880 computer with a single core processor. All right, now, when 0:17:06.880 --> 0:17:10.280 it comes to parallel processing, I use this analogy pretty 0:17:10.359 --> 0:17:14.960 much every single time to describe single core versus multi 0:17:14.960 --> 0:17:18.200 core processors. But let's do it again. Okay, Let's say 0:17:18.240 --> 0:17:20.840 you got yourself a math class and there are six 0:17:20.960 --> 0:17:23.960 students in the math class. One student, and we're gonna 0:17:23.960 --> 0:17:27.320 call her Annie, is like super good at math. She 0:17:27.560 --> 0:17:30.560 is a genius. Now, the other five students in the 0:17:30.600 --> 0:17:33.120 class are really good at math, but they're not at 0:17:33.160 --> 0:17:36.879 Annie's level. One day, the teacher comes in and proposes 0:17:36.920 --> 0:17:40.080 a contest. She's going to hand out a pop quiz 0:17:40.400 --> 0:17:43.359 with five math problems on it. Annie will have to 0:17:43.400 --> 0:17:47.880 complete all five problems, but the other five students will 0:17:47.960 --> 0:17:51.080 each only have to solve one of the five problems. 0:17:51.080 --> 0:17:54.000 So student one gets problem one, Student two gets problem 0:17:54.080 --> 0:17:57.720 to et cetera, And then the teacher starts the clock 0:17:58.040 --> 0:18:01.120 and lo and behold the group of five students finish. 0:18:01.400 --> 0:18:06.400 There's collectively first, Annie is faster at answering individual questions 0:18:06.560 --> 0:18:10.000 than her counterparts are, so she can answer question one 0:18:10.320 --> 0:18:13.920 before student one can do the same. But keep in mind, 0:18:14.040 --> 0:18:17.400 students two through five are still working on those other 0:18:17.520 --> 0:18:21.960 problems while Annie is still finishing up question one, so 0:18:22.640 --> 0:18:24.760 she is not able to finish her quiz faster than 0:18:24.800 --> 0:18:29.040 the collective classmates for that particular pop quiz. This is 0:18:29.160 --> 0:18:33.560 kind of like parallel processing. Parallel processors are great for 0:18:33.680 --> 0:18:38.360 certain types of computational problems, namely problems that can be 0:18:38.440 --> 0:18:42.280 solved in parts. The various cores can tackle the different 0:18:42.400 --> 0:18:45.800 parts of the problem and then together they all arrive 0:18:45.880 --> 0:18:49.200 at the solution, and potentially they can do this much 0:18:49.240 --> 0:18:53.680 faster than a more powerful single core processor could. However, 0:18:54.480 --> 0:18:58.760 not all problems are parallel. Some problems require a serial 0:18:58.920 --> 0:19:02.800 approach s e. R I. A L not captain crunch, 0:19:03.520 --> 0:19:06.080 and a serial approach means that you can't just divide 0:19:06.119 --> 0:19:08.359 the problem up into parts. You have to go from 0:19:08.400 --> 0:19:11.040 beginning through all the way to the end. And in 0:19:11.080 --> 0:19:14.720 those cases, the more powerful single core processor is going 0:19:14.760 --> 0:19:18.640 to solve the problem faster than the parallel processor where 0:19:18.640 --> 0:19:21.320 each core is not running at the same you know, 0:19:21.400 --> 0:19:25.719 high level clock speed. So Gustopherson's law takes all this 0:19:25.760 --> 0:19:29.919 into account and gives a mathematical expression to estimate how 0:19:30.000 --> 0:19:33.639 much faster a parallel processor can solve a given type 0:19:33.640 --> 0:19:35.879 of problem if you happen to know how much of 0:19:35.920 --> 0:19:40.920 that problem is serial rather than parallel. Alternatively, you could 0:19:41.040 --> 0:19:44.679 use this to estimate how slowly a single core processor 0:19:45.000 --> 0:19:49.199 would solve a parallel problem. All right, Well, what if 0:19:49.200 --> 0:19:50.840 you were to look at Moore's law and say, hey, 0:19:50.880 --> 0:19:53.600 that's nice and all, but it's way too slow. Well, 0:19:53.640 --> 0:19:56.959 then you could take a gander at Nevin's law. This 0:19:57.040 --> 0:20:00.159 is named after Hartmut Nevin, who works in discipline is 0:20:00.200 --> 0:20:03.919 like quantum computing in robotics, and his law proposes that 0:20:04.040 --> 0:20:08.680 quantum computers increase in power at a doubly exponential rate, 0:20:09.040 --> 0:20:12.560 which is quick and crazy fast. And we can sort 0:20:12.560 --> 0:20:16.480 of see why this is too so. For classical computers, 0:20:16.920 --> 0:20:20.080 the basic unit of information is the bit, and a 0:20:20.119 --> 0:20:23.240 bit is a binary digit, so we designated as either 0:20:23.359 --> 0:20:26.040 a zero or a one, which you can think of 0:20:26.080 --> 0:20:30.399 like a switch being turned off or on. Using lots 0:20:30.400 --> 0:20:33.280 of bits, we can tell machines to do all sorts 0:20:33.280 --> 0:20:36.480 of stuff based on specific input. This is the basis 0:20:36.640 --> 0:20:42.480 of computer science. But quantum computing has a different basic unit. 0:20:42.560 --> 0:20:47.119 It is called the cubit or quantum bit, and a 0:20:47.240 --> 0:20:49.760 bit can either be a zero or a one, right, 0:20:49.800 --> 0:20:52.080 it has to be one or the other. It is binary, 0:20:52.080 --> 0:20:56.880 But a cubit, thanks to stuff like superposition, can effectively 0:20:56.960 --> 0:21:01.400 inhabit both the zero state and the one states simultaneously, 0:21:01.440 --> 0:21:05.200 as well as technically all states in between. So as 0:21:05.280 --> 0:21:08.679 you add in the ability to handle more cubits, as 0:21:08.680 --> 0:21:13.359 you build quantum systems that have more cubits incorporated into them, 0:21:13.440 --> 0:21:16.480 you vastly expand what the computer is capable of doing. 0:21:16.840 --> 0:21:20.879 Your collection of cubits can, in a sense, perform drastically 0:21:20.960 --> 0:21:25.200 larger numbers of simultaneous processes to solve a specific subset 0:21:25.280 --> 0:21:28.479 of computational problems. That sounds like word sellad, but it 0:21:28.520 --> 0:21:30.560 does make sense if you start to break it down, 0:21:31.119 --> 0:21:33.400 And it doesn't mean that a quantum computer is good 0:21:33.400 --> 0:21:37.080 for every kind of computational problem, just like a parallel 0:21:37.200 --> 0:21:39.800 processor is not going to be good for are not 0:21:39.840 --> 0:21:43.480 going to be better at at a serial level kind 0:21:43.520 --> 0:21:46.760 of computational problem than a single core processor could be. 0:21:47.760 --> 0:21:49.639 A quantum computer is not going to be great at 0:21:49.680 --> 0:21:54.080 every single type of computational load, but for a subset 0:21:54.119 --> 0:21:57.040 of them, they could be phenomenal as long as computer 0:21:57.119 --> 0:22:02.200 scientists develop effective algorithms to lever the quantum computing UH, 0:22:02.240 --> 0:22:04.439 and these are problems that would take a traditional computer 0:22:04.560 --> 0:22:07.760 decades or maybe centuries or thousands of years to complete, 0:22:07.760 --> 0:22:12.000 depending upon the complexity. So one example of of the 0:22:12.080 --> 0:22:15.240 type of problem that quantum computers might be really good 0:22:15.280 --> 0:22:19.440 at tackling is UH is known as the traveling salesman problem. 0:22:19.480 --> 0:22:21.920 And here's a version of this problem. Let's say you've 0:22:21.920 --> 0:22:26.600 got a salesman whose region includes you know, ten different cities, 0:22:27.400 --> 0:22:29.600 and the salesman's trying to figure out what is the 0:22:29.640 --> 0:22:33.240 most efficient route that will allow the salesman to visit 0:22:33.440 --> 0:22:36.719 every city at least once with the least amount of 0:22:36.760 --> 0:22:40.600 travel time. And in a classical computer system, a computer 0:22:40.640 --> 0:22:44.919 would have to go through every single possible variation of 0:22:45.040 --> 0:22:48.800 every route between every city and record the results. And 0:22:48.840 --> 0:22:52.120 then once it had run every single variation, it could 0:22:52.119 --> 0:22:55.480 then compare all the results against each other UH and 0:22:55.520 --> 0:22:58.760 then determine which route would be the fastest, and that, 0:22:59.000 --> 0:23:01.520 depending again on the complexity of the problem, could take 0:23:01.600 --> 0:23:05.480 hundreds of years. A quantum computer with a sufficient number 0:23:05.480 --> 0:23:09.560 of cubits along with the appropriate algorithm, could potentially solve 0:23:09.640 --> 0:23:13.960 this problem much faster. Also, interestingly, the solutions that quantum computers. 0:23:14.000 --> 0:23:17.880 Generator actually listed in probabilities, not certainties, so you would 0:23:17.920 --> 0:23:22.000 get an answer that what might have like a threshold 0:23:22.680 --> 0:23:25.520 of certainty saying that this is the right answer, which 0:23:25.520 --> 0:23:28.960 means it might not be, but it probably is. Now 0:23:29.000 --> 0:23:32.640 I'm being very fast and loose and very very high 0:23:32.720 --> 0:23:36.440 level with this description. It gets so much more complicated 0:23:36.480 --> 0:23:38.760 and technical than what I'm I'm saying. But this is 0:23:38.800 --> 0:23:41.600 just to give you an idea of what quantum computers 0:23:41.640 --> 0:23:43.800 will be used for. They won't be used for everything, 0:23:44.480 --> 0:23:47.600 but for the applications that they can be used for, 0:23:48.040 --> 0:23:51.919 they can potentially be far more powerful than any classical system. 0:23:51.960 --> 0:23:55.680 All Right, We've got a few more laws to cover 0:23:55.880 --> 0:24:07.440