CppCast - PLF Library

Episode Date: July 28, 2016

Rob and Jason are joined by Matt Bentley to discuss plf::colony<> and plf::stack<> and some of their advantages over std::vector<> and std::stack<>. Matt Bentley was born in 1978 and never recovered from the experience. He started programming in 1986, completing a BSc Computer Science 1999, before spending three years working for a legal publishing firm, getting chronic fatigue syndrone, quitting, building a music studio, recovering, getting interested in programming again, building a game engine, and stumbling across some generalized solutions to some old problems. News CppCon 2016 Program CLion 2016.2 released Free Seattle C++/Graphics workshop Aug 3rd Using ImGui with modern C++ and STL for creating awesome game dev tools Part 2 LLVM Weekly #134 Matt Bentley @xolvenz Matt Bentley on GitHub Links PLF C++ Library Sponsor Incredibuild

This episode of CppCast is sponsored by Incredibuild. You won't believe how fast your build can run until you download your free developer version at incredibuild.com slash cppoffer or just click the link on our website. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Episode 65 of CppCast with guest Matt Bentley recorded July 28th, 2016. In this episode, we discussed the CppCon 2016 program. Then we talked to Matt Bentley, the developer of the PLF Containers Library.

Matt talks to us about the PLF Colony and Stack Containers and some of their performance advantages. Welcome to episode 65 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Berman. Join my co-host, Jason Turner. Jason, how are you doing today? Doing good, Rob. How about you? I'm doing okay. I just wanted to get right to this feedback. We had a lot of talk going on Reddit about our last episode with Gabriel Dos Reyes. One of the things he mentioned during the talk, I'm just going to kind of summarize all these Reddit comments. He talked about how over half of the C++ developers use Visual C++. And someone, I guess, took issue to that and was citing the JetBrains survey,

which showed less than half prefer vC++. But according to Microsoft's data from what gabriel is saying uh he's saying that you know some developers will use multiple compilers and microsoft at least believes that at least half of c++ devs do use vc++ that is disturbing you know for me personally i i use all three major compilers and what i prefer depends on what i'm doing and i certainly but but i definitely use all three and i'm guessing a lot of c++ developers do use multiple compilers i mean i'm having to test on all three just to make sure that everything's compatible across compilers. But what's an example of a scenario where you'd specifically prefer to use Visual Studio, Visual C++?

For me personally, for anything that's going to be running on Windows, I prefer to use Visual C++. It works better than the other alternatives, like MinGW. MinGW is a great compiler, just want to clarify. But if you, for instance, want to work with libraries that have been compiled with Visual Studio, much easier to do that if you're using Visual Studio. And if you want things to, you know, just in general, behave in a more native way, have good thread support,

you want to use Visual Studio. Right, cool. So we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com, and don't forget to leave us reviews on iTunes as well. You already heard him there a little bit. Joining us

today is Matt Bentley. Matt was born in 1978 and never recovered from the experience. He started programming in 1986, completing a BS in computer science in 1999, before spending three years working for a legal publishing firm, getting chronic fatigue syndrome, quitting, building a music studio, recovering, getting interested in programming again, building a game engine, and stumbling across some generalized solutions

to some old problems. Matt, welcome to the show. Hello. Well, that was way more amusing than it was um yeah great to be here hi i always have to ask what you started programming with in 1986 um basic on a spectra video which i think was also known as a spectrum in some countries so very much sort of i don't know if you guys ever dealt with gw basic but sort of real yeah terrible um and then later on get onto things which were a little bit more user-friendly like quick basic and eventually discovered c and c plus plus and that was just much better overall so is that a pc compatible device then uh the spectrum is it the original spectra video no not at all um okay this is sort of you know back in the day storing everything on cassette tapes and

hoping they don't die overnight and all that sort of jazz before floppy disks became a little bit more apparent on the scene. Since you mentioned GW Basic, I just thought maybe this is some PC compatible I had not heard of before. Oh, yeah, yeah. I mean, what I'm saying is later I got onto PC and worked with GW Basic and that sort of thing. Okay. But my start was on spectra video

