Hi, as you can probably rapidly tell from my accent, I'm not actually from the UK. What he means is I was in the UK before I came to Fosden. I went to the Manchester United game on Wednesday to watch our awful terrible draw against Hull, but it was still fun. I still enjoyed it. Okay, so but let's talk about Ruby garbage collection. So I have a performance consultancy called Speed Shop where I work with companies on their Ruby and Rails applications to make them faster. To make them more performant. And one of I would say the number one issues that I tend to see is companies that don't understand memory usage in their Ruby applications.  You're not supposed to think about memory. You're supposed to just write the code you want to write.  And you can't intentionally write leaks, right? But it's a little more complicated than that. And so I thought we could all benefit if we understood a little bit more about how garbage collection actually works and how it's evolved and got a lot more complicated since those long ago days of Ruby 1.8. This talk is beginner friendly. That's why it's a people's history. It's by the people for the people. If you're a Ruby core team member, you probably will not find anything interesting or novel in this talk. And I've tried to structure all of this so that if you don't know anything about garbage collection or if you don't know anything about garbage collection algorithms, this should not be too challenging for you to understand. Okay, so I would say that the whole history of Ruby's garbage collector has mostly been about how do we reduce GC pause times? How do we reduce the amount of time that we spend stopped to garbage collect? Because in Ruby, we have to, in MRI, see Ruby, which is what I'm talking about here today. I'm not talking about JRuby or Truffle Ruby. Those guys have their own garbage collectors that work in completely different, much more complicated ways. In CRuby, we're mostly at this evolution over time. We're trying to reduce the amount of time we have to spend stopped to garbage collect. We have to stop during garbage collection because if we allow things to move along and execute Ruby during garbage collection, we're going to lose track of which objects we've already looked at to see if they're free or not, which ones we haven't, and we're going to end up with memory bugs. We have to stop for periods of time and say, stop execution, hold on, which of these objects are being used and which of them are not. But if we pause for a very long time, that would cause pretty bad behavior, especially in a web application. So if we need to spend a half a second garbage collecting, which was not uncommon in Ruby 1.8 days, then what happens if we spend, we have 50 milliseconds in our web response. We're doing our normal work and then, oh crap, we need a GC. So the person getting this response has to wait a half a second for that to complete, and then you do the rest of the work at the request, 50 milliseconds, whatever. So a 100 millisecond request now takes 600 milliseconds. So that's not really acceptable. So really, this history is about how do we make these GC pauses shorter and more interleaved throughout the application actually running. So let's start with 1.8. This 1.8 employ, and as far as I know from Ruby's inception, employed a Mark and Sweep garbage collection algorithm. This is really the simplest possible garbage collection algorithm that you can have. So to talk about how Mark and Sweep works, I need to explain to you how Ruby organizes its memory. Ruby objects are organized in something called the object space. Sometimes this is called the heap, but I find that slightly confusing. Object space is the name of the module that you can use to inspect the object space. So I'm just gonna call this part of the Ruby's heap the object space. It's basically just a list of Ruby objects. So every Ruby object has one R value, which is the name of the C structure that we hold these Ruby objects, right? R values are 40 bytes, and they contain some information about the Ruby object. It's just a list of, R values is just a list of some flags, like have we marked this object yet for garbage collection, some other information, and also some very basic information about the object. This all depends on what type of object it is. If it's a string, an array, et cetera, et cetera, et cetera. If it's a string, if it's a very small string, we can contain that string right in the R value. It's actually like 23 bytes or smaller, it's like a whole great blog post by Pat Shaughnessy about why Ruby can only store 23 byte strings inside the R value. If the data is too large to store in the R value, so strings longer than 24 characters or arrays of five elements or more. So if it's too big to fit in that R value, we just store the pointer to space somewhere else on Ruby's heap. The object space is a list of 16 kilobyte heap pages and of 400 R values each. So it's just a long list of these heap pages which contain all of our R values. So what triggers GC? I think one common misconception is that GC just sort of, well, people don't really understand when it runs at all. That kind of runs on a loop or like it runs every five seconds or whatever. Really, there are two main things that trigger GC, although there's more conditions than this that I'm not going to get into. Either we run out of open slots for new R values or we allocate enough memory on the heap that passes a limit. So if we just run out of object slots, we have to get new slots, right? So Ruby will garbage collect to try to reuse the slots that it has already allocated for itself. The other malloc limit is when, like I said, if a string, for example, is 1,000 characters long, it's going to have to allocate space on the heap for that 1,000 character string because it doesn't fit in the R value, right? So that's 1,000 characters, which would be 8,000 bytes or whatever, or bits. So once the amount of space that we allocate in that way crosses a certain threshold, we garbage collect. That's called the malloc limit. There's also some other limits which I'm not going to talk about, but those are kind of the main things that end up triggering GC in Ruby. So when we trigger GC, we're going to start with the root objects.  So we start with the Rails.Application object. And then we're going to look for all the references to that object and traverse down the object graph. So each object that references Rails.Application, for example, which I don't know if is really a root object or not. Maybe Rails.is, but anyway, we start at our root object, traverse down the object graph until we've marked everything that references each other. And then any object at the end of that, which hasn't been marked, is free, because it's nothing's referencing it, right? Pretty simple. And then all the free rvalue slots get added to the free list. Simple as that. And then in the future, so that's the marking phase, and then I should say marking phase, and then sweep puts objects into the free list. So setting the mark bits, marking objects is one phase, sweeping them into the free list as the next. And then the next time we need an rvalue slot for an object, we just grab one off the free list. If we run out of, even if after garbage collection, if we still don't have any free slots, then we allocate more slots using malloc to put more slot, to create more heat pages and get more slots. In 1.8, this is done with the FL mark flag. This is one of the flags in rvalue at the time. And you just set that to one or zero after you mark an object. If it was zero when you were all done marking, that was a free object. Of course, sorry, I should say an object that could be freed during sweeping. So garbage collection looked like this. You had a whole long mark phase and a whole long sweep phase. Then you were done with GC. You could go do whatever you wanted to do. And then you have the GC again eventually and a long mark phase and a long sweep phase. Sweeping always immediately came after marking. There's no pause in between. And so in a large Rails application that had 400,000 objects, even a million active objects, this could take a very long time. Could take a million objects, could take a second to mark all the way through, right? Because we have to mark through the entire object graph. So that takes a long time. No Ruby can be executed during that time. And like I said, that's not really convenient for a web application where if normally your responses only take 10 milliseconds to process, if someone gets 10 milliseconds plus one second of GC pause, that's kind of annoying and not really performant. So next came 1.8 Ruby Enterprise Edition. This is a project of Fusion, the guys that write the passenger web server. This was kind of like the big, I don't know if anyone here used Ruby Enterprise Edition. That's kind of like old school now, yeah. So it had a couple things going for it. One of it was it's support for copy and write memory. So let's talk about copy and write. We have these things called forking web servers in Ruby because we don't have real parallelism I should say. You can't execute two bits of Ruby code at the same time. So what we do instead is we have two different processes, two different web server processes that are the same and can just execute different responses at the same time. So Puma, which I am on the committer team for is an example of a forking web server, also passenger and unicorn do that. And when you fork a process, the child process shares its memory with the parent to the extent that it can. And it does that through copy and write memory. So we have to talk about shared versus private memory. So the child process when it gets forked from the parent, gets a, not a copy, but it gets some addresses that looks like a copy of the parent's memory. And that's shared memory. And it's just the exact copy of the parent's processes memory. But whenever it tries to modify one, the child process tries to modify one of those memory pages, the operating system in the background will copy it. So it's kind of like a copy on demand thing, right? So it's very important. When are you writing to memory locations in a child process? Because that'll create a copy which will increase your memory usage. So this copy and write is the whole reason that when you have a Puma process with three workers, you don't see exactly three times the memory usage that you do when you have one process. Cause we're sharing some small portion, 10 to 30% of that memory between the child and the process. This is the whole reason why you pre-boot or pre-load depending on what your web server is. So the idea is that you load the entire application first before forking. So you can share the maximum amount of memory possible, right? The problem with this, right? If you remember my description of how 1.8 worked, we touch the FL mark flag every time we mark. So you set the mark from zero to one and one to zero and that touches that memory location which ends up copying the memory page. So we couldn't garbage collect without breaking copy on write, right? Every time you garbage collected, it would create copies of all the memory in the child process and now you're back to where you started with memory usage. So that was kind of inconvenient and it's kind of a wasteful use of memory. Ruby Enterprise Edition fixed that with a method I'm gonna talk about later cause we got it for in core and 2.0. And Ruby Enterprise Edition ended up using the exact same method that 2.0 used. So we'll talk about that in a minute. In the meantime, 1.9, which I think actually came in .3, Narhira Nakamura gave us lazy sweeping. So the whole idea is you don't sweep until you need it. It's, we're trying to break the sweep phase into multiple smaller phases. We're still gonna have one big long stop the world mark but we're gonna sweep only in smaller increments when we actually need it, which is when we need new slots. So we just sweep until we have enough free objects to have to deal with whatever were Alec were, whatever objects were creating and then we go back to program execution until we need more slots and then sweep again. So we're doing the mark phase just like we did in 1.8 but then we'll sweep a little bit immediately for whatever we needed but then we'll go back to program execution and then sweep objects into the free list only as necessary. So this decreases the worst case times, right? Because rather than having one long mark followed by one very long sweep, you have one mark followed by several smaller sweeps. So the worst case that you could have for a GC pause time was greatly reduced. So mark sweep sweep sweep and then mark again. In 2.0, we got official copy on write support. I mean, technically you're always supporting copy on write. It just either works well or it doesn't work at all. Like it's all, copy on write only happens at the operating system level. So technically, like you already supported it. You just didn't take advantage of it really. And we got that through something called bitmap marking which is another Naruto Nakamura commit. The whole idea with bitmap marking is okay, well if touching the FL mark bit on the R value triggers that copy, let's just keep the mark bit somewhere else where in a different memory location so that when we touch it, we're only copying mark bits and we're not copying this 40 byte R value object. And that's done through bit mapping. So instead of keeping the FL mark bit in R value, we keep it in a separate array of bits. And we can get that, it's not like a point or anything, it's just an address. So if our R value is at memory address 0x whatever, we just do some arithmetic to calculate where the mark bit is. And that's done through something called memory address aligning. So you can just do some arithmetic to figure that out to figure out where the bit for marking is. So that makes Ruby copy on write friendly, yay. And this saw pretty big memory reduction usage for people using forking web servers.  So we're still marked with sweep, sweep, sweep, we just kind of changed where the mark bit actually resides, right? It now resides in a separate area, not in the R value. There are a couple more bits now that are bitmap marked in this way that aren't stored in R value. We'll probably get to those in a bit. In 2.1, we got generational garbage collection. This is where we start, 2.1 is where we start seeing some actually like big changes in how GC is actually done. This was written by Koichi Sasada who's a Rails Ruby core team member, works for Heroku now, actually doesn't work for Heroku anymore, works for Cookpad, did work for Heroku for a while, but one of the few people paid to work on MRI.  New objects become old when they survive a certain amount of garbage collections. I don't think this is actually the correct number for what it was in 2.1. Now, if you survive three collections, you are promoted, if you survive three marking phases, I should say, you're now promoted to an old object. Back then, I think it might have been less. Now we have minor and major GCs.  Most objects are just around for the duration of a web request or whatever, and then they can be garbage collected after that. And traversing old objects, looking for stuff to garbage collect there, like if you're going through the Ruby code, if you're going through all the objects that get created when Rails starts up, it's kind of inefficient to traverse those objects every time we mark, right? Because they're not going anywhere. The only objects that are probably gonna go somewhere are the ones that we just created, like request headers or whatever. So during a minor GC, we're only gonna look at new objects to mark and during a major GC, we're gonna look at all objects. We're gonna look at new and old objects in the marking phase. So all we've done is just created two different kinds of marking phases. The problem is now you have to keep track of these different kinds of objects. So the way that this gets explained, and I'm pretty sure this is how it works in GC.cs, we have three different colors. We have black, gray, and white. All objects start as white. Then all root objects, which I explained in 1.8, root objects get colored gray. And then from each gray object, we're gonna traverse the object graph and look at all the references and we're gonna turn those objects gray. Then when we're done, when we marked all the references to this object gray, we turn the original object black. Then we keep going through the tree until all objects are black or white. Okay, now the problem is when we have a black object that refers directly to a white object. So that shouldn't happen, right? Only gray objects should refer to white objects. To solve this problem, we have something called the right barrier. The right barrier just is a barrier for realizing whenever an object creates a reference to another object. So we've put a barrier between you being able to reference an object directly. The right barrier is used to implement what was originally called sunny and shady objects. Now it's called right barrier protected and unprotected. Sunny objects are protected by right barriers. Shady objects are not. And the reason we do this is because with a sunny object, we can track when new references get added to it. Shady objects, we can't. In the generational garbage collector, we have to check shady objects every minor, every garbage collection during minor and major because we can't know whether or not you added a new reference to that object or not. And sunny objects, we know whether or not you did so we can actually promote them to old generation and then not look at them for new references. All right, explain that. So sunny or white right barrier unprotected objects can never become old. They can never be promoted to the old generation. We have to check them during every minor garbage collection. Now, one of the major sources of right barrier unprotected objects are C extensions. If a C extension has direct access to the Ruby object, if it knows where it is in memory, we can't be sure that C extension hasn't added some references or that isn't using that object. So we cannot promote those objects. Right barrier unprotected objects. The right barrier unprotected objects are added to something called the remembered set. The remembered set just contains right barrier unprotected objects and any old generation objects which have a new object added to them which we detect via the right barrier. So if you have like an old, let's say like a big array that you're adding and removing objects from and it's like a stack or something that you use throughout the whole application. So it becomes an old object, okay? When you add a new element to that array, we wanna make sure it doesn't get garbage collected, right? Because if a minor GC marking phase happens, we've added a new object to this old array. That new object, if we didn't have the right barrier would get garbage collected because an old object wouldn't, we don't look at the old objects during this minor GC marking phase. And so that means that our new object is white and so it'll get garbage collected. We don't think that it has any references to it but the right barrier means that when we create that reference, when we add the white new object to the old black array, we will catch that and Ruby says, ah, okay, I will add this old object to the remembered set. So I will check it during the next minor GC. Okay, so now garbage collection looks like this. This is what we had in 2.0 and also 1.9. This, I should say this diagram and the previous diagram are from Koichi's talk about Ruby 2.2 GC. So these are all Koichi's diagrams. This is what we had in 1.9.3 and 2.0. You had a long mark phase and a short lazy sweep when you just swept objects into the free list as you needed them. Then in generational GC, we introduced the two different types of GCs, minor and major. Minor GCs are quicker because there are fewer new objects than there are total objects, right? So you have a short mark phase followed by short sweeps. Once you've done, and then there's major GC, which is the same as it was before. Major GC in Ruby 2.1 and up took exactly the same amount of time that a regular GC did in 2.0 and below just because it's not any different. In fact, it probably took a little bit longer because now you have to keep track of the object age slightly longer, not like anything crazy different. So the whole advantage here is most of the time we're gonna be doing minor GCs. And you can check this yourself. If you look at GC.stat and then you're running Ruby Process, you can see how many minor and major GCs it's done. And usually you'll see minor GCs happen twice as often as major GCs. And sometimes more depending on the age of the process and like what you're doing with it. So that's great. It means we have shorter pause times on average, which means that we're less likely to have some big GC pause during their quest. We still have them though with major GCs because well, this is just the same as it was in 2.0. Is there anything else that I'm missing? I don't think so. Okay, so we still have this problem, right? Of long major GC mark phases. So we'll fix that with incremental GC in 2.2. Again, this is a Koichi project. So the whole idea with incremental GC is well, let's just break up the mark phase. Let's just break the mark phase into shorter bits. And so we can execute Ruby during the pauses in marking. Now there's a lot of problems here because like I said the whole reason it's easier to just stop and not execute Ruby during marking is because then you don't have to keep track of all the stuff that happens in between. When you start adding stuff to arrays that you thought that you marked already but then you gotta keep track of all the stuff that you added to stuff you already marked. That's not good. So total GC time will remain the same. The idea wasn't to make GC time quicker, it was just to reduce the amount of total time we spend in these long pauses. And this is the point where out of band GC becomes not a thing anymore in Ruby. People still somewhat do this, although it's kind of dangerous. Out of band GC was basically the idea that before a request in a web application you could disable the GC with GC.disable or whatever, do your request and response and then enable the GC again. Now that has a lot of problems and it's kind of dicey because what happens if GC doesn't get re-enabled somehow? What happens if during a request you allocate a bajillion objects and now GC is disabled? So well you need a bajillion megs of RAM, right? So it was always kind of a dicey proposition and at this point if we can make mark phases shorter, which means that our maximum pause time for GC ever is gonna be 10, 15 milliseconds, well then what's the point of out of band GC, right? It's just kind of like adding this possible failure point when the maximum GC pause is only 15 seconds. It's not like a huge benefit of moving it out of the request depending on your application and what your goals are or whatever. So, but this is the problem I was talking about is that we can do a mark phase and then execute some more Ruby, but now objects which you've already marked can have new white objects directly referring to them, which isn't good because we don't go back and look at black objects again usually, right? So this just goes back to the right barrier. Now the right barrier in addition to tracking old generation objects which get new references to new objects written, which, sorry, old objects which track references to new objects. Now we just have to do that basically all the time during marking. After a mark phase is over, we check the right barrier for objects which got new references to them. So it just adds other things to the remembered set. You can check the size of the remembered set in GC.stat. Again, I recommend just taking a look at this. It's kind of opaque. Like the keys are a little bit hard to figure out what they mean and GC.stat changes a lot. It changes in every Ruby version pretty much. So, but you can get an idea the remembered objects is sort of like just right in there. And it'll also tell you like how many objects are protected by the right barrier and how many are not. From a practical perspective, the right barrier now is so important after 2.2 for incremental and generational GC. What you might have caught is that this means that C extensions which touch or make shady or basically remove the right barrier from large numbers of objects that could be really bad, right? Because the more objects which are not protected by the right barrier, the more objects we have to check every minor GC which isn't the idea. We're trying to make minor GCs as short as possible. So I've never seen this happen in production because I don't know of any C extension that does it but it would be interesting because that bug is kind of possible where a C extension touches tons of Ruby objects, makes them shady slash right barrier unprotected and suddenly your minor GC pauses are just as long as your majors and you've lost the benefit of generational and incremental GC. Kind of interesting. Symbol GC, we also got that in 2.2. It's not really that complicated. Now symbols are garbage collected too. 2.3, not much changed. That was 2.2 was kind of like the last major change to the garbage collector that we've gotten. Kouichi introduced a new experimental right barrier in 2.3 which his assumption was that we can assume new objects referred to from old objects are probably also long-lived objects. So if we add a new object to an old generation object, we're gonna assume that this new object will probably become an old object. It's probably gonna stick around for a while. So for example, adding a item to an array in a config file, right? So if you, I can only give like really specific century examples, but changing the setting in a config, right? You're creating a new object, you add it to your config object. That object's gonna stick around for a while and it would be better if we just made it old right away. Cause if we made it old right away, it doesn't have to be marked for three minor GCs and we could just ignore it until the next major. The problem with this is, well what happens if that object isn't, you know, it is not going to become an old object. So if you have like my stack example from earlier, if you have some stack object in your application that you're constantly taking items in and out of with this new algorithm that any object added to your long living stack would automatically get marked in the old generation. So that wouldn't be great cause you're taking stuff in and out of it all the time. So that would greatly increase the memory usage of your stack. I guess this experiment didn't work or he didn't like the results because it's still commented out in the rubygc.c code. It's still in there. I don't know what he ended up thinking about it but it's not been enabled yet. You can mess with it if you know how to compile ruby and want to comment it out or whatever but kind of interesting. 2.4, we got a couple more little changes. You now can control somewhat the amount of three slots ruby tries to keep open. So the whole idea with GC and when it triggers and how many slots and how often we want it to trigger is that GC is expensive, takes time. We don't want to do it that often. So when we do do it, we're going to try to make sure we don't have to do it very often again. So what ruby does is let's say you have a million free slots and you have to garbage collect.  Everything is being used up. So we still have a million slots but we need more room. Ruby will grow the amount of slots by a factor. And that factor I think by default now is 1.4. So with a million free slots, if we need more slots we're going to grow to a 1.4 million slot heap. That factor is configurable by an environment variable. But let's say we get to 1.4 million, whatever and then five minutes later we GC again and now we're only using 500,000 of our 1.4 million slots. Well, that's kind of inefficient, right? We should return some of that space back to the operating system if we can. And that is what that control over that ratio of what ratio between used and empty slots is now configurable I should say in Ruby 2.4 by an environment variable. These environment variables, I talk about them sometimes in talks but I tell people not to touch them usually. If you can find them in GC.C you're probably also smart enough to figure out what exactly they do. It's very easy to cripple a Ruby process if you just copy and paste someone else's settings for these things. So I don't even tell people where to find them or how to look at them. But if you can find them in GC.C you can probably figure out how to use them. But this is an interesting one because one thing that I see a lot in production with Ruby processes is they get in their steady state. Where am I at? Okay. In their long-term steady state after six hours or whatever they have too many free slots. And they're not returning those free slots back if they can. Which means a long-term higher memory usage, right? So I've been interested in this. I haven't played with it yet to see if it reduces long-term memory usage for people's real applications. Part of the problem with returning free slots back to the operating system, and I've talked about this in other talks is memory fragmentation. Ruby can only release a slot back to the operating system if the entire heat page, so 400 slots in the page have to all be free. That's called a tomb page if you see that referred to anywhere in Ruby. A heat page with an object in it is an Eden page and a page with no objects in it is a tomb page. So page has to be a tomb page for us to release it back to the operating system because we can't move objects around the heap. Because we don't see see right-barrier unprotected objects, right? These are referred to by C extensions. They have just the direct memory address. There's no indirection between that C API access and where that object resides in memory so we can't move the object. Otherwise we'd break the C extension. So that means we can't move objects around and which in turn means we can't free pages back unless there's no slots. Being used in the page, which happens about never.  There's a couple of things which are being done to help with this. So let's talk about those. Now we can talk about the future about where Ruby GC seems to be going. And the main thing I think that most people are gonna be interested in is garbage compaction which is moving objects around the object space and moving them around the heap to make them less Swiss cheesy and more griere. I don't know, it looks like not cheesy about holes in it, I don't know. J Ruby and Truffle Ruby already do this because they're on the JVM or Grawl or whatever and those garbage collectors are compacting or at least some of the JVM garbage collectors compact. So they get to take advantage of all that for free and it just compacts for them and that's great. Aaron Patterson has been working on this after a hallway conversation in Ruby Comp he realized that basically we might be able to move some objects around the heap so long as we don't have any, we can make sure that they're not being referred to by C-Extensions and he's been working on that if you follow his Twitter, he's been posting about it every once in a while. It's a very interesting project. It will never be able to move all objects around the heap but we might be able to move some of them and improve fragmentation and being able to return some memory back to the operating system somewhat. So what this means in the long term is that your big long term Ruby processes will probably use somewhat less RSS or memory in the long term. Another approach here besides being able to move objects around is to just put them in separate areas to begin with. So if we have an object and we need to put that object somewhere, right? If we think that this object is probably going to be old and it's probably gonna stick around we're gonna put that in one pile and then any object like an instance variable that we think is not going to be around for a long time we'll put that in another pile. And in theory what that means is our old object pile will be less fragmented than our new object pile, right?  So that should reduce memory fragmentation and therefore less total RSS usage. Guilds, so everyone talks about guilds probably not coming for a while but I was told Ruby 2.6 or 2.7. So guilds will be sharing the same object space in the plan right now. I mean this is all super early, whatever but guilds are Ruby's future plan concurrency model if you're not familiar with this. But the idea is that these guilds are gonna be sort of like lightweight processes almost and they will share the same heap.  I did sort of an interesting side note. For more reading, I suggest these three authors, Pat Shaughnessy wrote a great book called Ruby Under the Microscope which is the starting point if you wanna learn more about how Ruby works internally. Koichi has written a couple things online in English about how Ruby Garbage Collection works and Sam Saffron of Discourse has as well. If this was interesting to you, I have a course called the Complete Guide to Rails Performance which is a bunch of screencasts and a very long book about optimizing rails applications. It's all at railspeed.com. You may have seen my blog, it kinda looks like this. I write about Ruby performance from time to time and that blog is at speedshop.co. Thank you very much. We have more than five minutes for questions. Yeah. Container space, containers, containers, containers. Everyone's talking about containers. Where do you see Ruby, not just in general, Rails, Ruby, Rails fitting in within the container space because I just tend to say, just put it into container. Don't worry about it, put it into container. Well, that's pretty much what everyone does already because, yeah, sure, sure. So the question was like, how do I see Ruby fitting into containers? I think the fact is that most people run Ruby in a container already because most people run Ruby on Heroku which uses LXC, where do Terrence go? Yeah, well, Terrence is, who's giving me a talk next could maybe even say a little bit more about it, but Heroku uses LXC, I think, which is containers and so it's really not or hypervisor or whatever. So I don't see a lot of people running Ruby on Docker yet, but most people are running Ruby already in a containerized environment whether they realize it or not, or depending on your definition of container. I think what's interesting and what kind of relates back to this talk is that most people running in these environments tend to run them in very resource constrained environments and memory is usually constrained in these environments. You know, like the default Heroku Dino size, right? It's like 512 megabytes, which is enough for like half a Rails process. So I think people's memory knowledge is important for being able to shove big old legacy Rails applications into small containers, but increasingly I'm starting to think that CPU is also an extremely important thing in these environments. Like Amazon's VCPUs are just hyper threads. So like, you can have like eight gigabytes of RAM and then get like two hyper threads. So that's like nothing, you know, you can run like 1.5 Puma processes on that. So I gotta do some benchmarking and look at this more, but like memory is a very important constraint and understanding how it works and when GC occurs is gonna help you with shoving stuff into these small containers, but CPU is also an increasingly scarce resource in the cloud, I guess. Yes? So there's two things that Ruby's done over the years to improve GC. One is all the stuff you talked about and the other has been trying to not allocate objects to begin with like, like flow nums so that there are no other objects that are tracked by the GC. But then there was also set throws and string literal. So I was curious if you have any experience with how much library is changing to use that as reduced memory. Yeah, so the question is like, we've also, the other side, the flip side, which I didn't talk about of trying to reduce GC and memory pressure is just don't allocate new objects in the first place. So the example was pushing frozen string literals. So I think, was it 2.2? We got the magic comment at the top of the file that was frozen string literal or you could just make the whole file. Sorry? 2.3. 2.3, okay. We got the dot freeze and 2.3. Oh, okay. So that frozen string literal and the dot freeze or whatever, right, was intended so that we freeze an object so it's just not garbage collected, right?  So I was also interested in that. I actually asked Kouishi about frozen string literal, the magic comment at RubyConf. And because I think part of the original promise of the magic comment was that you would, that they were thinking about making that core language feature that just all strings would all be frozen. And so it was sort of an experiment to put in the runtime to see like, okay, does that actually make people's applications faster? Kouishi feels, and I also sort of feel that that hasn't really been a huge performance impact. Just either not enough stuff can be frozen or when you do freeze stuff, you end up creating new strings anyway to create the copy or whatever.  So I haven't seen any real world benefit, major real world benefit from that. And it doesn't seem like it's gonna change or become like that path where we're at right now with freezing objects. Doesn't seem like it's gonna change to me so much in the future. I asked him that in the context of guilds, right? Because the whole thing with guilds is we can share frozen objects between guilds. We know they're not gonna be modified, right? So we can share these frozen objects between the different processes without fear of modification. So I said, well, you know, isn't that when we wanna create more shared objects then? And I guess Kouishi feels that that's the way that it is currently is adequate, I guess. Yeah. About locality, I mean that objects that are allocated nearly at the same time often also will be used nearly at the same time. Sweep is, mark and sweep is known for destroying locality. For the compaction, are you considering algorithm which preserve locality or like the Morris algorithm which also destroys locality? Yeah, so I am not a Ruby core developer. I've never committed to Ruby, actually, I don't think, yeah. So the person you have to ask is Aaron Patterson because he's the one doing all the work in compaction in C Ruby right now. So if you just Google Aaron Patterson Ruby and you'll find him, he's hard to miss. Yeah. I think that that's kind of like what has been talked about with putting objects in an old heap and a new heap, that the new heap, you're preserving locality that way, I guess. But that's kind of outside my area of expertise to be honest. Yeah. Two minutes from question. Is it really interesting to make the GC learn to adapt to the application? Because we have one like one to fit them all and for instance the 1.4 ratio you were talking about. Yeah. Stuff like this could benefit from the GC learning from how it works with a specific application. Yeah. The question was how can we make the GC learn how to perform based on how to make decisions based on the actual application performance. What do you think? I don't really think there's anything in GC.C right now I think that could be described as doing that. I think all the important knobs really are set by environment variables beforehand. One thing that Ruby GC does do is these thresholds like for increasing the heap size do change because it's like based on a ratio, right? Like 1.4 is a ratio of the current heap slots used. There's also ways to cap that. Like you can say 1.4 or 300,000 heap slots whichever is less. So there's some changes in these thresholds as the application executes but I wouldn't describe it as the run time learning about itself. I think that's interesting because one of the problems that MRI core maintainers have is, Rails long running Rails processes have like one very specific set of behavior and then there's people that still use Ruby for 10 line sysadmin scripts and then someone comes into that, someone comes into the discussion and says, hey, wait a second, you can't do that because you're going to break my 64 megabytes of RAM, Raspberry Pi, whatever, like some crazy environment that they run Ruby on. Ruby has to cater to all these use cases. Yeah, and so there's just so many different ways that you can run Ruby that it's difficult for a core language maintainer to make aggressive decisions for one workload or another workload. So that's an interesting path forward. As far as I know, nothing has really been done on that front yet. Thank you Nate.


