Conor

You know, scatter gather, are they good names? And I was thinking alternative names are index copy to and index copy from. I'm not actually sure which I like the most, because index copy to versus from, the only thing you have to delineate the difference between those two is the fact that you're copying to an index versus copying from an index. Those are good names for it, by the way. I kept on saying integer sequence, yada yada counts and offsets. Very nice names.

Bryce

Yeah, not names that I picked, names that the AI picked. Let us all bow down to the machine gods that rule us. Yeah, the machine gods that rule us, where we can't even find the chat that I had two days ago.

Conor

Welcome to ADSP The Podcast, episode 257, recorded on September 23rd, 2025. My name is Connor, and today with my co-host Bryce, we record live one day before NDC Tech Town in Kongsberg, Norway. In today's episode, we continue our discussion of the replicate algorithm as well as scatter, gather, run length decode, and more. Alright, folks, we're back. It's been it's been a minute. Last time you heard from us, where were we, Bryce? We were on the He doesn't remember. He's he's in the car? No, that was two episodes ago, Bryce. God. Admittedly, it's been a long two days for us. We just finished two. No one can hear you right now. You forgot how this worked, buddy. You gotta wait till the mic is in front of your mouth. Last time we talked to you, we were walking on the streets of Copenhagen. I think we just left you when we were about to get ice cream. Let's first do a review of the Copenhagen soft serve. How or yeah, you got soft serve as well. How was it, Bryce?

Bryce

Well, I gotta say, given that I didn't remember it until a moment ago, I don't think it was the most memorable thing. But I did have a wonder wonderful dinner at this restaurant here called Neela, which uh is Yeah, the Indian place. The Indian place who uh it's uh it's a a master chef uh winner, or she got came in third or whatever for master chef. Winner third. But it was an excellent meal, and Connor bailed out on me. Connor and Ashwin bailed out on me after uh two days of uh of uh training. We tried we taught people the coup to Caught people the coup to Python. Now I gotta give one more talk and then I get to go home.

Conor

See, I apologize on behalf of Bryce Folks. He doesn't understand how podcasting works. He just started explaining to you the meal he had tonight, and it is now officially 48 hours later, we're in a different country, we're in a different city. What? No, uh last last time we recorded was uh well actually that's true. It's been 72 hours. Last time we recorded was Saturday. We were traveling on Sunday. Guess what, folks? I mean, let's go chronologically. So the last we left you, we were having ice cream, we went to sleep, we woke up, we were in transit. What you want to tell them about the train?

Bryce

I do.

Conor

Wait, we're not at the train yet. We because what happened before the train?

Bryce

We were on a plane.

Conor

We were on a plane, and who did we run into on the plane?

Bryce

We ran into Jason Turner on the plane. Not just Jason.

Conor

Jason and his partner Jen. It was lovely to see them. Haven't seen them in, I think, close to a year. Bryce is just chomping at the bit to get this mic.

Bryce

More importantly, Connor was napping on the plane, and I got photos, folks, and they're going all over the internet.

Conor

I'm allowed to nap, folks. I was tired. It uh I was tired.

Bryce

It was It was It was a 1055 flight. There was no reason to be tired.

Conor

Actually, folks, there was a reason to be tired. I had to make a game time decision. Did I run in Copenhagen at a very early hour? Because we needed to leave, I believe it was at 8 30 to be at the airport at 9, which means in order to do a 10 to 15k run, I've got to be up a hella early. And I think I woke up at what was it? 6 30 or something like that in order to be back. So it was either do that or run when I get to Kongsburg, which was gonna be at like 3 p.m. in the afternoon. And you didn't know it was gonna be cold. And I didn't know it was gonna be cold. I made the right decision for the wrong reasons. I made the right decision because I thought Copenhagen would be easier to run in. I'd be tired. It's been freezing here, folks. Guess what? I did not run this morning. Today is Tuesday. Yesterday I woke up and I I spent 45 minutes coercing myself to get out of bed and run, and I did. It was two degrees. For the American folks, that's like 36 Fahrenheit or something. I couldn't feel my hands the whole run. And today it was even colder. It was zero. I know what that is in Fahrenheit, that's 32. I couldn't do it. I couldn't force myself to get out of bed. And uh I also I don't have you're thinking, why don't you just throw on a fleece? I didn't bring a fleece. I brought shorts, a hoodie, that's it. Anyway, so we ran into Jason. We had a lovely visit with them on the train, until what happened, Bryce?

Bryce