okay well Matt we got a couple news articles we'll go through and then we'll start talking to you about the work you've been doing with SG 14 group okay cool feel free to comment on any of these the first one they just released the full program for CPP con 2016 so you can now go online and see the full schedule although it doesn't list all of the plenary sessions yet although they CppCon 2016. So you can now go online and see the full schedule, although it doesn't list all of the plenary sessions yet. Although they are announcing that Bjarne Stroustrup is going to be doing the keynote, which is going to be titled

The Evolution of C++ Past, Present, and Future. Sounds like it would be an interesting one. Yeah, it's always great to see what Bjarne is thinking about these days. Seems there's also a t-shirt design contest announced yeah uh if you're interested in designing a t-shirt this will be given out to all the cpp con attendees and there's a deadline on it need to submit it by august 19th so if you have any design skills, it's something to look at. It'll be interesting to see what he says about the future, because a lot of people I know are a bit worried about that. Just the amount of craft that is built into the language over time through necessity.

Whether it's possible to work around that or not. Yeah, I know Bjarne also was I think very disappointed in the lack of features that were added in C++17, so I'll be interested to see what he's going to say about that. Anyway, next one is another update from JetBrains. They're releasing the 2016.2 version. Some of the highlighted features here

are improved performance of debugger drivers and a remote GDB debugger. We've talked about doing that with different IDEs a lot recently. Yeah. They're now going to have Doxygen support, more code generation options, which is a big feature of their IDEs. And they're now going to have some smart CMake support, which I guess is kind of like IntelliSense or code generation for CMake. I mean, CMake is not a very pretty language. Let's just say that. So I'm kind of impressed that they will have gotten that working. Yeah, I'm sure it'll make working with CMake a bit easier if you're using CLion.

There's also a note there, Doxygen support is in this release now. And I saw some tweets from Uniten, who we interviewed, talking about how his documentation tool should also be able to work with minor changes. Okay, that's good. How is his tool coming along? I thought that was still very, very early days. Standard Ease is the name of it. Yeah, Standard Ease. He just released an update, or is getting ready to release another update, and it's looking like it's starting to become something that maybe you might be able to roll into a test environment

anyhow. Okay, that's exciting. This next one is really only for listeners who might live in the Seattle area, but if you're over there, there's going to be a C++ graphics workshop on August 3rd being run by some developers in the C++ community who work in video game graphics, AR, and VR. So definitely an interesting thing to check out. And it's just, yeah. And the last or second to last one here,

another update from Elias Daler's blog, part two of his series on using IMGUI with Modern C++ and STL for creating game tools it's a really great post um i know you've talked before jason about how impressed you are by some of his blog posts yeah they're well done um i really need to dig into some of this stuff i haven't had the chance to play with mgui yet and i need to there's tons of really good examples he even has some animations going on in here showing you how his tools work. So it's

definitely worth checking out if you're interested in game development at all. And then this last article is LVM Weekly Update 134. It looks like they're moving from Subversion to Clang. Right, Jason? Wait, from Subversion to Clang?

Subversion to Git. Okay. My mistake. Yeah, yeah. Well, they've always had a Git mirror. What was that? They've always had a Git mirror, but I don't know. Oh, a proposed move.

Oh, it's a discussion about a proposed move, maybe? I don't know. I missed that part of this article. That's the part that I got out of it. They're at version 3.9, too, or 3.9, and it looks like their next version is going to be version 4.0. Yes. Yeah.

The main thing I got out of it was initial coroutine support. That's good. And that's based on the same spec that's being used in Visual C++, I guess? Not their own version of it, right? It's not like modules. I'm not sure, honestly, without digging into their docs. And it looks like a really big commit to dig into,

