 The T2tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. How to build the biggest computer ever. I have sunk to the level of clickbaity titles, but is it legitimate? If this is the first time that you've seen a T Tuesday update, thanks for taking a look. If you're a regular, you know my answer to how to build the biggest computer ever is one tile at a time that you take, you make a piece of computing that has memory, processor, display, input, output, everything, you make it completely self-contained so that all it needs is power for operation, cooling to get rid of excess heat and space, some place to put it, and you design it so that it can connect together with others of its own kind as far as you like. And these things, you know, these gigantic pitiful expensive things that look like, you know, Feringue tricorders or something like that. You know, you have supposed to imagine in the future that these are like grains of sand or little bits of chips or whatever. Who knows? But these are just our prototypes of back in the very beginning. So the idea is you design a machine that you can make individual pieces and tile it out. You could power it up. You can be using it while you're building it out bigger. And you can make it at the biggest computer ever. Why? Because even other computers like supercomputers, the way that we design computers today, without indefinite scalability, you essentially start with the size of the machine and then you engineer backwards. So if we want to make a petaflop supercomputer or an exaflop supercomputer, well that defines a whole bunch of parameters and then you work backwards to how much hardware and what type you need and so on and so forth. Indefinite scalability turns it around. Commit to a tile first and then say we're going to have more and more and more and more of these. And when you do that, you're going to find out that eventually, if you have so many of these that no matter how reliable they are individually, there's going to be failures that are happening somewhere in the grid and the computation is going to have to be smart enough. It's going to have to be robust enough to ride that out. It's going to have to make its best effort to deal with whatever happens rather than thinking everything's going to be completely perfect because the hardware is guaranteed 100% reliable. And when we start building software which we're in the process of doing very early stages that is going to work on best effort hardware, the software is much more like living systems. They're going to reproduce to safety and to use resources. They might heal themselves. Who knows? And that gets to the connection between life and computational systems that underlies all of what I've been doing for most of my research career. Well, really all of it one way or another. This, the T2 tile project is the latest step in that because the way we've been building computers today really is not appropriate to using them for systems that need to be resilient, robust in control of things that are potentially dangerous. So that's how we're going to build the biggest computer ever. And we have made progress. It's been two weeks, two weeks ago. Well, so yeah, so it's all been about the T2 native engine which means this is the T2 tile. So the native engine is a rewrite of a new software base to control this stuff to do the movable feast machine. It's a particular kind of way of computing that is a two dimensional grid where everything's kind of flat and laid out and you talk to your nearest neighbors, you decide what to do. It's kind of like Conway's Game of Life. That's what most people are familiar with but it's different in several key aspects. But we had tried to take a simulator and just sort of put the simulator on the tiles. Hadn't worked so the native engine was let's start fresh and just build up the software for what the T2 tile wants us to do and that's where we've been at. And two weeks ago it was all building the code out. This hadn't been written. That hadn't been written. It hadn't been written. Whoops. One after another, just keep finding out where it was. In the last two weeks, actually made some progress beyond that to get to the point of saying, how is this actually really supposed to work when we're having an event, a little part of our cellular automata in the corner wants to talk to another tile and say, I did something that you could see. I need to tell you about that. We had to get that coordinates right and that's what this thing is. This is an ASCII art picture of the corner of a tile counting out all of the grid locations of all of the different types. And if you're in location A, then you have to worry about being in the west cache. If you're in location B, you're west visible and so on. Trying to get this stuff clear in my head. This is like who knows the fifth time I've been going through this, but now it's for the T2 tile. And so then the design becomes telling myself stories about what's going to happen. This is going to happen. Then this and this and this. And then implementing some stuff, looking at messages coming out from the log file. That's what these things are and telling myself the story about what's going on. West to text compatibility starts to open up. East opens up too. Now, because the way I debug this stuff is I get, well, it's kind of busy at the moment. But what I typically do is I get a ribbon cable and I plug it in this side and connect it to the other side so that when you go out of east, you come around to west. Which folks who know about cellular automata say, oh, it's a tourist. And they say, well, yeah, it is, but it doesn't have to be. Unlike software simulations where the design to wrap around and you can't not do that. Here normally tiles have edges and you have to deal with edges. It's just that you can actually plug a cable in to make it go around if you wanted to. So right now, west and east are connected to each other. They're deciding what's going on. You know, one of the ways that you organize complexity is building invariance into your code where you design them into your code. You say, okay, whenever this guy says A, this other guy has to say B. And that's a contract that they're both ending entering into. So you can tell if it's not B, it's that guy's fault. If it's not A, it's this guy's fault and so on. So designing and designing. What are we actually going to put? We have to make a request to say, I want to do something in the corner that's going to affect you. Please don't do anything while I'm doing that. That's what a lock request is for. And where are we going to put this Yoink value? If you've been watching since a few weeks ago, we had the Yoink protocol, the one strike, three shoot, shoot, shoot. So that when two guys both tried to grab the same piece of real estate at the same time, we'd have a systematic way to decide which guy won so that this guy would go ahead and do it and they wouldn't step on each other's toes. So that's the Yoink value. On and on and on. As I was working through this, I got to, here's a question. I realized, you know, with one, twice, three shoot, you know, there's only two sides. There's the one side of the team, one team, and then the other team. There's only two teams. But when you're saying, I want to grab this little piece of real estate, you could in fact be overlapping with this guy wanted this piece of real estate and a completely separate guy who wanted that piece of real estate. So when we go for an event in the locks, we might actually end up racing with bunches of other people, of other event windows that we're going to actually have to resolve. And that was a real problem. I just had it thought it through. And because the whole idea of the Yoink protocol was that both guys on either end would detect the race. They would realize that the other guy was trying to go for it, too, based on the information they had available. And with the Yoink bit, the random bits being exchanged, each side could tell who was going to win in a fair way without having to send more information back and forth. They would both know it. They would both resolve it. But if one side was having three races and the other guy was having one, this guy, only having the one, would have no way of knowing that this guy might have lost a race to some third party that wasn't even involved in the pair-wise interaction. And that became a real problem. And it took me several days to get my head around, and it's one of those scary moments when you say, you know, maybe the whole idea is going to blow up. But eventually it started to seem like, well, if we have multiple races, could we track the order that we tried to grab the various pieces of real estate, and then when we just detect races, we'll resolve it from oldest to newest? Why is that going to help? Because the one that we tried to grab first, we sent the request out first, which means the guy at the other end is going to see the oldest one first, and he's going to try to resolve it. So if we resolve our multiple overlaps from oldest to newest, then we ought to be able to be resolving them in the same order that the other guys are. So if one of them blows up, they will blow up on the same race. Eventually I sort of convinced myself that it seemed like it was possible, and eventually I finally got to, you know, the point where I could see an event. Actually, this wasn't even seeing an event. This was like reaching a behave. That's active side behave. That's the state and the code where we would do the event, where we would take this little patch of space and rewrite it according to the rules of whatever the program wanted to do. We got that far. And it wasn't sure very long after that, that indeed using our loopback cable connecting east and west, we had a guy in the west trying to, well, you know, I got the log file. So here it was, you know, the log file was going on, you know. It was like calling a sports game or something, you know. 23 goes for an active event in the far northeast. And around the same time, 2 goes to start an event in the far northwest. And 2 sends out a lock request before 23 sees the inbound request from 23. Oh, no! And east happens to read the lock request from west first. It dishes it off to the handler routine. And finally we get to incomplete code. So the race was detected on one side. And that got to the point where we triggered one of our watch out. We have to go implement this now. And this is still not implemented. This is where we are now. But as long as we avoid races, which we can do in some ways, we can actually have events. And that's what led to the new clip in the opening credits. What do you think, folks, that had seen the other previous ones before? I want to do a quick demo and then wrap up. All right. So here it is. Look at this. We've got a tile with three guys on it, but we have two tiles. And the three guys, and now the loopback cable, that's this thing here, is going all the way from west on this guy all the way around back to east on this one. And these are, you know, if you go to the physics here, that button says seed, drag, dereg. But that's not what it's actually doing. It's just seeding these guys. You know, I was thinking, I've been wondering what I want to call those things. I tend to call them guys, but guys is kind of gendered, and I'd rather not call them that. And I was wondering about what if we called them not beings with a G, but we just left the G off. B-E-I-N, call them beans. So these three beans are, all they try to do is go west. They look to see if the spot ahead of them is alive, and if so, they go. And that's it. And these guys have been going for hours. And, you know, we can see what's going on underneath it. Here's the time queue of events. You know, here's the log file. Yikes. This guy's having some temperature issues. Well, a lot of it, it's better when they're tipped up. But all of this works out underneath it. But look at this. Let me see if I can do this. Yeah, all right. What if I pull this cable like that? They stop. Why? Why do they stop? Because since this cable was disconnected, this West ITC intertile connector closed, and they see that the spaces are not available. In fact, we could even, oh yeah, and we've got a down detection here, we could find the program that's running. It's called ITC spike 12 at this point, even though it's turned into a big program. And let's just kill it. Kill 1773, like that. Now, there it is. Now, this thing starts automatically on boot, so it was automatically restarted. And now, I mean, is this true? Can we just plug this thing back in? Look at that. This really feels like living computation, you know? That organization of those three little go West beans, that's not on disk anywhere, that's not being checkpointed, that's nothing. If you lost power here, those things would be gone. But we could move them onto one tile, we could reboot the other tile. We didn't, we just restarted the engine, the native engine, but you get the idea. It's pretty cool. So, but at the same time, if we went ahead and we added enough more of these go West beans, eventually they would, the reason this is working is because all three of them are like more than four rows apart from each other so that their events never actually interact with each other. That's coming for the future. But this is the first reasonably reliable intertile event that's actually going between physically separate tiles, not just going by the fact, even though this part is. So that's pretty cool. All right, whoops. Yeah, the other news, just a quick wrap up. The Living Computation Foundation that we've set up to be a coordination point, a non-profit organization that last week was announcing it actually has a donate button now. And that, you know, people can support it via PayPal and we offered our new Living Computation Foundation nerd numbers, if people are in a position where they can donate $5 or more. And a bunch of people did, more than a dozen LCFN Living Computation Foundation numbers have gone out and everybody who comes after that are going to get a higher one. The low numbers, there's still a bunch of low numbers yet, but they're moving on out. And, you know, what are they good for? They're good for showing your support and that's it. And I really wish we could get away. Wouldn't it be cool if you get your LCFN on a t-shirt or something specific for yours? You know, I'm LCFN 222, 222, whatever it happens to be. At the moment, we do not yet have our tax deduction determination letter from the IRS. So if you're thinking of sending more money, you should probably wait a little bit. But if you want to support this work, if you think building the biggest computer ever with our little group of people who see computing differently, see it could be more than it is, more than just rigid rule following that's oblivious to its surroundings. Get an LCFN, show your support. You know, it's easy to get torqued up about money. But really, I'm just trying to understand for myself that, you know, supporting on social networks, people who are writing code or doing, you know, anything, all of that stuff is incredibly important. And in a way, it's the kind of stuff that you can't really buy with money. And so in a sense, it's more important. So thank you for everybody for making comments and retweeting and Instagramming and all these things that people are doing. It's really great. It really feels to me like, you know, this for some, and I've been doing this for a long time, and it's pretty way out there within computation. So, you know, getting traction is a slow process. And I understand that this is an extremely big revision to the ongoing set of rules of the road that computation, computer science, computer engineering have been using to talk to each other for many decades. So it's great to start to see that support coming in, to start to see people getting it. I really appreciate it. I thank that you're here. The next update will be in two weeks. I don't even know what to put myself on the hook for. You know, keep implementing the incomplete codes. Keep testing it out. It's going to be the A-Life 2020 conference, which there's supposed to be a tutorial about some of this stuff as well, perhaps as a paper presentation of some sort and a demo of a whole bunch of new stuff and the coming out of the grid. Not just two tiles, not just 10, but over 100 of them all working together with programs moving between them and so forth. It's coming. Thank you so much for being here. Stay safe. Stay the right amount of sane. Hope to see you next time.