Well, we seem to be cursed for our train luck this trip. Because once again, dear listener, we got on a train. This was actually, wait, both times that we got on a train together.

Conor

Two for two.

Bryce

Both times we got on a train together, something happened with the train. The previous train got completely cancelled, but this train didn't get entirely canceled, but uh we went somewhere and then they started speaking in the uh the Norwegian, and then uh then the signs changed and the but our our our stop disappeared from the little display monitor, and then a guy came through and asked for our tickets, and he said, Oh, well, this train's heading in the d in the opposite direction now because there's a track closure, and you gotta get off the train and something, something, something about a bus. So we got off and we looked, we went and walked over with all the rest of the people, and it looked like there was gonna be a bus. But then the bus wasn't gonna take us to the final destination. The bus was just gonna take us around the train closure, the track closure. And I was like, I'm not having enough of this, so we got a very expensive Uber. Well, not a very well, depending on your frame of reference, an expensive Uber that we took directly to Kongsberg, the city of Kongsberg, the C's not really a city. I don't know what the population is, but I don't think it gets to be called a city. It is uh it is a sleepy little town, and we get it. It's a sleepy buddy, buddy. I gotta tell you, the the people of Norwegian. The restaurant that I had dinner at tonight, one of the one of the folks who was in our training today, he's Norwegian, he's from this town. His parents own the building that the restaurant is in. Yes, that's a sleepy little town. You don't get to you don't get to be a city until you're more than 50,000 population. I'm sorry. But the town of Konsberg, but the place where we had dinner, the guy, the the literally uh had dinner with the person who owns the building that the restaurant was in because it's a little town. Everybody knows everybody. Anyways, we got here, and then we had to do an eight-hour training on Monday on CUDA C, which Connor delivered about 40-50% of. I delivered the rest of it.

Conor

And then uh It would have been 50-50 if you hadn't gone over by half an hour.

Bryce

It wouldn't would have been 50-50 if I hadn't gone over by half an hour. I did not go over by half an hour, I went over by about 15 minutes, and nobody complained. We got great It was 30. We got great feedback. People could have left whenever. And then peep everybody was happy. I got great feedback. We had less lovely people there, and then today we did a Cru to Python training, which I gave about half of, and my colleague, our colleague, Ashwin, gave about half of. And it all went great. It was excellent, it was wonderful. Now I got one more talk, just one more tomorrow, because tomorrow is the open of NDC Tech Town, which is uh I'm learning. The people tell me, I didn't realize it's not actually a C conference, it's an embedded conference. Is what the is what it seems like different people have different ideas about what this conference is about. I have been to this conference before. Don't you know? I I mean I didn't go to that many talks, I just talked to a lot of people.

Conor

So wait, you've been to when was the last time you were in NDC? Wait, wait, wait, just wait for me to ask because nobody can hear what you're saying. When was the last time you were in NDC Tech Town and give us your review of that last edition that you were here for? I'm assuming it was pre-pandemic, but you can tell us.

Bryce

I was here last year. It was very nice, lovely people. Yeah, yeah, I was here last yeah, last year, very lovely. I do recall talking to lots of people who worked on interesting devices, like people from the company that makes remarkable, the little like liquid paper tablet thingy were here, and there were a couple other people like somebody who worked in like some sort of deep-sea vehicle. So lots of people who worked on things that now I'm realizing are all embedded things. But at the time I just thought they were very cool things.

Conor

You know that uh I saw Chandler earlier.

Bryce

What's Chandler? Chandler Caruth?

Conor

He's not on the schedule, but and also too.

Bryce

No, you didn't see Chandler. I haven't seen Chandler in so long.

Conor

No one can hear what I'm saying, but I did definitely see, unless if Chandler, coincidentally, happens to be in the city of Konsber, it was definitely him. It was definitely him. He had a sharp, a sharp haircut, he always has a sharp haircut. He's always very nicely dressed, and he had a mask on. Um it was definitely I mean I'm saying definitely, but as a former actuary, I should uh I should take a step back. I'm 97% sure. That means that there's a 3 in 100 chance that I think I'm wrong. Um I'm very confident Chandler's here, even though he's not speaking. And what was I also gonna say? Um Techtown embedded 2024, Jetson embedded, your talks tomorrow. Alright, well, let's transition. You just heard a record scratch. I can't remember what the second point I had to make was. That's because Condor's turning into an old man. Well, I mean, I'm just catching up with you because you are already an old man. That is true. That is true. Anyways, um our plan is to record tomorrow night. We already told you about this on Saturday. You're hearing it a week apart, but it is now Tuesday. The conference starts uh tomorrow. And tomorrow night is the NDC social after the first day of the conference. We're gonna be interviewing folks, but right now we are following up our conversation, which I butchered by saying have we had Chandler in the bias? Are you kidding me? Before Sean came on and talked about how he crashed the Porsche, I can't I can say I consider the pizza to Google story by Chandler. I mean, I mean that was the that was the best we had. I think to this day, too, it's probably the most inspiring because as good as the uh Sean Perrin crashing the Porsche story is, that's just an amazing story. You're not inspiring anyone to like work hard and end up at a you know.