so I'm not sure. That's fair. Okay, well, Matt, let's start talking to you about the proposals from the SG14 working group. We've had a couple other C++ developers on who are involved in that group. Could you maybe give us an update on how all that work is doing and whether any progress has been made in the ISO C++ meetings? Can't comment on that personally.

I haven't been to any of the meetings because they're slightly too far away from where I live, so to speak. But, you know, I've been part of some of the online discussions at least, and I think that's really interesting. I mean, because it's bringing together, although these are all fields which are all essentially geared towards high performance one way or the other, they're still very different fields. So the kind of feedback that you get coming out of the games people is very different to the feedback that you get coming out of the low latency, high performance trading crowd so um i think what's good about it is that there's a lot of different perspectives all geared towards high performance coming together and there's

some consensus like not everybody agrees on the same things like whether or not um the standard library is usable in any way shape or form um versus partially usable in some bits the triple a developers don't think it's usable at all um but obviously indeed developers are more likely to use it yeah it varies a lot um so i think that in and of itself is useful, sort of people understanding what each other's consensus is as to whether, you know, where it's at in relation to the standard and proposals, I can't really say personally. Okay.

Okay, well, do you want to tell us about the new container class that you're proposing and that you're going to be talking about cpp con yeah so this kind of came about because i was developing a game engine a few years back and i'd been out of the game for quite some time like you know 10 years or so um it's funny how you know quitting your job to focus on having a long-term illness kind of does that to you. But, you know, so a lot of the stuff that I was coming across was stuff that hadn't been common the last time I was doing C++. You know, for example, when I was at university university we didn't do standard library stuff because it it you know it was there it just wasn't used a lot um so now i was running into all these things

like you know standard map and standard vector and stuff and i was thinking oh that you know that sounds like it could be really useful something that a container that expands in real time um so you don't have to determine how many objects you are having in advance which is exactly the sort of thing that you want for a game engine because you don't know um but then of course like most c++ noobs i started using it and then discovering oh right it invalidates pointers at the drop of a hash and it has these problems and the erase times are really slow and this sort of jazz so um i guess from out of that came desire to do something which um you know had decent performance like a vector but wasn't invalidating your links all the time and when i say links i basically mean whatever whatever method you use to refer between items of data

in your program whether it's indexes or pointers or iterators or whatever um so what I ended up coming up with eventually was something that uses multiple blocks, like a DIG does, but has a growth factor, so expands twice for every block, essentially. And in that way, gets around the invalidation on insertion problem because you don't have to reallocate your data. And it uses a skip field instead of reallocation for erasures. So you end up having very fast insertion compared to a vector, very fast erasure compared to a vector very fast erasure compared to a vector and kind of the third component of it was essentially finding some kind of skip field pattern that allowed an iterator to iterate in time complexity 01 because that's one of the requirements for iterators under C++.

And eventually I came up with this kind of combination of a data pattern and an algorithm, which for lack of a better term I've called jump counting skip field pattern because that's essentially what it does. And that basically enables that. I feel like I should take a breath there and let you guys ask something. I am kind of curious how this jump skip field pattern that you mentioned for your iterator can work. Because that was the first thing that came to mind was thinking if there's skips then how is it possible to iterate efficiently yeah so you know initially i was using um a boolean skip field and that was fine i mean but as i said you know the problem of that is that you can have one active element and then

50 erased elements after it and then another another active element. So essentially when you've got your iterator and it does a plus-plus operation, then it has to do 50 checks between here and there. And that number could be anything from one check to 1,000 checks between elements that aren't erased so it's difficult for me to demonstrate how the pattern works without having visuals so i won't go into it in any great depth but essentially it counts the jumps and it does it the way that the algorithm works it does it very efficiently and it also allows for reinsertion so anything that's been erased any of those erased element locations also get pushed onto a custom stack which is also part of the whole deal and the next time you do an insert, it pops that location off the stack and reuses that memory location.

Hence, it's an unordered container. There's no indexes, though it can be sorted. And again, you end up with much faster insertion time because of that, because you're not, you know, constantly reallocating data all the time. All right, so you just said it's not an

