 The T2 Tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday Updates. So we're back. It's another week in pandemic world. I went out to get food for the first time in a couple of weeks using one of these homemade chopped up t-shirt masks. It was sort of strange. Didn't see that many masks out there in the world. Things are still going to be changing pretty quick here, I think. In the T2 Tile project last week, I announced the formation of the Living Computation Foundation. Now a couple of quick updates. There's a chat room, a chat sub room on the Gitter specifically for the Living Computation stuff. It's got the mission statement and Andrew Walpole, who's been doing so much great stuff, has been putting up possibilities for different versions of the logo, other possible logos. These things that he's got an explanation for him. He's got the sort of a sun thing for life and the input output links and stuff like that. I'm not sure. I'm trying to let it grow on me. And also for a logo type, the stylized form of the abbreviation LCF Living Computation Foundation that Shirley will need as well. And he's got these two that I kind of like. I think there's some potential for these things with the F kind of going off like a little flame of life or something like that and everything all getting packed together. There's lots of stuff going on. Thank you, Andrew. Another Andrew as well was contributing to the discussion. Thank you. And I encourage everybody, especially if you have any of those inklings for doing graphics design and stuff like that, if you have some experience and you might have some possible unfunded mandate for coronavirus shut-ins, come take a look, see what you think. And then, yeah, the foundations, the logo as it stands now, not wedded to it. Although, you know, I need to like it, whatever it is, I need to like it. Okay. So the main event for today for this week is back to intertile events. And you know, what I didn't want to do was just, you know, sort of show, okay, I wrote a bunch of code, top down, starting in the new version and put on the, die unimplemented, die unimplemented, and then I just started running it. Couldn't open the things to get packets, figured out how to get them open, couldn't do the next step, figured it out, pushed it down, pushed it down, and that's a lot of what I've been doing. But again, it's just not very exciting, and I'm not sure it's really very insightful. So what I want to try to do today is push back up to a slightly higher picture, higher level view of intertile events, and come a circle back around to an idea that I've started working on, this stuff that I'm showing little pizza code here is working on, is aiming at. Kartik Agarom, who we got hooked up with through the Future of Coding Slack, Steve Krauss's thing, posted an interesting little connection between a couple of different programming languages and architectures on Twitter a week and a half ago, connecting it to the Moveable Feast Machine, and he described it as Moveable Feast Machine, a tiled processor for very finely grain distributed computation. And that's just right, that's a good description. The distributed part and the fine grain part are both really key. And what it means, so distributed means you don't have one thing in charge, and fine grain means you have a lot of small things in charge. And that's what makes intertile events so fundamental. When you're using a regular serial computer, there's only one thing happening at a time where at least the whole system is designed and architected, engineered to let the programmer believe there's only one thing happening at a time, except in specific cases of multicore and so forth, when there are potentially violations of that general principle of serial execution going on. And having only one thing happen at a time is a tremendous simplification that allows you to reason about things and know this is done before that begins and so forth. The cost of that wonderfulness, of course, is that you can only go so fast, you can only get so big because there's just that one moving finger having RIT moving on, and many hands make light work, serial doesn't take advantage of that. So if you go the other direction, as we are doing in the t-tile project where we embrace indefinite scalability, anything that's going to keep us from saying we're just going to be able to plug more in, plug more in, we're not going to allow, we're going to rule it out indefinite scalability commits us to saying whatever that we're using as our fundamental tile, we'll be able to tile it out as long as we have power, cooling, money to buy tiles, and real estate to lay them out. So that means in exchange for giving up on serial and getting scalability, we have this coordination problem, how do we get these multiple independent agents to agree so that when something happens, one guy goes, the other guy goes, and they don't both try to go at the same time, they don't end up racing, and I've mentioned this paper before, non-determinism is unavoidable, but data races are pure eel, and I love the title because it's so owning it, it's just going for it. And Hans J. Bohm, I don't know him personally, but I know some of the stuff he's done, he did a garbage collector for C, he's not a bunch of very good stuff, he's a good guy, I mean, he's a smart guy and knows a lot about computer architecture programming languages and all that sort of thing. And so this was for a workshop in 2012 that I've mentioned sometimes before, and the call for the papers that this workshop was in was saying, a new school of thought is arising that accepts and embraces non-determinism, including data races. In other words, where you don't know which one is going to actually get in there and get stored because multiple values are heading for a given storage location and you don't know which one is going to get there first, and in turn reduce synchronization or even eliminate it completely. And that's what we're facing from the other direction with the T2 Tile project where initially we have no synchronization and we have to just try to get what we can get. So the advantage of serial is that it makes everything easy to reason about and really or easy to organize. The cost of it is that there's only one thing happening at a time and as soon as you step beyond that and start having multiple things happen at a time, you get terrible bugs and so forth. The flip side is when you don't have a guaranteed serial and you have many, many things happening at once, you have to figure out how to coordinate, you have to figure out how to synchronize. And not just that, you have to as an additional constraint. It's a separate constraint. You want to have that coordination process be somehow fair with respect to all of these little tiles, rather than just saying, I'm king of the back lot and I always get to go first and I always get to do as much as I want. That's not going to present a good understandable programming substrate to the programmer on top. We need to be able to say that, you know, yes, there are going to be variations in how many events happen and when they happen where it's all randomized. But in general, there's going to be no particular areas going to get starved. You're happy to be running over there as you are over here because you'll get events over there. You'll get events over here. That's what being fair is supports. So, you know, one way to think about this is it's like rock, paper, scissors or something like that where, you know, each side, when they're saying who gets to go next, I want to go, I want to go, that, you know, each one has the ability to flip the outcome. There's nothing that you can pick that the other side can't respond to in some way. And, you know, this comes up a lot. I want to pick instead of rock, paper, scissors, this is the one that I used when I was a kid, you know, odds and evens, you know, this one, you know, we were at least according to Wikipedia, you know, you go once, twice, thrice, shoot, and you put out a one or a two. And if you're odds and the total is odd, you win. If the total is even, the guy's got even wins and so forth. Now, I don't know, once, twice, thrice, sounds like Victorian England to me. When I was a kid on Long Island in the 60s, what we said was one strike three, shoot, shoot, shoot, whatever it was. I guess I can believe that one strike three kind of sounds like a corruption of a once, twice, thrice. But also we were playing Sandlot baseball, so getting strikes and one strike means for the reasons. The point is, is that it's not just like the rule of the rock, paper, scissors that each thing has a possible counter move. It's also that you actually need to synchronize just to make the decision. Well, why is that? Because by doing one strike three, shoot, what you're actually doing is deliberately creating a race. The whole point is that both sides can believe that the other side must have committed to their choice before they saw what the other side did. And that's the exact essence of a race, right? And that, you know, you can't change your mind because they're both in flight at the same time. Through the communication medium, whatever it happens to be, my two is out there while his one is coming in and we both figure it out in sync. We both figure them out in the same group time. We figure them out by racing against each other, and we can both agree on the answer. Odd wins, even wins. So it's not a matter of data races being evil in this context. The data race is the whole point when you move beyond saying we have a single threat of control in when you have a single threat of control. Yes, races are evil because it's destroying the illusion of a single point of control. But when you have many points, having a deliberately engineered race is what gives you confidence in the fairness of the algorithm. Okay. So what that says is that, you know, in the so all right. So so here's my protocol. I've just renamed it today. It's the joint protocol. So the idea is is when you want to have an event, you need to have a lock between your neighbor because you're doing an event near the edge where they could see the results. You just try and grab the lock, which in this in the case of what I'm running now, it means you send a message saying, I am requesting a lock on this little region, event window radius of three, because that's what the atom needs at location x y whatever it is. But in addition to sending along all the information about the where the event actually is, you also include one random bit. And if the other guy isn't trying to have an event at that spot, then you win, you don't you grab a lock and it's great. The only case where it's a problem is if the other side was simultaneously trying to grab a lock that was going to overlap, and the two requests cross in the data fabric cross in communications. And that's exactly equivalent to one strike three shoot. And if it doesn't happen, see, the key thing about one strike three shoot is we all agree that we're picking sides or we're deciding who's going to bat first or whatever it is. In this case, we don't even have that agreement. We might have both sides trying to have an event, but we might not. So that's where the yoink comes in first, you try and grab it. And it's only if the other guy is trying to grab it to, then that means your request to that guy and that guy's request to you will cross in the fabric and you'll both see them. And then you'll have your random bit and you'll have his random bit. And you play odds and evens with them if it's a zero that's throwing a one or whatever it is, you add up the two bits. And if it's even one guy wins and if it's odd, the other guy wins and you just hard code that Northwest is odd Southeast is even that kind of thing. So what happens then is that it doesn't it's not actually super critical that we be able to resolve the lock situation as quickly as possible, or at least if we're actually doing this by sending packets, which are going through the outboard proves and blah, blah, blah, all that stuff we're working through as we saw months ago, that's not super fast. And in fact, we had a special extra hardware that we made to try to make the locking fast. But all of that I realized a week or so ago is based on the idea that we have one event window on the tile. And so when we decide that we are going to do an event window here, and that implies I need a West lock, we block, we say, I want to get the West lock, we need to get the West lock as quick as we possibly can. So we know whether we can go ahead with this or not. Now, in the way the simulator implements it, if it can't get the lock, then it just drops the whole thing and goes and does something else. But it still has to find out the lock resolution process has to settle before it can do anything else. So that's what this code is heading for. And you know, this model where there's only one event window per tile goes all the way back to this paper from 2012. And I've shown this before with the intertile mutex mutual exclusion lock try 20 cycles. This was the thing that turned out to be completely unrealistic on the T two tiles, the lock attempts, even with the special hardware stuff takes a much, much, much longer than that. And that was one of the reasons to feel bad about how many air or milli air we're going to get out of these things. However, suppose we had lots of events windows going at once, then we could say, okay, I'm asking for this thing, I'll send him a packet, I'll go on other business, I'll start another event window over here that needs to have a lock with West and I'll send him a packet. And all of this stuff can be going on while I'm doing packets, while I'm doing events in the middle of the tile and no problem. And so the locking mechanism doesn't have to be super fast as long as we can have enough parallelism in event windows to cover the the latency of talking to the other side. So what we need is we need lock packets requested acts that aren't very big, so they don't take up a lot of bandwidth. And we need to be able to hold lots of locks all over the place, not just one lock for the entire north edge or the entire West edge. But specifically, I only need this many sites, radius three around six comma 22, whatever it is. And that's what we're implementing now implementing precision locking, where you request exactly the sites that you need. And the other side has a we have an array of all of the sites and who's locked by who, and we can have up to right. So as opposed to doing what we did before, where you know, so all of these things in the schematic everything that ends with LK there, those are the special wires just for locking. And in there it was that in in the MFM simulator, where is it? Oh, yeah, there it is, the one and only event window per tile. But what I'm doing now is event window is an array of a bunch of them, the tile has max EW slot of them, which is basically 32 that so the way I'm designing it. This tile will be able to originate 32 events that it's doing simultaneously with its neighbors. I'm sorry, 16 events that it's doing simultaneously with its neighbors, and also manage 16 that its neighbors are doing that requires locks on it 16 for active where it's running the event 16 for passive where neighbors are running the event all going at once. We'll see. It's a significant redesign. It means more state machines. But again, doing all of this stuff at the Linux kernel module level and so forth over and over again, doing the state machines getting it working gives me a little bit more confidence, we can do it yet again at the event level. That's it. Okay, so I ran long here. But I'm a little bit excited about it. I really want to find out, you know, number one, is this going to give us some speed up? And I hope it will. And number two, just, you know, got to get it working first, we can actually see it. And, you know, there's quite a ways to go here. But I'm not going to be back for two weeks. So the next update will be April 14. Half way through April, who knows what the world will be at that point. Let's hope for the best for everybody. I hope to see you in two weeks.