Freddy Krueger, what's up? What is toilet bruh? Okay, what the heck is going on here?  That is freaking weird. I think I just lost some brain cells watching this YouTube what's going on man? And today we're here.  Let's begin. Okay, this is by mini HP Skibbity toilet boss versus Titan camera man skibbity toilet versus camera man animation. Oh This looks like pretty clean Oh the camera man just punched him.    Oh Do you stomp them inside the toilet? Boom Okay, this is getting an epic. Oh No, he caught the baby Okay, what camera is that like a cannon Squeeze his head and popped it.  Oh Is it like this is it Titan? Oh, I got a rise shield. What? Oh Oh That was epic. Oh It's the boss give you the toilet versus Titan camera man zap them right into the toilet. Oh, he says site. Oh What dude what it just ended like that?  It's us.  This is getting intense man. I'm like object out, bro You got like attachments all that to be continued. No, I should have known it was getting too good Man, it was gonna come to an end right next. We got mini crewmate kills skibbity toilet, but what box character? Oh That boy Oh, he's out Stopping the name of love This song so catchy That was genius you distracted him with the music so he was able to flush him But then they got bamboozled by the giant skibbity toilet at the end All right, next we got mini crewmate skills kills skibbity toilet characters part two I think this is continuing off the other part that we seen at first. I'm not sure I know it's not Mario what?  We went down the pipeline. He's got four eyes Of his egg they were supposed to be eggs because of waffles legalized nuclear bombs.  I'll know the toilet Bro, he was an ambassador This guy's himself at the toilet. Oh That's not good. Oh to be continued once again And for our final video we got mini crewmate kills creepy skibbity toilet characters I think this is part one actually to the one we just seen. I don't freaking know. Let's just watch it. Oh It's a shotgun Dude, they should make a game like this I would totally play it like a mobile game He tripped on sorry to ooh slo-mo No the gun jams.  Watch it.  Well, there we have it skibbity toilets.