ordered container, but you can sort on it so it's a random access. No, you don't have to have random access to sort, do you? I don't recall. No. Okay. Yeah, I mean that's basically it. Yeah, so I think multiset is the same, like unordered that can be sorted.

Don't quote me on that. Yeah. Okay. So it would leave the same gaps that are already in there. It wouldn't do any kind of compression or anything. It's just going to swap elements as it needs to to get them in a sorted order. Oh, when you're doing a sort. Yeah.

Yeah. I mean, yeah. Yeah. assorted order uh oh when you're doing a sort yeah yeah i mean yeah yeah um like i think probably the ideal with i'm not entirely sure how um it tends to work but yeah probably if i were to think about it hard and come up with my own solution the best solution would be to have an internal sort algorithm that gets rid of the gaps as it's sorting but obviously if you were using the standard library standard find or whatever then it's not going to be doing that right yeah i'm just trying to wrap my mind around what this looks like with there being gaps but you don't't, as the user of the container, you don't know there's gaps there, I'm guessing. No, no.

If I'm understanding correctly. Yeah, they're not visible. Okay. And the other thing that happens is that when, you know, because it's all memory blocks and they all have, they start in a small size and they have a growth factor and they have a maximum size um and because the skip fields are per block um the bit depth of the skip field actually determines the size of the block which is by default 16 bit so you get a maximum size of 65535, I think. But you can change the bit depth of the field and get whatever you want. But anyway, the point of my saying that was when any of these blocks become empty, whether it's at the end or in the middle or whatever,

they also get, well, they don't get reused, they get thrown away. So they get freed to the OS and that link in the chain closes up. And that just means that you don't end up with a situation where you've got tons and tons of empty space, which isn't being used for anything. Okay. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. IncrediBuild dramatically reduces compilation and development times for both small and big companies like EA, Microsoft Game Studios, and NVIDIA.

IncrediBuild's unique process virtualization technology will transform your computer network into a virtual supercomputer and let each workstation use hundreds of idle cores across the network. Use IncrediBuild to accelerate more than just C++ compilations, speed up your unit tests, run more development cycles, and scale your development to the cloud to unleash unreal speeds. Join more than 100,000 users to save hundreds of monthly developer hours using existing hardware. Download your free developer version at incredibuild.com slash cppoffer or just click on the link in our link section.

You mentioned before how a lot of AAA developers you've talked to on the working group don't use the standard library containers. Do they wind up making their own container classes that are similar to what you've been working on um i don't think there's anything quite the same because i don't think anybody else has been doing the jump counting thing but that aside they probably have been doing a lot of stuff that's similar in other regards like from what i've seen uh the approach of using you know a boolean field for each object in a game and just kind of ticking those off rather than erasing them and then skipping over them during iteration that's quite a common approach um but

as i'll show in my talk that's quite, the iteration performance of that is actually not very good compared to other things that you can do. different elements that don't exist anymore and you're iterating essentially only over a few of them that whole pattern is actually quite slow and surprisingly it's not actually because of the amount of data that you're reading like it's not because of reading all of those boolean fields it's actually just because of the branching and what's interesting is that when you get when you use that kind of pattern and you've raised say 25% of all of the elements in your container and you're iterating over them your iteration time slows down and then when you go

up to 50% the iteration time slows down. And then when you go up to 50%, the iteration time just goes completely to hell because the branch prediction of the CPU can't work on the branching anymore because it's essentially random. And then once you get up to 75% erasures, the iteration time is fairly much the same as it was back at 25% erasures.

So it's almost entirely down to that branching CPU branch prediction, that sort of thing, as to why that style of erasing stuff doesn't work terribly well. Do you have any kind of compact method so over time you could choose to take the cost of what would essentially be a garbage collection? Yeah, I mean, there is a, you know, basically a shrink-to-fit function. Okay. Much like what you've got with Vector, but of course the caveat with that is that you invalidate all your pointers and all your approaches. So, yeah, that's kind of problematic i guess so i understand what you are getting at with the uh branch predictor and then i'm wondering what its cash friendliness

