 I want to talk about robust-first computing, it's what I've been working on, and show a demo of the demon horde sort, which is a particular approach to sorting that exemplifies this robust-first idea. Now we have computers that are extremely cheap and less weak, fairly powerful, and that culture of correctness and efficiency only, CEO software, is creating incredible security problems, the security nightmares that we're living with today that we kind of think they're sort of normal when in fact they're crazy. So if we think robust-first, we say let's make sure we're in the ballpark and then try to get it data. The architectural goal is to be able to take this computational model and scale it indefinitely large. As long as we have money to buy the nodes and power to power them and space, real estate to plug them all together. To do that, we need to focus on robustness. This computer potentially could be so big we cannot finish it before we start using it. We're going to be able to plug in more stuff while it's going. It's going to be so big that some fraction of it's going to be getting repaired or crapping out one way or another as we go. The computations that we build have to be inherently robust so that we can slap this stuff together. In each site, it can either be empty or we can have an atom, one atom. And here's an atom. It's called DREG, which stands for Dynamic Regulator. This diamond shape is called the event window. That is the limits of the number of sites that this guy in the middle can access when he executes. So there's 41 sites total. They are all within a distance of four, counting in city block distance. When this guy in the center is executing, he can read and write to the event window arbitrarily. But once he gives up control at the end of his event, then some other guy gets picked and he can read and write the event window, which might be overlapping, might be completely separate. The movable feast machine as a whole can be executing many events simultaneously as long as none of their event windows overlap. Now the way DREG specifically works is this. When it behaves, it looks north, south, east or west. One of those locations picked at random to see whether it's empty or occupied. And for example, suppose it looks north, it's empty. When it's empty, it picks some random number and with some low odds, it will create a resource atom, an atom called REZ, in that spot. And with a very low probability, instead of creating a REZ, it will create another DREG. So DREG can reproduce into empty spots, but it's very low odds. On the other hand, if it looks in a direction, in this case, if it looks west, it finds it's occupied, it picks a different random number with a different probability and maybe just erases the thing, whatever it is. At the end of the step, it diffuses and in general, diffusion respects whatever constraints there are on the local layout, okay? That's it. That's the DREG rule. We've got one DREG in it and we'll start it up. So there it was just diffusing around and eventually it will get lucky and decide to make something. Now, it can't destroy anything because it's the only thing that there is in the universe there. It made a REZ. Let's get rid of the grid because it gets visually a little crowded. We're artificially slowing this down so that we can get a little clue what's going on. Let's let it run at its natural speed and you see what starts to happen. If you can read these numbers over here, there's currently two, one, one. There's 50 REZ, 60 REZ, and so on. Overall, there's 18, 19% of this little grid is occupied by something. If we let it run, given the particular probabilities I picked for creating stuff versus destroying stuff, twice as likely to destroy as to create and that tends to make it float around a third of the sites in the grid occupied. So now we're at 32%. It'll end up going a little above a third, 35%, something when it reaches equilibrium. One of the essential things about parallel computing is you have to deal with deadlock, crowding, queues full, and so on. In this robust first approach, this particular demonstration, we're saying let's just deal with that by putting in this lower level that keeps the world about one third full. We can do more with this. Suppose I put in another element, he's a sorter, the demon horde sorter, but one of the behaviors that he's got is he looks around himself when it's his turn to go, and if he sees REZ, he converts them into more sorters. So if we let this run just for a brief bit, the REZ have been taken over. We can take a dragon REZ base and build things on top of it that will compete for the available resources, and they will automatically keep their total population under control because they can only get as big as the number of resources. Okay, this is a cartoon of the world of a sorter. He looks to his right and up to see if there's a number that's bigger than the number he's carrying because that's a number we're going to try to sort smaller numbers up, bigger numbers down. So if he sees a bigger number above him, he would like to move it down. If he sees a smaller number below him and to the right, he'd like to move it up and to the left because in all cases we're going to sort from right to left. So in this case, the 79 is bigger than the threshold and so he'd be interested in moving it down. The 24 is smaller than the threshold, he'd be interested in moving it up, but the destination for moving it up is all currently occupied. But we've got an empty spot, so what the sorter decides to do is take the 79 atom, copy him down to this empty spot, erase him from where he used to be, moving it sort of a little quantum, a little increment of sorting, and then as the sorter updates its threshold to be the value of the atom, it just moved. So at the end of this event, the 43 will have changed to a 79. You're not trying to do the entire sorting job yourself, you're just trying to make things a little better. And by making this spatial assumption, saying that we're going to sort from the right to the left, small is up, big is down, that allows the individual sorting element to make things better. So here we've got a much bigger grid than we have last time, it doesn't look bigger because the atoms are all drawn smaller. And so on the field there are these little eggs at regular intervals, each consists of two sorters and two dregs, and if we look on down there's more, and there's more here in the middle, another egg. In addition, there's this guy who's an output guy, and the idea is we're sorting right to left, so eventually the data guys will reach the left, and these out guys will suck them out of the system and do whatever the rest of the computation needs with them. In our case, it's just going to score them, it's going to say, well I know what numbers ought to be coming here, and we'll check to see how well the sorting is going. Similarly, over at the other end, on the right, we've got an input guy, he's going to generate data, just at random for purposes of this demo, to be sorted by the demon horde sort, and the guys in the middle are the demon hordes. So when I start this up in a sec, it'll be a little confusing because a bunch of stuff will be happening at once, but the first thing you'll see is the input grid will spread because in addition to creating inputs, the input elements are designed to look above, look below, and if the spots where there should be another input guy, or don't have an input guy, and they're empty, it goes ahead and puts a new input guy there, and the output grid makes a denser row of two, so we'll see the grids grow. As the input grids grow, they will start generating data, the blue atoms, and then the sorters will do their diffusion, and the drag will do their diffusion, and create res, and so on, so let's take a look at its behavior. All right, so pretty quickly, we've now got a full stack of green input grid guys. It takes a while for the machine to warm up. The sorting error is seven positions on average, that's pretty bad. If it should be the neighboring guy, that's the sorting error of one, off by two guys, and so on, so a sorting error of, well, now it's down to five, is, you know, better, still not very good. Let's let this run quicker and start to equilibrate a little bit. Now we're doing a little better. The sorting error is down to about three and a half positions on average, plus or minus, which is not too bad, and the categorical error is a tenth of a percent, sometimes never over the course of a 500 step period, not too bad. And this thing is embarrassingly robust. Unlike the correct first CEO approach, where you do something once, remember it, and then trust it from then on, here we are continually in the process of recreating ourselves, or we can blow like two thirds of the entire machine away. And again, now the score is definitely a categorical error is up to a third sorting error is terrible. The thing is getting all jammed up here. So it takes a little longer to recover. One last point here. This is a picture that's showing just the sorters, but instead of showing them as red, it shows them colored by what their threshold is. You know, it looks like there isn't a whole lot happening in the last third of this grid. The colors seem fairly uniform, but they're making increasingly fine distinctions. If we want, we can start stealing resources from this sorting thing. The machine adjusts. Eventually, its sorting performance starts to degrade. But now we've got all of this space over here. There are still events happening here. OK, so that's it. This is obviously a different way to compute than the way that we've gotten used to it. But in a way, it's a lot more like how society computes. All of the stuff that we do in the world tolerates these little errors. The idea is that each computing element, instead of assuming that everything else is absolutely perfect, should assume that everything else is trying, but might not be perfect. So computational elements that give a little better than they get. Like the sorter doesn't try to get the correct answer, it just tries to give a little better than it gets. Thanks for watching.