Bryce

I think if I heard that story, I'd be inspired by all.

Conor

Anyway, so uh we're gonna be interviewing folks tomorrow, but now we're gonna follow up our conversation to replicate uh of which you've listened to already like a week or two ago, or maybe it was a week ago, just a week ago now. And I said scatter, scatter, scatter, but then I edited it. Not yet. Current Connor has not edited it.

Bryce

Why are you saying scatter, scatter, scatter?

Conor

Because remember, I I explained to you that the permutation iterator was the lazy version of the scatter algorithm.

Bryce

Why are you telling the listener right now?

Conor

Oh, because I will keep I will keep a couple in. I have to let them know because they're gonna notice the quiet, echoey room of scatter versus the noisy streets of Copenhagen. There's no way I can say uh of gather, yeah, scatter versus gather. It's alright. No, I will never forget now. I will I will never forget the gather is the algorithm version. The problem is, is why don't we just call algorithm and iterators the same thing? Gather, gather iterator. Sequence, sequence iterator, or counting, counting. Well, why don't we just name them the same, you know? It's it's beyond me. Nobody knows. But anyways, Bryce has had some time to think about how to implement this algorithm, and I have gone and taken a look, and uh there's lots of exciting things to talk about it. We're gonna hand the mic back to Bryce.

Bryce

Wait, wait till you have the mic. You're gonna have to go first, because after two days of training and just spending a couple hours with uh an NVIDIA customer trying to debug some weird problem. I uh I have to page the context of uh uh of how to implement replicate in a single pass back in.

Conor

Alright, well uh I can I can chat a little bit first. Remember, we talked about the integer overload, which is lazy and easy, and now we're talking about the array overload, which takes an array of integers that corresponds in length to the length of our sequence, and you want to basically copy each of the corresponding elements the number of times uh of the element or the integer that corresponds to that element. So, as I mentioned in the last episode, if you have A, B, C, and one, two, three, you end up with A, B, B, C, C, C. As Bryce just mentioned off mic, you may have picked it up, you may have not. It is effectively a run-length decode. And the question is, and the discussion is how to implement this in parallel. If we look at the current implementation, which obviously will change, it's an experimental library, folks, so everything changes very quickly. I think I had five kernels. Five kernels, Bryce. That's not hard to beat. That's it's definitely too many, and it's not too hard to beat.

Bryce

Yeah, so now I'm remembering all the context. Yeah, like I I was working on this when we were on the plane. When Connor was napping, I was furiously coding on my notepad on my phone, as I often do. Um I I think I may just I think I may just read you some of my notes um from this document that I wrote on the plane. Alright, so uh so per block, if we think about this problem, let's divide this problem up into a bunch of blocks, which is what we want to do to parallelize this. We need to be able to subdivide this this problem um up into a bunch of blocks. So let's assume that for each block of threads, each group of threads, we've got a fixed input of n pairs of value in count. And and then we want to out to do a fixed output of k values. Um that's like the the facility that we have today in Cub is can can do that. It it it where it has a fixed size input and a fixed size output. Um the problem with that is uh you you end up with having one of two cases. Either one k is exceeded by less than n inputs. So your your fixed size output, you exhaust your output before you get through all of your input pairs. And if that's the case, then how do we process the remaining n inputs without introducing load imbalance? The other case is where all n inputs are exhausted, but we've produced less than k outputs. And if that's the case, then you end up with gaps in the output. And so this algorithm is just not as straightforward to do single pass as you might uh uh as you might wish. I think if I go to my chat GPT history, um it is pretty straightforward. Oh god, there's been a lot of chat GPT queries since. No, where is okay, alright, alright, you hold this for a second.

Conor

Alright, folks, I'm not sure what I'm supposed to say right now. Bryce is just looking through the history of his chats with ChatGPT.

Bryce

I had to get things on announcing the editing.

Conor