is like because it seems like you are generally moving linearly through memory so cash friendliness i would expect to be pretty good yeah i mean it's you know it's um it's one of those things where I think if the people who are actually working on lib standard C++, those sorts of people who have got really, really deep experience with implementation, this sort of thing, and particularly implementing under a given compiler we're able to take it on they could probably make something where the iteration was better again maybe change some of the way it's structured whatever but as it is it's pretty good like the iteration performance is in terms of what's in the standard library, it's better than anything except for standard deke and standard vector. So, yeah, that's pretty good, particularly considering that you've got to take into account you're going to be jumping over a lot of data and whatever, whereas standard deke, standard vector,

you don't have to do any jumping by default. Right. I think the only thing that can beat vector would be an array and that would only be because of the initial offset yeah yeah exactly um having said that you know vector has some problems in terms of um you know it's just a singular memory block and you know it's not all going to fit into your cache at once so a lot of what i've um seen people talking about is sort of breaking stuff down into sizes that will actually fit into your your cache lines and just feeding stuff through like that. So one of the ideas for this was basically giving the programmer the ability to customize the minimum and maximum size

of the memory blocks. So the minimum and maximum could, in fact, just be the same. So they can, in fact, shrink it down to whatever size is actually going to fit in your cache line. But, you know, then you've got to deal with, you've got to have some check there, like you do with a deke, to check that you're not at the end of the block, and if you're at the end of the block, you've got to skip on to the next block. So, and that's branching so vector

is always going to have or an array is always going to have an advantage in that respect right so so far we've been talking about your colony container do you want to tell us about the stack container and how it compares to the standard stack yeah so i mean basically standard stack is standard deke under the hood unless you specify otherwise um and it's just a container adapter rather than an actual container um so basically i determined that what was existing in standard library was not going to be fast enough for what I wanted to do because I need that stack and colony to push the erased memory locations onto and then pop them off again. And vector wasn't going to be fast enough and standard stack, standard deque wasn't going to be fast enough so the advantage of uh the memory allocation pattern i've got under

the hood for both colony and uh plf stack is basically a you know if you want to break it down essentially it's a doubly linked intrusive uh list of groups which are just memory blocks plus metadata plus whatever else and the advantage of doing it that way is that it removes a lot of the complexity that you can get from doing things for example i think deke is usually implemented as a vector of memory blocks or a vector of pointers to memory blocks under the hood. That creates more complexity, but it also means that if you're getting rid of memory blocks a lot, then you have, it's more expensive, the operation is more expensive. But the linked list pattern, like a normal linked linked list is not so good for iteration but it's really good for getting rid of things and putting things in again and that's essentially all that a stack

does you don't iterate over it you just put things into it and you get rid of things. So I don't have the stats right here in front of me, but, yeah, under every compiler I've tested, which is Clang, GCC, Visual Studio, various different versions, yeah, basically beats out standard vector and standard stack in terms of stack performance. Other than that, I mean, it's just a stack, so there's not much to say about it, really.

It's just faster. Well, that is interesting, though, because this is something you are proposing, potentially, as a standard library class, correct? Hmm. Yeah, I was. I'm not sure if i still am um uh there's a kind of i don't know there's a lot of politics in this stuff but um you know one of the requirements for something to be a container under the existing standards is that it have an iterator and a stack doesn't need an iterator. So,

you know, technically I can't propose PLF stack as a standard container. It has to have some kind of different name, like a concept class or something like that. But you know, that's what it does. It contains elements. So,

um, that, that in itself doesn't bother me. It's's just i know if i am going to propose that it's going to be like another project um just to propose it as a standard that's going to take like three or four months to work through and then you know it goes round and round. So we'll see. I might just try getting it into Boost first, getting both Colony and Stack into Boost first because that's something I've been working on for a while. Once that's done, then maybe I'll look at the actual proposals again.

