 Thank you. Lance and I have been semi-collaborating on these kind of ideas for probably five years or more. So you will see definite family resemblances between the approach he's taking and what I want to talk about today. I have a candidate answer for Charles' question about how we're going to speed this thing up. And the way we're going to speed this thing up soon sometime is by building actual incredibly parallel hardware to run it on. And so in service of that over the last year, Elena and I, Elena is here, have been working on a programming language to support, at the moment, simulated models of this sort. But with the goal of having it be directly portable at the level of recompiling to run an actual scalable parallel hardware. So that's the goal. The talk tries to be sort of big and architectural, but really, in my mind, it's an introduction to ULAM, which is the name of the programming language. We are releasing today. It is on a personal package archive on Ubuntu. So you can use either of the major systems to run it to the 1204 or 1404. And it's there to play with now. So I want to make sure I save enough time to actually do some demos, just the sort of equivalence to Hello World or to see how this thing works. It's a very different kind of programming. People think they get it until they try it. And then it's like, oh. And the question is, how many of these bitter pills can you take before you say, oh, wow, this is too hard to program? I, in fact, want to go back to CPU and RAM and GPUs, even though they only scale as far as they scale and then they poop out. But who cares? In the long run, we're all dead. Oh, I like that. So this is the idea. If we're not going to do that, what are we going to do? So the takeaway message is if you believe computation is going to continue to grow, if you could believe we're going to do larger computations in the future than we do today, then determinism is doomed. Determinism meaning the program will get the same answer if you run it twice. One of the dirty little secrets in the supercomputing community is they're having troubles with that, which you could care less about if it was the weather. You might care a little more about if it's the nuclear stockpile that's being simulated. The guys in the supercomputing community know this five years ago when they were talking about the transition to exascale supercomputers. There was a major research question saying, are we going to be able to make it deterministic? Are we even going to pretend it will get the same answer twice if we run it twice? And they thought, oh my god, no, we're going to have to think of, I don't know what. But now they believe with tricks and hacks and disgusting stuff, they pushed non-determinism over the horizon one more generation. And the exascale machines are going to be deterministic, at least as deterministic as they're pretending the pediscale machines are today. But I'm looking all the way down the road. Down the road, the idea of determinism is a fantasy. It's a property of small systems. And that's fine, as long as our computations are small computations. In the future, we will have to pick a post-Vinoyan architecture. That means something other than CPU and RAM, all right? People don't like this. The machines we have today, parallel architectures, they generally forego the serial because they're parallel, but they still try to preserve determinism. Everything has to reach the barrier. Nobody can proceed if anybody is late for the factory. The entire factory shuts down until everybody else comes in, so that allegedly you'll get the same answer twice. The fundamental problem with the approach that we've taken, the CPU and the RAM, is that central planning, the idea of a CPU just doesn't scale. All the data has to come from the South 40, go into the CPU, get incremented by one and sent back out. That's fine, but there's this tiny little thing called light speed that you can only bring data in from so far before your clock has expired. Now you do all these tricks to pipeline it, and then you get latency. You make all the tricks that you want, but you cannot escape the physics. In the end, you have to have many CPUs. And that violates the fundamental principle of RAM. The whole principle of RAM was that it was completely stable, and it never changed. It sat there until the CPU said to do something. But if we're giving up on the idea of a CPU because it doesn't scale, that means that memory has to be doing something other than nothing. And the question is, what? What is it going to be doing? Oh, and then, sorry, not right. I worked in artificial life intensively in the 90s, and I sort of moved away from it a little bit in the early OOs, and primarily during that time I was doing computer security. I was doing biological approaches to computer security, trying to figure out how to mop up the sorry mess we had made for ourselves. I now know it is not possible to mop up the sorry mess that we had made for ourselves. And in fact, this research effort is saying we really ultimately have no choice but to reboot if we're ever gonna have something that could be called credible security. We think our programs are deterministic, but that's until the first bug. We think our programs are deterministic, but that's until the first buffer overflow. We think our programs are deterministic, but that's until the first two-bit error or one-bit error on most machines these days. Determinism was always a fantasy, bought by the fact that our programs were short. Our programs were over, so that we had a good probability that they would be okay before the error occurred. All right, so the talk, I've already said it, I will not blow the whole thing. Traditional computing, I'm calling computing in the serial deterministic attractor. The idea that you're gonna be able to make a line of steps, each step will be completed perfectly, therefore you can use logical inferences to figure out what the concluding step will be. And it's a happy world. And just to say that, brings with it a host of other design decisions, so deep into our computational framework that we don't even recognize them. Ideas as deep as CPU and RAM, ideas as deep as binary representation of numbers. We think there's no other alternative. There's tons of other alternatives, but we don't think about them. So in fact, this is a set of interlocking design decisions that all support each other, and make us almost blind to the possibility that there could be something else. What I suggest I'm calling in the alternative is the robust first attractor. The robust first attractor does not promise to get the right answer. It'll compute for you, it will tell you something, and it'll probably be close. Will it be close enough? Maybe, how close do you need it to be? Really. The robust first attractor has the possibility of robustness at a level that the serial terms strategy cannot achieve, and it has the possibility that we can make an arbitrarily large machine with it. Because we broke the fundamental assumption that there was gonna be a single central point of control. The system's gonna be doing stuff whether we want it to or not. The rest of the system's gonna have to deal with the fact that the world may have changed between the time we look at it twice. The problem is, the robust first attractor body of knowledge, it's an engineering term that they like to talk about. When they don't actually have a theory, they say body of knowledge. We don't have a theory. We don't even really have a body of knowledge, and that's the problem. We need a body of knowledge. I do not believe there's going to be the one amazing theorem that is going to make robust computation obvious. I do not believe it's a scientific or mathematical failing that we need. What we need is a ton of engineering. What we need is to actually try these things and say, oh, that was a really bad idea. Don't do that. We have plenty of bad ideas in the development of serial deterministic computing that we don't do anymore. We pretend that code and data share the same space. Self-modifying code, well that's not true. It hasn't been true for generations of hardware. Turns out it's a bad idea. There's lots of things like that. You don't see that up front. It was extremely pure. The idea was extremely pure. So powerful. Universality. Bad idea. We need to start springing the design bear traps of robust computation. So I am offering Oolong as a tool to help us get in there and start trying things and spring the bear traps. Say, oh, that's a bad idea. Oh, that's a less bad idea. Publish. We got low hanging fruit everywhere. Okay, that's the idea. A-lifers are uniquely well suited from my point of view because they're half crazy already. So they require many fewer mutations to get it to think, holy moly, I don't have to compute the answer. I just have to make the world a little better. I don't have to even know what I'm doing. I just have to know how to make things a little better. And then if there's enough of me, it can't be wrong. That's how you compute in the robust first attractor. The way you solve programming problems is not by figuring out, you take whatever the overall problem is and you say, how could I come up with a guy so that using just little local information, he could make the world a better place. Sorting, compare two numbers, move the bigger one up, the littler one down. Does that mean the overall problem is solved? No, is the world a little better place? In some random stochastic, well-founded, ill-founded sense? Yes, the world is a better place. Things are closer to where they want to be in the answer. All right. So I want to talk about active media stuff just because that's the alternative to the RAM and then start showing down this. So I've said most of this, CPU and RAM doesn't scale. If memory isn't passive, what is it doing? That's my little Zen call in for today. And the idea is it's doing something. And our job as robust first computer programmers is to try to make systems that spontaneously do stuff that might be useful. Sitting there and doing nothing, which means computing the identity function, 99.99 every time until the bus cycle where the right comes out, that is useful, but it's not scalable. So if it's going to actually do something that involved change, what might it be? And our job as programmers is to say, I don't even know what you want to do. I'm not sure what the program is, but it's a generally good idea to be able to make membranes, to be able to divide space in half. It's a generally good idea to be able to make redundant copies of something that's important. It's a generally good idea to be able to do a sort of Maxwell's demon thing of pushing one stuff one way and one stuff the other way. We can imagine building small agents, entities, something or other, artificial chemistry elements that do that kind of stuff and then look to recruit them into larger spatial assemblages to produce more useful behaviors, okay? That's the idea of bottom-up programming. We're not gonna say, you tell me the problem and then I'll figure out how to solve it. Instead, we're gonna say, I didn't know something about problems in general. We're gonna need boxes, we're gonna need containers, we're gonna need this. In fact, why don't you become a super specialist in being a container and I'll hire you if I need you. This is the Hollywood agency model of production where you got a guy that all he does is carry the steadicam, but he's incredibly good at it. Whereas if you say, I need a steadicam guy and Bob says, well, I'm strong enough to carry it. Yeah, he'll do it and it'll totally suck. That's the computation we have today. The idea of all behind all of this is best effort computing. It's not about being correct. It's about being able to show you tried. And if you can show you tried well enough, you will be correct. But fundamentally, you're no longer promising to be correct because that was an evil illusion all along. In order to make this go, we need to be able to deal with machines that can be as big as possible or taking way too much time. So I'm gonna skip the guts of indefinite scalability. This actually, I stole the tile from the previous talk. Anyway, the idea is if you design architecture so that you can plug tiles together as big as you want and if you need more computing power, you just plug in more tiles. You don't stop the previous ones. You don't reboot. You don't power cycle. You just hot plug more and more and more stuff in and the program just keeps running and it has to adapt to that. If you take that idea seriously and indefinitely scalable machine, you cannot have a global boot time because it's being constructed while it's being used. If you take that idea seriously, strictly, it will lead you to robustness to the multiple CPUs to the neutral dynamics idea of what is the thing doing anyway. All right, soft A-life people think to themselves, ooh, I do artificial chemistry. It sounds inherently like this. Everything's distributed. It goes all over the place. I'm doing cellular automata. Oh, it's just like this. I'm doing game of life. It's great. And I wanna agree but I can't because there are these fundamental assumptions that we think of as free, like a global clock, like deterministic updating that are far, far, far from free. They have huge design impacts, huge design consequences and means that the dynamics that we observe using synchronous updating, using deterministic computing is warping our intuitions about how much hardware is necessary to do any particular function in a robust way rather than in this completely phony, everything is perfect, rather sort of way that we do it. Okay, so that's the part where we have to push the A-lifers a few more steps to complete lunacy. And then, and Ulam is just to take it. Now, I mean, I see some people who think they're buying it and some people who think that they're not, is anyone wanna jump in? I can, I have my own objections that I will raise if nobody else wants to. Sure, go for it. What is the threshold for the scale, up in scale, making the Von Neumann model no longer autonomous? My slogan is there's nothing wrong with a Von Neumann machine that cannot be fixed by making it small and insignificant part of a bigger system. So if we have buttloads of Von Neumann machines and we can shoot out a bunch of them and the machine will keep on going, that's fine. The mistake was thinking we could take that single idea and make the CPU bigger and bigger and bigger and so forth like that. All right. I'm wondering if the classic problems that you're thinking of computation being able to address is changing. Like for example, nowadays, if I want some number of digits of pi, I can ask my computer to do that. Yes, indeed. But you might be telling me, and I'm wondering if you are, that if I really want billions or trillions or some incredibly large number of digits of pi, well, that's just not a question that the computation will be able to give you. It's gonna turn out you didn't really want it. And the idea is you have to upstream that question. You have to say, what were you gonna do with the answer? And you say, well, nothing, I was gonna make me happy. Well, then okay, you pay to have a deterministic machine try to do that. But in fact, computations become coupled into physical systems when they have sensors and effectors and they only need, well, in fact, today is pi approximation day. 22 over seven is close enough for almost everything that we're likely to do. So yeah, I am talking about different set of computations. Much more coupled sensory motor control systems. Simon, last one. I got a little bit of a concern, but that's fine. The best effort I did is to study how that knows how to do it and the guidance is not just a bit. Right. Do many of you reward me? And if so, do they get me reward you proportionately to have a way to do it? The system has to be designed to stabilize the pieces at all levels. And that is part of our design challenge. Just as because this is gonna be a spatial computer because we have to recognize that this guy is closer to that guy, we're gonna have to get the incentive structures and that's gonna be part of our task, absolutely. Okay, great, thank you. The sort of things, all right, so here's my objection. Does anyone know what this stands for? Not at all. This is a solution in search of a problem. So by saying bottom up computing, aren't I saying I am offering you solutions in search of a problem? The answer is you bet. And the reason is when we take the approach of problems in search of solutions, we get the crappiest, cheapest, stupidest solution that does what the problem needed. And that's great. If you don't care about security, you don't care about robustness, don't care about scaling. We need both. We need solutions in search of problems. We need problems in search of solutions. So yes, I'm alone now. Without determinism, I can't. There's lots of complaints that come up. We've heard some. I can't compute the billionth digit of pie. You didn't want to. It'll be too inefficient. Partly yes, partly we'll fix that once we try. Remember where we started in serial deterministic threat. But isn't there a trade-off with robustness? There absolutely is. And computer scientists refuse to acknowledge that. That efficiency and robustness are diametrically opposed on the value of redundancy, which robustness requires and efficiency eliminates. So the question is, is how much redundancy do we need? And what we want to do is to be able to use however much is available and then only start becoming efficient when we absolutely have to. Crawling across the desert, are we gonna make it or not? Okay, I'll be efficient. All the rest of the time I'll do everything 30 times because why not? Times are flush. All right. So, let's jump on to demos. Demos are cooler. Here is an ULAM program. A complete ULAM program. It defines an element in this called F0 because it's the first one. Inside the element we have an event window. The event window defines the memory model. It defines the neighborhood that you can see around it. And in fact, EW sub zero is U. U are the center of the universe. There is no global addressing. Of course there couldn't possibly be any addressing. When I say you, I mean me, but you know. So what this says is copy me to EW sub one. Now what is EW sub one? In this case it turns out it's west. We have a 2D indexing system because it's a 2D model but we also have an underlying 1D addressing scheme which just kind of works its way out. So zero through four ends up being von Neumann neighborhood and zero through eight ends up being the Moore neighborhood and then it goes out farther than that. The event window lets us go to a Manhattan distance of four. Each site can hold an atom that has a type and then 71 bits that you can do anything you want with. Okay, so here is that program. There it is the same thing. Let's compile it. It does a whole lot of stuff. In fact, it builds a A.MFZ. This is a Moogle Feast compressed file that has everything needed to play with it. And if we want to play with it, we run MFZ run and we give it the package name and here we are. We're now looking at the simulator. The simulator looks kind of icky because the screen is really tiny but nonetheless it still works. Here's our table of elements. We can pick the pencil tool and put down one of our guys. Let's clear it out here. There it is and we can start up the simulator and it goes west. Incredible. Let's do one more and then I'll take questions. All right, so here's F0, here's F1. It's the behavior function that says how you do a transition from one state to a next. Identical, but the comment ahead of it has changed slightly. I've got this done ahead of time. Here's our F1 atom. The difference between F0 and F1 is symmetries all. And that means when you do an event instead of assuming that this thing is west before every event pick a random rotation and a random flip and do that, okay? Now that's it. Otherwise it's the exact same function. What happens to the dynamics? A slight change. Massive case of cancer. This thing is a fork bomb destroying the universe as fast as it possibly can just because it can reproduce in any direction. The only reason the previous guys didn't was that they kept running into each other, okay? Now the last one I'll show before I eat up all of my time is, well first off, maybe we better stop the universe and clear the thing out, okay? We have an availability of four squares in any direction to see when we're deciding what we wanna do. And that's great. It's more than a typical cellular automata for sure. But if you're thinking that's it, that's your memory. There isn't any memory anywhere else. There's just that memory and a function call and stack that gets reset after every event. No persistent state except what's in the world. You're 71 bits and that's it. And I'm out of time. So I will let this go. This is an atom called a mob. You give it one, it spontaneously duplicates itself through three rounds of generations until there's 128 of them and then it runs this simple thing called the mob rule where it picks, it looks around itself, tries to find a random one of its own type and a random empty spot. And then it checks to see whether that empty spot is closer to the other one than it is. If the empty spot is closer to the other mob guy than it is, it switches, otherwise it doesn't, okay? And so that's the example of just make the world a better place. Don't solve the problem of cohesion flat out. Just have a local little bit. If I see an empty and he's, that empty is closer to that other mob guy than I am to the mob guy, then switch. Otherwise do nothing, okay? And that's the mob rule. And what I'm looking for, this is a movie that runs a little faster. This is a mob that has a slight bias toward the Northwest, okay? So mostly it does the mob, oh actually, so this is one of the more advanced guys that actually has random changes of direction. So they actually have to come to consensus on deciding where they wanna go pillage now. Like that. I'm out of time. Ulam is available on Ubuntu. I would love people to try it. Join our mailing list, which will exist real soon. Thank you so much. I'm sorry I went over. Okay. Thank you.