Seeing as Bryce is not paying attention, I'll just walk you through the algorithm that I had implemented, which will clearly be replaced because it's five kernels. If I recall from memory, it starts off with a plus scan on the integer sequence, representing the number of times we have to copy things. And that leads us to the starting positions of each of the sequences of values in our decoded sequence. Then I do a scatter if, which we we we need to talk about to the naming. Because we didn't talk about that on the last episode. We had a a big discussion from the ice cream to the walk home to the hotel, and Bryce wanted to record, and I said, no, no, no, we'll talk about this next time. And it's the naming of scatter and gather, which is part of the reason that I I messed up saying scatter when I should have been saying scatter, because gather is, and and we asked ChatGPT this, or actually, wait, you did record a mini recording of the yeet versus yoink, which maybe maybe I'll cut in right now. The top humorous one was yeet and yoink. And then Bryce thought that was hilarious, and that's what we should call it. But my response was, well, that doesn't make any sense because yeet means to like delete, to get rid of, to toss it, you know, when they say yeet it means to get rid of it. And that's not what scatter's doing. So is the semantically, it has nothing to do with the actual semantics.

Bryce

So I believe you said specifically yeet semantically has nothing to do with the actual operation.

Conor

Yeah, yeah, something like that. Uh but the best suggestion, in my opinion, because I had actually thought about scatter to and gather from, where I was thinking of gather because you're gathering from an index and then copying to an output. But scatter is scattering from an input to an output index. And so gather is the algorithm I was reaching for, but you know, scatter gather are they good names? The idea that you basically, and I was thinking alternative names are index copy to and index copy from. I'm not actually sure which I like the most, because index copy to versus from, the only thing you have to delineate the difference between those two is the fact that you're copying to an index versus copying from an index. Anyways, a little bit confusing. And one of the properties of a scatter to is that you can only scatter to the the maximum number of indexes you can scatter to is the length of your input sequence. Whereas gather does not have that property. Gather from you can gather from the same index multiple times, and therefore you can end up with an output sequence that is longer than the input sequence. And technically, like the output sequence from scatter two could be longer, but the number of copies that you'll end up doing is less than or equal to the input sequence that you have. Anyways, scatter two gather from, index copy to, index copy from. And the point is, is I had a scatter if where you are scattering the value from your input sequence to the integer if it equals a counting iterator. So you end up with the cumulative sums from your plus scan on the integers, and that's where you want to copy the first value of each decoded sequence. And so you do a scatter if the counting iterator equals one of the values in your plus scanned integers. And so you end up with a value at the beginning of each decoded sequence or subsequence, and then after that you do a MAC scan to basically copy that value to the rest of the subsequence. And then I think there's one other kernel at the end of that. But that is a MAC scan, a scatter if, uh plus scan. I mean, technically I only mentioned three kernels there, but I counted five when I looked at my algorithm. Anyways, over to you, Bryce. Are you glad that I just randomly talked for like seven minutes?

Bryce

Because I had a chat GPT chat that I knew was there, but when I s I what could not find it in the list of my phone, when I search for it, I just get, you know, error, error, error on the phone. I tried I I we're thinking about it. I try I cleared the cache on my phone and then I opened it up and I could not find it. I knew it was there. Eventually I opened it up in my browser and I searched for it in the browser, and like the first time it gives me an error, and the second time, then it pops up, and now it's like suddenly showing up as my latest chat. So like it was it was definitely not there in the list until I searched for it and found it. So they then they have some infrastructure, some infrastructure issues they gotta they gotta look at. Anyways, you you wanted things expressed in terms of thrust. So I was saying before I was unable to find the chat and was interrupted, that it's fairly straightforward to uninterrupted.

Conor

You handed the mic away.

Bryce

I know, I uh interrupted by my inability to find it on chat interrupted by chat GPT. I was interrupted by chat GPT's rudeness of not being able to find. Things. It's fairly straightforward to do this as a two-pass algorithm. Pass number one, so we've got an input, a value, like imagine we have a function that takes uh a device vector of values, uh, a device vector of counts, and then it takes some output uh iterator, let's say. Um and uh uh we do an exclusive scan um from uh first of all, we create some temporary storage uh uh called like offsets. Um that's gonna be the size of the values. Um and then we do an exclusive scan uh of the counts into this offsets array. Um and then we um uh those are good names for it.

Conor

Those are good names for it, by the way. I kept on saying integer sequence, yada yada, counts and offsets.

Bryce