Boost is a very good way to get your code vetted and ready for proposal. I think so. That's certainly been my experience so far. The people on the Boost forums have largely been really, really good, and particularly in just pointing out, hey, you essentially know nothing. Here's one of the things you know nothing about which is you know kind of what i needed um and then some of the time you know people will say things oh you're doing this wrong and then i find out i'm not actually doing it wrong but what they

said was actually a better idea a better way of doing stuff or whatever. But there's so much to know when you're developing a container because there's so much stuff in the standard and there's so much of the standard now. You've got C++03, C++11, and then all the rest of it. It's almost impossible for one person to keep track of it. Yeah, right. So it might be in boost eventually but right now you can still get access to these containers in a library right yeah yeah it's all good to go at the moment um yeah in terms of the actual implementation it's completely done

it'd be nice to get it into Boost because although it wouldn't actually use much from the Boost library, the Boost compiler detection is much, much better than what I can do on my own. Just the detection as to whether, you know, this compiler supports this feature, etc. So yeah, all that stuff is really good you've mentioned it works on the major compilers does it have any other requirements

um no not that i know of um your compiler has to support either c++ 03 or c++11. That's fair. Yeah. If you're on C++99 or whatever the previous standard was, yeah, you're out of luck. I don't think very many people would complain about that today, although you might find someone who would complain about it. There's always someone to complain about something. I think I did see something on one of the forums the other day and it was i think it was a games developer and they were using

something that was pre c++ 03 or they had to rely on a compiler that was pre c++ 03 so but that's an interesting comment if it's something that you can speak to at all it came up in one of our recent uh episodes was uh triple a games development or console games development sometimes it seems like would lock you into older compilers or weird compilers do you know anything about that uh not personally no okay but i don't know yeah i mean i'm not even sure what the reason for that is other than just legacy i guess i mean i know that people haven't been terribly happy with the playstation 4 stuff um so far but i think clang is probably going to be quite good for that um in the sense of being something that can be deployed on multiple platforms and does not bind people to a gnu

license or anything like that um so that will probably change over time i would imagine interesting point so um what state is the library in like have other developers that you know gone and used it and anything like production ready um i haven't i mean i've been contacted by a guy who was um looking to use it for i think actually a compiler of his own like he was actually making a compiler so um he was because a lot of the stuff encoders you had stuff remove us so that it's kind of high modification um it seemed to fit his use case quite well um but that was quite recent i haven't heard back from him. I have heard from several other people who have used it for various things. I haven't really had any bug reports or anything like that, except for the benchmarking stuff I did, which was separate to it. There was just a

couple of standards mistakes in there. But yeah, I haven't had any bug reports in terms of the library itself. So I think it's pretty much good to go. I mean, I'm using it in my own game engine code. So pretty much every time I do a revision to it, it goes through a whole batch of tests and then goes through the game engine and then goes through all the different compilers and you know

if there's something to be picked up it'll get picked up in those but you know at this point I've been working on it for cripes what is it what year is this yeah what year is this 2016 so it's been like a year and a half I've been working on this stuff,

just in my spare time. So I'm thinking it's pretty solid. Yeah, I certainly have no evidence to dissuade me of that. Can you tell us at all about the game engine that you've been working on? Yeah, I mean, there's a bunch of students I've got up in Auckland, which is north of where I am, who are working on the documentation for that library at the moment. It's not a fantastic AAA engine or anything like that.

It's essentially a layer on top of simple Direct Media library, but it supports some nice things, like it supports textures that are larger than the maximum texture size on the graphics card, that sort of thing. Yeah, it's basically designed as a very genericized 2d game engine um with a bunch of additional stuff if i was going to go back and do it again there's a lot of things that i'd do differently um at the time i didn't know about uh entity component systems so um what i've actually

