 Computers keep changing the world, but their power and safety is limited by their rigid design. The T2 tile project works for bigger and safer computing using living systems principles. Follow our progress here on T Tuesday updates. This is the 47th T Tuesday update, let's get into it. So for the last several weeks we've been working on getting cash updates going between tiles. The two things we need to have intertile events, which is what's going to allow us to make an indefinitely scalable computer by connecting more and more tiles is by being able to have an event that starts on one tile and ends on another tile. In order to do that we need locking where we say please don't mess with this stuff because I'm going to mess with it and then we need a cash update where we say here's how I messed with it. Make your cash copy of MySpace look the same as MySpace so that we'll have a consistent view across the border. In this past week using the loopback cables using the tile connected to itself so it doesn't really know that it's connected to itself but it makes debugging a lot easier. We actually got intertile events working on loopback and I'll talk about that, that's the main event. In the coming week having loopback cables it turns out it does not get us exactly all the direction that we need to go to get true intertile events and I'll talk about that. Alright so in education and outreach yeah so also last week I did this podcast. The book I mentioned Algorithms to Live By by Brian Christian and Tom Griffiths. Audible.com is making a follow on little podcast, a series of podcasts called Algorithms at Work and Brian invited me to come on and talk about the T2 style stuff so I did that last week. They actually sprung to rent a studio in Albuquerque that I drove over. Another one of these things, no idea that this thing ever existed at all and here it is. I talked to Brian, mostly Brian and also Tom Griffiths for most of an hour and it was really quite good and actually had a sound engineer guy doing sound engineering that I chatted with after he was a nice guy. He's also a musician and overall it was really good like I said we talked for about an hour and I have no idea how much of that they're actually going to use but we really hit everything. It was living computation, it was hardware determinism, it was indefinite scalability and it was the T2 Tile project explicitly so that was really great. We'll see how much of that ever gets used out of no idea what the timeline is for that stuff coming out but did that and it was fun to be in a recording studio. I've never really done that before either. Coming up in two weeks is this workshop at the Santa Fe Institute that I got invited to about biological computation. Now I'm not speaking at this thing, there's a bunch of people going and they're not having that many talks but they are having sort of little impromptu 10 minute things on the final day that you can sign up for so probably I'll try to sign up for one of those and just let folks know the stuff that we're doing here as well. So that's education and outreach. Alright, the main event. Limited to the case of doing it on loopback, we actually have intertile events happening for the first time really in the history of the universe and it's incredibly slow. I mean at this point I'm kind of adjusted to it. I sort of feel like Rodney Dangerfield. I'll tell you, I feel alright now but last week it was rough because it was. It's incredibly slow doing all the communications and so on and so forth. Now I warned us that it was going to be slow but we're nowhere close to one air. So I made a little time lapse that we'll take a look at and then I'll come back and say what I think we probably can do about it and so forth. Oh yeah, T2 Tile on full loopback. This is basically the first thing I got at work. So we have one particle here that just tries to go west. Every time it has an event it tries to go west and look at this. It's actually going out the west and coming in the east. That's the intertile event. But it's, you know, look at my watch. So that was speeded up like 1500 times or something like that, like two seconds in an hour. I don't know. It's incredibly slow. It's watching paint dry. It's watching grass grow slow. And we knew this was coming. We knew it was possible. But, you know, I actually said, okay, now I could make a measurement of what was that air based on the video. So I did that. And, you know, the simulator itself makes these claims .032 air, you know, like that. But that is excluding certain overheads and it takes a lot of time to sort of make estimates and the estimates to relax and so forth. So I said, well, you know, look, let's just, we know that the dot is going to move one site every time it gets an event. Because here's the event. I called it Watson, you know, like, come here. I need you. It's kind of a little one of the circles of Inferno because it never actually arrives. It just keeps going around and around. But it just swaps west every time it has an event. So, you know, events are happening all over the tile. But the all the ones that are happening in empty space, they generate updates. They generate traffic, less traffic than they might be if there was stuff, but there actually is stuff still going. So, so here it is. And so, you know, I just marked it. So when it was all the way at the right hand end, one of the times it got there was like almost 7pm. And, you know, there are 52 active sites, which is sort of a weird number, but internally there's actually 60 wide. But then there's a stripe of four for a cache on one side and a stripe of four for a cache on the other side. It's take away eight. So 60 minus eight is 52. So 52 events will actually take us around the universe once. And that took it arrived back there at 918. That's like two and a half hours, 8400 seconds, 8400 seconds for 52 events, .006 air. And, you know, just sit and look at it, you don't see anything. You're very lucky if you ever see the Watson move. So that's a huge bummer. I mean, you know, knowing that that was a possibility and actually saying here we are are two different kinds of things. So now the couple, you know, there's a whole bunch of footnotes on this. So footnote number one is, you know, the although having the loopback cables makes debugging and stuff much easier. There's a sense in which it's actually a difficult case for the performance. Because normally when we have a whole bunch of tiles in a grid and a given tile tries to grab a lock to the west, say, there will be some fraction of the time when the lock is already being used by someone else. And so the attempt to grab the lock will fail. And when that happens, MFM just goes on and says, we'll just have an event someplace else. It doesn't wait because it really can't wait because the whole point is that everybody's independent. But when you're on the loopback, it never fails because when this guy is requesting a lock out the west, he's definitely not also requesting a lock out the east. So every time we actually try to do an event that's on the border with the loopback, it succeeds, which means we have to do the locking and the cache update and send everything and so forth. Whereas when we actually had tiles, intertiles, and they were talking to each other, some of them would fail and go on and do it. So we might actually get a little bit more performance out of that. There's also a whole bunch of things and I've talked about them over the last weeks and months where I was giving up performance in order to make the implementation simpler, more obvious, or more robust. And I even did two of those in just this past week that, you know, because there's a difference between the way the MFM code looks at the world. For example, the MFM code wants to take one lock at a time. If it needs to, it tries to get one and then tries to get the other. Now the underlying Linux kernel module that I wrote actually takes a set and you can say, give me these locks all at once and it will actually go for them in parallel. But to preserve as much of the mobile feast machine code for purposes of getting it running, I don't take advantage of that. I just try to get one lock. I try to get the other. Similarly, the mobile feast machine is expecting to have a separate channel, six separate channels, one for east, one for west, all separate that it can read from whenever it wants to. Whereas the way the Linux kernel module is designed, it provides all of the MFM traffic on a single channel with each packet labeled by its destination. So rather than redo all the mobile feast machine code in order to get it working, I put an additional layer of buffering that reads all the packets in and dishes them out to six different waiting areas so that when the particular direction east or northeast or whatever it is wants to go for a packet, it can go to a specific place, but it means the packets are getting copied in extra time that they don't need to. There's a zillion things like that. So on the one hand, a lot of that stuff could be fixed. But on the other hand, you know, that might bias a factor of 10. It might even conceivably bias a factor of 100, although I doubt it. But even if it did, that would be a half an error. And really, we just got to adjust to that's what the T2 tiles are going to be like. And, you know, maybe the fantasy of having it all be super fizzy and yet from here to the horizon, maybe that was asking a little bit much all along. I mean, after all, you know, it was on the third day that the earth brought forth the plants and the actual fizzy jumpy run around the animals didn't happen until the fifth day. Maybe when we're trying to build a completely new computational stack, we should be thinking that looking at the T2 tiles running is going to be less like going to a movie and more like sitting in a garden. Maybe it is like watching the grass grow. And that could go to something like Montreal next year that, in fact, it really might be a better idea to have the display if it works out in the lobby so that people could just be kind of going by it as if it was kind of like a mural and say, wait, that kind of changed from before lunches or something like that like seeing things happen in the garden. And from a scientific purpose, you know, we can still just point the camera at it just like I did here and do time-lapse to see what the future could look like if we had tiles that had better air, you know, that could have better air. It takes some adjustments, but I'm okay. I think it's there. Like I said, Rodney Dangerfield. So that's it for this thing? Yeah, that's it for this thing. All right. So now part of, you know, understanding all this is saying, you know, why is it so much worse than I was fantasizing? Because I mean, you know, theoretically, this was like supposed to be engineering rather than fantasy. So I want to go back and go through where the numbers came from, the estimates that were underlying this so that we can understand, you know, why is it that the T2 is coming out the way it is and so forth? Does it actually make sense? This is going all the way back to 2012 now, almost seven years ago when we published this paper in the computer journal. It was one of the longer papers that we did. And, you know, one of the good things about good and bad, depending on how you break, is you get a lot more reviewing, a lot more intensive reviewing in journal papers than you do from conference papers where, you know, you know, generally, you kind of get either one round of conference paper reviewing and it's either in or out because the thing's going to happen. Whereas journals that the reviewers can ask for lots of changes. And one of the things the journals that the reviewers asked for here was, well, how is this going to work? How is it going to perform? And this section three that we added, performance estimation, was in response to a reviewer request. So what we did was saying, well, you know, we don't have any actual hardware, so we don't, we can't really know, but we can simulate it, we can guess. And here's the main line. We can expect an indefinitely scalable air in the several hundreds to a thousand or more without heroic engineering using affordable tile suitable for research. So, you know, that might be true for somebody else's definition of heroic engineering. It's not true for my hardware abilities with the T2 tile. So where do we go wrong? Let's drill, we drill a little deeper into it. Since we have no actual indefinitely scalable implementations, here we employ a hypothetical tile processors with parameters or something like figure seven. And here they are. And this is really the smoking gun. So we imagined back in 2012 that the little tile would be going at 100 MHz and in fact these guys are going 720 MHz and they're capable of going 1,000 MHz at gigahertz, but I usually have them running a little slower for temperature. So it's going a lot faster than we were imagining for the hypothetical processor. Instruction time, two cycles per instruction, that's perfectly reasonable. The intertile mutex lock try, 20 cycles. 20 cycles at 100 MHz, that is 5 microseconds, something like that. Well, we saw that we were doing like 50, 100, 100 plus microseconds because we're doing it all in software in Linux. We tried to go fast, but we're nowhere close to that. Same thing for the unlock, nowhere close to that. And the intertile IO speed, 1 to 10 Mbps, because we were hypothesizing to check a range of variations, we're not getting anything close to that either. The sort of raw sending stuff, pushing stuff through the wire can approach a Mbps, I can actually get over a Mbps if the packets are big enough. But once again, that's not including all of the going through Linux, going from the buffers, going getting copied here, copied there, copying multiple places, we're not getting anything like the intertile IO speed and that's really where all the performance is going, I think. With these kind of numbers, we got this kind of graph back in 2012 that if everything was working exactly right, we might have gotten 7,000 air or yeah, that's if you could do an event in 1,000 instructions and you had a 10 Mbps line and so on and so forth. So in fact, we are much more down here in the very, very, very close to zero end of the spectrum. But as we've been saying all along, for scientific purpose, for engineering purpose, any number is a benchmark. And from one point of view, the smaller it is now, the more fastest growing we can have as we make improvements going forward. And again, we don't know by the time we actually get to benchmarking Dreg physics on an indefinitely scalable grid, whether it's going to be more or less than 0.006, we don't know. All right, and it says, MFM performance is highly sensitive to communication costs and so forth. Well, that I think we've kind of confirmed. It wasn't a surprise, but here it is. All right, so now one of the things, I can't really take too much time about this, but going forward, one of the reasons why the loopback is an easier case is because, you know, if we're asking out of East, then definitely something exists on West, whereas in the inner tile case, they can be booting, they can be going up and down, they can be in the middle of anything and stuff can fail in just about any direction. And so it pushes you, it pushes me, it's in the process of pushing me. So here we've got the default fail illegal state, and that's the typical way that you write correct and efficient programming. Anything that shouldn't happen, you assert that it doesn't happen to stop the insanity. But the alternative approach, the self-stabilizing approach, is to say, well, if something unexpected happens, let's explicitly say, here's your safe space. If we get lost, let's meet at the old tree. Have fallback positions just in case anything goes wrong. So this kind of code has been changing into this kind of code. If the unclaimed case happens, which really shouldn't happen, then we log an error about it to let somebody know. But then we go ahead and reclaim it, which is a step towards actually letting things happen again and so forth. And this is happening all through the code. It really goes back to, well, just don't have time to go into it. I would love to talk about CCR, which is another one of the really big projects I did a long time ago that had similar kinds of self-stabilizing code in it for dealing with this kind of thing as well. So just about out of time. Last week was rough for a couple of reasons. But here we are. We're going to make digital living plants with stuff flowing through them. And then just like you make time-lapse videos of plants growing and see how amazing that is, we'll make time-lapse videos of things happening on the T2 tile grid. And hopefully we'll get soon to that being amazing as well. So, alright. And the bottom line is it's not 0.006 air. It's 6 milli-air loopback has been achieved. It's not the benchmark yet, but the benchmark is going to be in that ballpark and we're going to say how many milli-air can we prove that is established on an indefinitely scalable grid. We'll find out. Next update will be out in a week. Thanks for being here. You have a good week.