Very nice names. Yeah, not not names that I picked, names that the AI picked. Let us all bow down to the machine gods that rule us. Yeah, the machine gods that rule us, where we can't even find the chat that I had two days ago.

Conor

Future machine god. I do not share Bryce's opinion. I serve you.

Bryce

Yeah, I serve no one. Um so then what once you've done that exclusive scan, so so i i uh the first version of this that the AI wrote, it did a reduce to figure out the the like the size of the output, and then it does the scan. Yeah.

Conor

In this case, I'm I'm I'm writing this of like a an STL style algorithm where um I assume that you or repeat for people because uh we forget sometimes we've been doing this for 250 episodes and we we skate by what is obvious to us, uh but why do we not need to reduce when we've done a scan?

Bryce

Uh because when you do a scan of something, the last element of the scan is the sum of the entire sequence. Um so in this particular case, the version that we're writing, uh we are writing to a fixed size output. So when you call this one-length decode, you give it an output buffer and you tell it how large it is. And if if decoding ends up exceeding the buffer, it just stops decoding. It will never go past the end. Um and we we've written, I'm writing it this way because almost all of the C algorithms are designed this way. Um now typically they don't take an output that's like of a uh uh a known size, but uh typically if there's like two inputs, it will only perform operations up until the smallest of the of the two inputs. Um and there are a couple that now take sized outputs. Um uh and this is just sort of the most natural way to meet for way to write it for me. The reason why I think it's the most natural is that if you have a fixed-sized output buffer, then you don't want an algorithmic primitive that's going to do an extra reduction to count the size of the output because that's wasteful. Um and if you don't have a fixed size output, if you need if you're gonna allocate the correct amount of output size, then you can just do the reduction yourself before you call the primitive. So I think that this is the more fundamental thing. But anyways, you do the scan, you get the the offsets, um, and then you can do a for each n where you uh you go through and you use those uh those partials, the the scanned counts to uh do yeah, the offsets to do the uh the right uh the expansion. Um and so it's pretty straightforward to do it in two passes, but I of course am a lover of a single pass algorithm. So I was trying to imagine how to do this as a single pass algorithm, and I think I mentioned, I explained perhaps poorly last time, that there is um this idea of a cooperative um uh uh kernel where um uh you have a bunch of groups of threads that are running concurrently at the same time and they can all have a uh synchronize with each other. Um and uh that you use this sort of cooperative uh kernel to implement something like a um uh a persistent map mall. A persistent map mall is a parallel algorithm where it's what it does is it it loads in you know an input matrix uh or input matrices, and then it starts doing a matrix multiplication of those input matrices, and then while it's doing that matrix multiplication, it starts loading in a next set of inputs. So it's persistent in that it is constantly um uh uh performing matrix multiplications while also fetching, prefetching, if you will, the next set of inputs to uh feed in. Uh this is very common in uh machine learning pipelines. And one could imagine having a persistent run-length decode uh kernel like this, where you have uh uh this parallel algorithm running where it is uh you know it fetches the next set of values and count pairs, and then it expands them to some output, um, and then it writes, and then it continues doing this until it's exhausted all of the um the input uh the inputs. And the reason that you would do this, the reason that you would write the run-length decode like this is because you do not know how much work, like you know how many values you have and you know how many counts you have, but you don't know how much work that represents because you don't know how many output elements you're gonna have. And so uh it's hard to like ahead of time do the load balancing. So I was imagining running a cooperative version of this, and I was trying to think about different schemes for how you could do the um the load balancing. Um so what you could do is you could um, you know, you could have like you could do a scan to figure out, like as we just said, you can do a scan to figure out the offsets of where you're gonna write. And then after that, you could decide to load balance at that point. You could decide now that you know where everything's gonna be written in the output, you could decide to load balance so that every, you know, thread is writing roughly the same number of elements. The problem with that is the locality problem because you've already loaded in the values and counts to some set of threads, and so they're local somewhere. Um and so if you do load balancing at that point, um it may be worse than just having load and balance but still preserving locality. Um and then I got thinking about all sorts of other all sorts of other problems. Uh like what if you have some really extreme load imbalance? Like what if you've got like one value count pair that's like um, you know, orders of magnitude larger than the others? Um and then I realized that the uh the cob run length decode block run length decode is probably broken because I'm almost certain that it doesn't handle the case where the uh the size of the of the count or where the count like exceeds the size of the fixed window that it supports. Uh Connor thinks that it that it's not a bug and that it does support it, but I've looked at the code. I'm almost certain that he's wrong. Um and then I hadn't I have not looked at the code, but I'm pretty sure it's right. Uh okay, then you can go test it tomorrow. Um or I can go test it tomorrow. Um and and then I had this thought, I wrote I wrote some notes down here. Um uh I didn't know I I I had this idea about sort of doing an adaptive thing. Or I guess I imagine the well, well, I'm almost done. The the adaptive thing, I uh I I uh if you do the load balancing, then you sort of like end up with this like adaptive, like uh as you go through the input sequence, you end up with different load balancing schemes. Like you have different amounts of different distributions of work, different uh numbers of runs that you're pulling in at a time. Then I sort of have this insight. I wrote, what if our scan produces intervals similar to chunk by? Because I I implement in one of my talks chunk by, which is chunk by is taking a larger sequence of n um and then producing a smaller compressed sequence. And you can, if your chunk by operates on equality, if your chunk by like uh uh chunks by like uh uh uh like equal, and then like you do chunk by like unique, it's sort of like the inverse of run length decode. And so I started thinking that it maybe this has some relation to chunk by um and and and that maybe chunk by is actually kind of similar to run length encoding, or maybe run length encoding is like a specialized form of chunk by. Um and uh uh yeah, and and that's that's that's that's just sort of what my random plain note thoughts are. So I think I think the best algorithm uh that would be single pass that I could come up with would be to either would be the cooperative one um either with or without load uh balancing. Um I I don't know that a non-cooperative one exists. But I think I had some ideas here about that. Connor wants the microphone.