got in there is sort of like a blend between an entity component system and a more traditional object oriented model um yeah but it's pretty good pretty fast etc nothing to write home about but i am kind of looking forward to you know having the documentation there and then being able to just release it so that some other people can get some use of it. It was always designed to be an open source engine. So listeners can't find that online quite yet, but it will be available soon, you hope?

Yeah, by the end of the year, probably. Okay. If people have used SFml or the angel engine um it'll probably be fairly familiar stuff to them um the advantage of it over those things is that they require um i think open gl well they require working open gl drivers, which is not always the case on older equipment and netbooks and what have you. So the advantage of using simple direct media layer under the hood is that it taps into whatever the default is for that OS, whether it's DirectX or whatever the one is on Mac OS X. I forget what that one is but yeah it's

basically designed to be very fast and to run on pretty much anything you said something else that caught my ear you said you have students working on the documentation yeah yeah um they they contacted me in terms of it it's sort of like uh like final year um almost like work placement stuff except you know in this case it's not so much work as it is what is it's open source work so it is work um so they're getting some kind of credit for doing it and they learn about um somewhat surprisingly i specified that they should be you know fairly experienced c++ programmers if they were going to take this on and about a couple of weeks after we got into it i discovered that actually they'd only done java before and um but that's good right i mean you know they're learning a lot at once it's it's quite heavy

for them and you know i'm quite impressed with how they've managed to get by so far it's going to be very good but very hard for them is it possible for you to tell us any more about that uh program for how how found you, you found them? It sounds like something our listeners would be interested in. It's probably not something I can speak of in great detail, but it's just out of Auckland University of Technology. Okay. And they have some kind of program like that I could probably bring up the details

hold on. But you submitted something to the university saying that you were available for people to help them? They actually contacted me because of just I had met one of the lecturers or something and thought I might be a candidate for that. Interesting.

But people can submit stuff. I'll just try and find of the lecturers or something and thought i might be a candidate for that interesting but but people can submit stuff i'll just try and find it very quickly if i can well if you want to send me a link i can put it in the show notes yeah that's probably better because it's gonna take a while to sort through but it might be something interesting to see if other universities have programs like that yeah yeah i think it's good because certainly when i was at university there's this thing where you learn all this stuff and i think um google are doing a lot of that at the moment is you know not so much training people out of what they've been taught but training them into the stuff that actually matters once you get into the industry um so i think it's yeah it's really good to have these sorts of programs because

yeah universities are a little bit of a bubble and you can get very enclosed in that bubble and not actually be doing stuff that's relevant particularly relevant to the outside world right well is there anything else you want to tell us about about the plf containers before we let you go matt um not particularly if people want to you know try them out and get back to me with them their impressions that sort of thing i'm always open to that my email address is on the site it's plflib.org both the stack and the colony container on there um yeah but i hope it's of of use to people and essentially the stuff boils down to it in terms of stack it's just faster than the other alternatives for using stack. In terms of colony, it's much better than the other standard containers in terms of high modification scenarios,

so where there's a lot of insertions and erasures in real time. But it's also a lot better than some of the workarounds that people have for dealing with vector or deke without getting that sort of link and validation between elements in your programs right right and listeners should definitely go check out your talk because even if uh they're not interested in these containers they'll'll be learning some new techniques about high-performance code, right? Yeah, definitely. I think the jump counting skip field pattern is going to be of interest to a lot of people because, yeah, that's just a different way of doing things. And it's probably going to be my biggest contribution in terms of this talk, I think.

But, yeah, hopefully people can get something out of it that benefits their work. And for conference attendees, it looks like you're currently scheduled to be Monday afternoon. That is correct. All right. Okay.

Well, thank you so much for your time today, Matt. Yeah. Thank you very much for having me on the show. It's been good. Thanks for joining us. Thanks so much for your time today, Matt. Thank you very much for having me on the show. It's been good. Thanks for joining us. Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in,

or if you have a suggestion for a topic. I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.