Hi, this is Julie from New Horizons one two three dot com I'm excited to be able to share with you that YouTube has rolled out the ability to link a YouTube short to a Related long-form video as some of you might know they took away the ability to use clickable links in YouTube shorts comments and Description and that was because of there was a lot of spam going on but now they put the ability to link to a long-form video right in there in the Studio section of your YouTube short so look for a clickable link inside this video that will take you to a tutorial To show you exactly how to do it. Enjoy


All right. Good afternoon everyone. Thank you so much for coming today. We are going to begin our press conference momentarily. Our speakers are on their way out. Okay. Thank you. If everyone could just please take your seats. Good afternoon everybody. Thanks for coming out. My name is Jeff DeMers and I'm the state refugee coordinator for the Texas office for refugees. We're honored for the opportunity to highlight the tremendous ways that our partner agencies have stepped up to serve the Afghan allies and guests who have overcome so much to resettle here in the state of Texas. The capacity required to meaningfully engage with and serve this population is dynamic and demanding and the partner agencies in our state are taking a collaboratively coordinated approach. Through the 24 direct service agencies in Texas, including six here in the greater Houston area, we aim to innovate and serve by engaging directly with clients and developing solutions alongside our partners and those they serve every day. Afghan guests will strategically receive client-centered supports including empowering case management, employment, and educational programs that emphasize self-sufficiency and take a thoughtfully holistic approach to the entire family. One of the immediate needs of so many of our Afghan guests is shelter and the innovations taking place to develop public-private partnerships between agencies and companies in this area to provide space has been crucial to the process. We're so inspired by the willingness and dedication the partner agencies in Houston and across the state have demonstrated and want to celebrate them today. The work being done is truly an incredible example of hard work, compassion, and collaboration. Success depends on all of us coming together to identify needs and opportunities to create solutions with, above, and beyond our communities. We are so grateful for our partners, the city of Houston and Texans for making that possible. And now I'd like to pass it over to Congresswoman Sheila Jackson Lee to say a few words. Well, you can give him an applause. I feel so much at home for this very special occasion. And it gives me great privilege to welcome the state, the White House and the federal government in the form of an outstanding governor, and of course to salute the CEO of this great city who sets the tone out there. I'm very pleased to be with him, and then very pleased to be with Combined Arms, that there's somebody getting ready to wake up to be able to just personally thank them for being such an asset to our nation and to the world. Thank you so very, very much. I told Martin and the governor that I'm at home, the mayor knows because I served on then Houston Metropolitan Ministries, now Interfaith Ministries Board, and then I had the privilege of being the chairwoman or president of the board. What a privilege, but as well to scounce myself, to immerse myself with the outstanding work of refugee resettlement that is decades old in this organization. And now look at the many partners and friends that are in the room. And so I'm gratified to be here, will not tell you the tall tale of up to ensure that the continued resolution was passed and the early morning will be pronounced refugee resettlement. It was an early morning flight to ensure before dawn that I was able to get here. And I just want to say these words and thank you. One, I feel extra at home because I can say that I know Reverend Dr. William A. Lawson. You look over and you see the wonderful spirits. I know Bishop Fragonza and of course new Rabbi Karpf. They set the tone for who all of us in our own spirits of giving are. We all know that it is better to give than receive. We all know that the expansion of humanity goes beyond our front door and our backyard. And so to each of you that are here, I know that you're part of showing the world the best of America, but most importantly, the best of this eclectic, international and loving city. The privilege I have of representing a large portion of it and for me to be able to say thank you and to commit to you under the leadership of this gigantic and wonderful team. I would like to thank the mayor of America from Delaware, who has been chosen by the president to lead this great effort, that we will stand by your side as the chair of the Congressional Afghan Caucus in the United States Congress, of which I've served on now for almost two decades plus since the war in Afghanistan, having spent time in Afghanistan over several years knowing how wonderful the people are Thursday they are for democracy and freedom, how much they want for their families, their boys and girls. And here we are in Texas on the map for being one of the states with the largest population of refugees, 5,000 plus, and our city being a star, a shining star. So thank you to the YMCA, the Alliance, Catholic Charities, Refugee Services of Texas, and of course Interfaith Ministries. Thank you to the Houston Endowment, Kinder Foundation, and of course the Chow Foundation, part of a $3.7 million private philanthropy fund. And we are right alongside of you. Governor, are you announcing that number? Since we really stayed up all night to get it done, I'm going to share the credit, but the $7 billion that the United States Congress has just given to you in the last 24 hours, I believe it is going to be well placed across America for the heroes and sheroes that extended themselves when our best and our most precious were on the front lines fighting for democracy in Afghanistan. And then to be able to welcome hardworking families to say to them that our door of humanity is always open. Those dollars will be well invested and well spent, and we'll show the world what the true character of America is all about. My promise to each and every one is to keep our doors open, our bipartisan doors open, because that's what America is. It is a pot that has many, but we're so delighted that we come to be one when we share and give and tell the world who we are. I'm delighted to be able to be here. I congratulate each and every one, and it is my privilege, I believe, or will you do it? I'm going to do it. It's my privilege. We wouldn't be in this way. We didn't have an enduring person who is serving as the mayor of the city of Houston. It has been proclaimed by the governor. We're going to take it as the most international. He went to one part of town, but I'm claiming the whole city as the most international and loving city. But it takes a CEO, a captain, a general to set the tone, and that is what Sylvester Turner has done. He is a people's mayor, and he leads us to our better angels. Ladies and gentlemen, the mayor of the city of Houston, Mayor Sylvester Turner. Let me start off by thanking the congresswoman. She's way too generous with her remarks, so certainly thank Congresswoman Sheila Jackson-Lay. Let me also quickly echo the sentiments of so many others, and thank her and the members of Congress for what they did in the wee hours of the morning. That $7 billion will go well for the resettlement program, so please give it up again to congresswoman Sheila Jackson-Lay. Governor Marco, we call on her time and time again, and time and time again she comes up and she comes to our rescue, so we really appreciate that. And then I'm certainly honored to welcome you personally to the city of Houston, and hope your stay has already been enjoyable and for your stay the rest of the day. So thank you for being here. And then I also want to acknowledge and thank all of the partners, every single one that has stepped up from day one to make sure that the resources were made available. Families were taken care of, truly showing the spirit of this city. So let me thank you all so very, very much from the depths of my heart. Governor Marco, congratulations on your new role as the White House coordinator for Operation Allies. Welcome, and I look forward to working with you along with so many others in our city. I know the challenge is great, but with your leadership I'm confident that you will help our nation succeed and help and support our Afghan allies. I want to acknowledge and thank the Alliance, the Bilingual Education Institute, Catholic Charities of the Archdiocese of Galveston, Houston Interfaith Ministries for Greater Houston, Refugee Services of Texas, the YMCA of Greater Houston, Combined Arms, and so many others for stepping up to help us resettle our Afghan allies. As the most internationally diverse city in the country, and I mean the most diverse, Houston has had a long history of being a welcoming city for refugees. Over a quarter of our population was born in another country. We speak more than 145 different languages. You went to lunch in one of the, if not the most diverse area, not only in the city in the state, but in the country. I think what you went to lunch over 100 different languages are spoken in that area long. Over a quarter of our population was born in another country. Governor, if there's one thing that I know I would like for you to take away from this visit. I hope that you will see the amazing work these organizations have been doing to make Houston home for our new Afghan neighbors. Since the very beginning, they came together and started planning on how they would receive our Afghan allies. They did an outstanding job at working with the city of Houston and my office of New Americans to make sure the city was always informed of their efforts and all of their activities. We offered our support and applauded their success. Houston is an example of what a welcoming city should be, and I underscore that a welcoming city. Whether it was opening our city in the past to help people from other states whose homes were devastated by Hurricane Katrina or helping asylum seekers from Central America and Haiti or welcoming our Afghan allies, Houstonians have always been there to lend a helping hand. And no matter what challenges the future may hold, we will always be a welcoming city to those in need. It matters not whether they were born, where they were born, where they live, what language they speak, whether they're documented or undocumented. I just happen to be their mayor and I'm proud of it. In fact, on Tuesday, December 7th, I will join with our partner organizations who are with us today to officially welcome our Afghan allies to our city. In closing, I also want to encourage all Houstonians to do their part to support these organizations in their work to help our new allies resettle in their new homes. Remember, for many of us at one point in time, maybe our grandparents, our parents, those before us came from some other place. But when we came here, we found a welcoming community. Houston will be measured, but not by so much we do for those who are here, but how we extend a helping hand for those who find themselves in need, come to a place they've never been before, but they find welcoming smiles, a hello, and people that are graciously extending a helping hand. That is what Houston is, that is who Houston is, and that is what we know people will find when they come to our city. So welcome aboard. I wish I had a cowboy hat to give you and a cowboy boots, but you'll have to come back in February to get that during the Houston Life Stock Show in Rodeo. Thank you. You can do better than that for a great city. When you clap for the mayor, I wanted to take one moment, just as Governor Merkel comes up, to indicate that I teach my grandchildren and everyone brags about grandchildren. It's better to give than receive, but then as I stood there, I looked at the word respect in many languages, Martin. And I want you to know of the respect that we have and that Governor Merkel has gained or did gain in his service as Governor of Delaware. And that respect was mutual between our President Joe Biden and our Vice President, but our President had known him for a very long time. And when I stood up and took credit for $7 billion, it should be that it was cooperative and collaborative because of the heart of President Joe Biden, who said, let us do the right thing, let us set up a great team, which I met under Governor Merkel, and let us show who we are. And I'm glad that we as members of Congress accepted that hand of friendship so that we now have this institution, but we have a man who has been respected and has lived his leadership as a public servant in the view of respect. And I'm delighted to say thank you for accepting the President's call. And I want to say to the President of the United States, thank you for the kind of heart you have where you want to show what America really is. And he will continue to do that along with our Vice President, Vice President Kamala Harris. So Governor, you're with a good team. Make sure you tell them that we thank them for the great work and the person they've chosen to do this job. Governor Merkel of Delaware. But you can come and fill in, brother. Come right in. Well, thank you, Congresswoman and Mayor. And I have to say, I appreciate your mentioning the President in addition to being a man of a big heart. He is a very good politician. And if he were here, he would be whispering in my ear and say, you should be yielding back your time to the Congresswoman and Mayor because they are such articulate spokespeople for this issue. You know, it is just so great to be in Houston. And I've learned in life that everything starts with great leadership. And there's a reason that Texas is leading the nation when it comes to resettling our allies from Afghanistan. And there's a reason that Houston is leading in Texas. And it starts with extraordinary leadership. There's no substitute for having elected officials to have your member of Congress as the chair of the Afghan Caucus and of the Pakistan Caucus is truly a remarkable thing to have a mayor. We spoke a few months ago, a few weeks ago when I called the mayor to tell him a number of Afghans were coming his way. You just could not have been more supportive. You could not have been more excited and you could not have been more welcoming. And I just want to thank the two of you so much for that leadership. We've had an incredible day here. I do want to give a special shout out to your state refugee coordinator, Jeff Dammers, who is just doing an amazing, amazing job. Yes. And we have had the chance to meet today with the resettlement agencies, with the Alliance. You have something here which is truly remarkable. The level of collaboration that we are seeing amongst the resettlement agencies, amongst the resettlement agencies and the veterans community with your philanthropists. And the Congress will mention some of the philanthropists who have contributed to this remarkable fund that is helping to support the resettlement of our allies from Afghanistan. This is all incredibly intentional and it's very difficult, but the fact that you are achieving so much success is not by accident. In large part I think it's the fact that you have people in positions of leadership, not only in government, but in the civil sector, in these resettlement agencies who understand the field, they know each other, they've been working together for years, they trust each other. Earlier this morning we sat, they were all seated next to each other and in some communities they might even see themselves as competitors because they're all seeking funding from the same organizations. But in this case, Martin, to you and your colleagues, your peers who are here today, the level of collaboration and commitment is just something really special and remarkable to see. As the Congresswoman mentioned, as the Mayor mentioned, President Biden asked me a few months ago to take this role as the White House Coordinator for Operation Allies Welcome. And he was very clear, he said his expectation was that we would provide a safe and dignified welcome to our allies from Afghanistan and he asked me to lead not just a whole of U.S. government effort, but a whole of America welcome and that is exactly what we are seeing. It has been truly inspirational in a number of communities across the country and certainly right here in Houston to see how welcoming you are and I give so much of the credit honestly to our veterans because across the country they have been the most, yes, that they deserve that. They have been the most credible and the most authentic and the most powerful voice because they served with these folks in Afghanistan. These folks in Afghanistan were by our side and so when our veterans tell us that it's our obligation to provide this safe and dignified welcome, we hear it, we don't hear it because we're blue, we don't hear it because we're red, we hear it because we're Americans and we are all in this together and the Congresswoman mentioned a moment to go, the bipartisan nature of so much of this work and I think what a great example right here in Texas and we are so grateful to all of you. I had a chance earlier this morning with my team to meet a newly arrived Afghan family and to hear their story, to hear about their life in Afghanistan, to hear about getting out from the airport and their time in transit and their message is I've heard this all over the country when we asked about what is it that they wanted to make sure we most heard from them. It was about their sense of gratitude. They have a one year old child and their belief and their optimism that that one year old is going to grow up in a safe, welcoming environment where he will be able to go as far as his potential will take him and I'm highly confident that this generation of Afghans, our new neighbors, are going to bring new ideas and fresh energy and fresh perspective to this country as generations of immigrants have done before and as clearly so many have come to Houston to live out their lives and to build their great American lives right here at home and with the help of all of these incredible partners I have no doubt that that family like so many others are going to be successful. One of the things we are particularly focused on is how we understand the need to put folks on a path to self-sufficiency as quickly as possible. So the folks from Afghanistan who are coming here to Houston are fortunate and that your job market is so great in large part because of your civic leadership, your government leadership and of course your business leadership as well. So be sure if you would to reach out to the resettlement agencies if your business or a business that you know is interested in hiring our allies from Afghanistan from you know highly skilled folks who speak English really really well to folks who need to learn English but who can do other kinds of jobs. The idea of making sure we provide a good welcome, one of the things we've heard over and over again from folks who have been here for a while is the fact that when they came here they felt welcomed into their communities, into their neighborhoods and it makes such a difference as they go about the hard work frankly of building new lives. So anything that we can do to provide that welcome and for those of you who are interested in how to do that reach out to the resettlement agencies here in Houston. They're doing a remarkable job under really difficult circumstances but you can help as a volunteer, they need more volunteers whether it's to pick up people at the airport to get kids connected to school or to be a friend who brings over a hot meal. These are all things that we take for granted but that are so incredibly important. So to the mayor and Congresswoman, thank you so much for allowing us not only to come to Houston but to providing such a warm welcome and to all the partners that we've met throughout the day. Thanks for the extraordinary work that you are doing and I think it's very fitting that the last speaker is a veteran. I mentioned earlier and I have seen this all over the country. Our veterans have taken the leadership role when it comes to making sure that all of us provide the warm welcome that we owe to our Afghans. So the CEO of Combined Arms, Mike Hutchings, we had a chance to meet with him and his team members a few minutes ago and Mike come on up to the podium. Thank you. It's funny, in 2012 I had the pleasure of leading a rifle platoon of United States Army soldiers over grape rows in fields fighting the Taliban on a daily basis. And if you had told my 2012 self that I would have the opportunity to stand beside such leaders for our nation, I would have told you you were crazy. So thank you all, everything for the support you have for our Afghan allies, I appreciate it. So Governor Markel, Congresswoman Jackson Lee, Mayor Turner, Demers, it's an honor to be here today and to discuss the needs of the Afghan wartime allies with you all. After the fall of Afghanistan it was astonishing to see hundreds of veteran nonprofits and refugee agencies come together across the nation and around the world to work with the federal government and provide support for the Afghan people. I'm honored to be a part of a veteran organization that's leading extraordinary work here in Texas to help with the resettlement of Afghanistan's. For years Combined Arms has been supporting the Afghan community in addition to our primary mission of connecting veterans and military families to life changing resources through our state of the art technology. For us at Combined Arms this is more than personal and it's seen as our moral obligation. 50% of the Combined Arms staff are veterans and we know firsthand the sacrifices of the Afghan people. We've stood amongst giants in Afghanistan, US service members, Afghan armed forces, frontline civilians, combat interpreters alike. The Afghan community are our brothers and sisters and Combined Arms is committed to the current and ongoing support of those who serve beside us. We look forward to increased interagency and public-private collaboration to ensure the Afghan community will feel comfortable calling America their home. There's an opportunity in front of all of us right now and it's the opportunity to come together as one cohesive effort to stand united and to provide security, stability, and the potential for success to the Afghan people. Thank you. Gentlemen, we have time for about one to two questions and then I'm going to ask all of our speakers to stay here and ask all of our agency CEOs to come forward. Is there a question in the audience? Elizabeth Troval. So the question is what I've learned about the experiences of our Afghan allies as they resettle here in Houston and across the country. So first of all, I mean the main reaction that I've gotten is one of gratitude for the welcome from everybody from the president on down to local communities. And this despite the fact that obviously these have been, it's really difficult to take your family to a place where you've never been before. Perhaps some of the family members don't speak the language. So I think what strikes me and as I mentioned earlier, it's good they're here at a time which is great for the job market. It's really difficult that they're here at a difficult time for the housing market. So the work that the resettlement agencies and the state refugee coordinator and others are doing to provide to find housing for them. This is really hard work, but they're doing it really, really well and our allies from Afghanistan are grateful. And I think what they feel most grateful for is that they feel welcome, that they're wanted. And imagine how difficult it would be if they didn't feel wanted. You know, in the past we have had, you know, other groups of immigrants who have not been wanted. And so I am particularly grateful. Again, I really, oh, it's not exclusively about the veterans, but I think the veterans send the message to the rest of us about how important this is. And when our veterans speak, it's like EF Hutton, people listen. Probably you're too young to know that reference. You know it, good. But so anyway, I think they feel like people are very anxious to get to work. They're anxious to get their kids in school. They're anxious to make new bonds in the community. And so they're raring to go. Welcome. Do we have one more question? Yes, Richard. Louder, Richard, I'm sorry. Well, let me say that the administration and many members of Congress are united on wanting success for Afghanistan in the world family. At the same time, we are aware that what we planted there, the seeds of democracy, people who are in Afghanistan are still hungry for what the United States created. It is not the look of how we left. It is really the look of what we left. And it was in the minds of Afghans through our veterans and others that democracy is something they love, they want, and they don't want to be denied. So the idea of funding is one where we want to be sure that the dollars, humanitarian dollars are used for the Afghan people and their needs. Not as a sense of punishment, but certainly to recognize that it is the people that we want to give to. So we know that they are receiving dollars from other in the Southeast Asia region. We know that Pakistan is very interested in creating a dialogue and continuing to be there for the United States in a dialogue. India is in the region, Bangladesh is in the region. The region has its challenges. But I can assure you that what we want is best for a government that will respect the desires of its people. And we hope to give the Taliban through the United Nations as much help as possible. But we also want to recognize the needs of the Afghan people that are there. And I think you will find out that the Biden Administration is continuing to work on those that our veterans are working with that want to leave. And we want to make sure the Taliban allows them to safely leave. All of that goes into how we craft a policy that recognizes Afghanistan and the people who are there as well as the need for Afghanistan and its leadership to become part of the world family. And that is to provide human dignity for all those within its boundaries and for all those who may desire to leave. Thank you so much. Thank you to all of our speakers. Thank you so much. Right now we're going to transition into our listening session, which is going to start in about five minutes. So we'll end the press conference. I'm going to ask all of our agency CEOs to please step forward now for photography. If you're registered for the listening session and you have a yellow armband, please proceed into the Great Hall. Our staff in the back will get you into the Great Hall. Thank you so much.