Conor

Alright, it is obvious that bl chunk by is a building block for run length and code. That is literally the first step of run length and code is to chunk the groups. This literally a uh I don't know if it's well known in Haskell, but the equivalent of chunk by in Haskell is group. There's a group by algorithm that takes the predicate, but group is a specialization where it's just equal to. So you just call group, and then you take the head, which is the equivalent of the first element, and the length. And that's a run-length encode. It's like three functions in Haskell. Anyway, so yes, chunk by is the very first building block of run-length encode, but I want to take it in a different direction. You lost me, Bryce.

Bryce

Wait, wait, wait, wait.

Conor

Alright, we will take it in a different direction in three minutes. Bryce would like to respond.

Bryce

What if what if um what if there's a more general form of run length decode? Because like uh run- We're just talking about chunk by and run-length encode. Yeah, uh, I know. Uh uh well, but but um like run length encode is saying like uh uh like collapse with a specific function, like you know, of like like these things are equal, collapse them down to a single value, right? Like that's a that's a function you can imagine. But but but and and run length decode is saying like uh like take this sequence of value count pairs and expand it with a specific function of like just repeating. Um but what if what what if you could imagine like a generic form of this where it it had some different way of doing the expansion where you have like you you have value in maybe not count, but like almost like value in like you know a function, a like a function application, yeah. Um like for each value you're going to do something to produce some number of values. But I don't know, it's just an interesting thought I had that maybe there's a more general version of run length decode.

Conor

You're correct, I can already think of it. The same way that there is a take in C20, and there's a take while. Take just takes an integer, and take while takes a unary predicate. If you want to invert that, you could do the same thing. So run length decode takes an integer. You could also design it so that run length decode takes a predicate. And so it decodes until it satisfies that predicate. And so you can always implement the integer version in terms of the unary predicate version where as long as the current length or count is less than a certain amount.

Bryce

I was thinking where I was thinking maybe even more generic than that, where it might decode different values.

Conor

It can be some kind of yeah, like expansion function that ends after something. I mean that's true. Alright, now it's been three minutes, and now I'm gonna take it in a different direction. We gotta we gotta break down what the category of algorithms are. Because we first I mean, I was talking about thrust. And also too, I said five kernels. I whipped out the implementation. One of them is an unnecessary fill, and one of them is an unnecessary copy. So the scan, scatter scan algorithm is three kernels. That's what it is in thrust. Bryce is saying it's two if you just do a four each after a scan. I squint my eyes and I twist my head, and I think maybe that works, but I'm not entirely convinced. Because I'm using a scan, and a scan typically can't be replaced by a four each. Maybe you don't. But anyways, we'll come back to that later. We're pausing and we're talking about what are the categories, because you dropped down from talking about thrust and then started talking about like a block aware. So, like, what are the what's your mental model for the taxonomy of algorithms? Be sure to check these show notes either in your podcast app or at adsphepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day.

Bryce

Low quality, high quality, that is the tagline of our podcast.

Conor

It's not the tagline. Our tagline is chaos with sprinkles of information.