What's up guys, I'm Michael and welcome to my YouTube channel today. We're gonna do another leech code challenge is gonna be called Deviser game Alice and Bob takes turns to playing a game with Alice playing starting first initially There's a number on the chalkboard on each player's turn that no purse that player makes a move consisting of choosing any number between 0 and n and And mod x is equal to 0 then replace the number and on the chalkboard with n minus x Also, if a player cannot make a move They lose a game Return true if and only if Alice wins a game assuming both players play optimally So originally what I did was I just had a Boolean to return equal to true Whoops my bed And I have my index starting at I equals 0 what I did was while the n is greater than 0 I looped through all the numbers between 1 and n and if the value Mod whatever numbers between 1 and n mod n is equal to 0 and mod a equals 0 Then I then I exit out of this loop and then what I'm gonna do is I Check it again. If n mod I is equal to 0 then I subtract I from n then I said to return equal to not to return to Flip it and then otherwise I break in the end I return true. I return to return if it's true or false but if you realize this shitty this this stupid question is that basically if it's an even number choosing any x with zero between 0 and n They basically just checking if it's even to you guys understand why because If it's even and you subtract 2 from it effects is if x is 2 and you mod a equal to 0 If you subtract 2 from it and it's even then you could divide by 2 again And that would be it would be divisible by 2 again so like if I take 8 and 8 is divided by 2 visible by 2 I get 4 right if I subtract 2 from 8 Six six will be divided by 2 again and over and over again.  Run the code Hold up. What is going on? I forgot this run the code And it passes Let's submit it again And it passes so basically that that's all you had to do.   Hope you guys enjoy this video


This is the exact stand-up I had for Brandon's show the last time, you know. Are you just wondering about this?