CppCast - Stream Processing

Episode Date: March 24, 2016

Rob and Jason are joined by Jonathan Beard to discuss Stream Processing and the C++ Raft Library. Jonathan Beard received a BS (Biology) and BA (International Studies) in 2005 from the Louisiana State University, MS (Bioinformatics) in 2010 from The Johns Hopkins University, and a PhD in Computer Science from Washington University in St. Louis in 2015. Jonathan served as a U.S. Army Officer through 2010 where he served in roles ranging from medical administrator to acting director of the medical informatics department for the U.S. Army in Europe. Jonathan's research interests include online modeling, stream parallel systems, streaming architectures, compute near data, and massively parallel processing. He is currently a Senior Research Engineer with ARM Research in Austin, Texas. News C++ Weekly Clion 2016.1 Q & A: Bjarne Stroustrup previews C+17 Sub-processing with Modern C++ Jonathan Beard @jonathan_beard Jonathan Beard's website Jonathan Beard on GitHub Links RaftLib C++Now - Come Stream with Me: build performant, simple, parallel applications in C++ using RaftLib

This episode of CppCast is sponsored by Undo Software. Debugging C++ is hard, which is why Undo Software's technology has proven to reduce debugging time by up to two-thirds. Memory corruptions, resource leaks, race conditions, and logic errors can now be fixed quickly and easily. So visit undo-software.com to find out how its next-generation debugging technology can help you find and fix your bugs in minutes, not weeks. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community.

Get your ticket now during early bird registration until July 1st. Episode 50 of CppCast with guest Jonathan Beard recorded March 21st, 2016. In this episode, we talk about the new version of Sea Lion. Then we talk to Jonathan Beard, author of Raftlib. Jonathan talks to us about stream processing using Raft. Welcome to episode 50 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm doing host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm doing good, Rob.

How about you? I'm doing pretty good. It's episode 50. It's a nice round number. A little celebration for that. We should have cake. I had cake the other day. We'll have to share some.

It's almost Easter. My wife's making a cake for that. Peeps? Yeah. She made little bunnies to go on it. It's pretty cute. Oh, that's fun. Yeah.

But you had some news to share, right? Yeah, I've started on a little side project lately, and I just thought I'd mention it on the podcast. I've been recording some live coding sessions and some random topics, and calling it C++ Weekly. And I just released my third episode of it this morning so that's uh something our listeners may or may not be interested in checking out i guess i watched the first one and enjoyed it i'll have to catch up with the other two though i need to

get on a subscribe list or something i got good feedback or good responses to the second one. I got basically 2,000 views in the first week and 100 subscribers to the YouTube channel. I'm not disappointed. It's very good. Okay, well at the top of every episode I like to read a piece of feedback.

This week we got an email from Florian. He writes in I recently stumbled upon a SIMD library by a guy named Agner Fogg. His vector class library is a convenient wrapper for SIMD intrinsics. They can detect the host's hardware capabilities

and automatically perform dynamic dispatching for the best port instruction set. He says he doesn't know Agner personally, but he really likes the library and he hopes we can get him on the show. Definitely sounds like it'd be an interesting topic, right, Jason? It does sound like it'd be an interesting topic. Something that we've kind of touched on several times.

Jason, you still there? Yes. Hello? Yeah. It does sound like an interesting topic. Something we've touched on a few times and could dive into some more, I would think. And it's always nice to look at new libraries. Well, we'd love to hear your thoughts about the show as well.

You can always reach out to us on Facebook or Twitter, and you can email us at feedback at cppcast.com. And don't forget to leave us those iTunes reviews. Joining us today is Jonathan Beard. Jonathan received a BS in biology and a BA in international studies in 2005 from the Louisiana State University. And he got his MS in bioinformatics in 2010 from the John Hopkins University and a PhD in computer science from Washington University in St. Louis in 2015. Jonathan served as a US Army officer through 2010, where he served in roles ranging from

medical administrator to acting director of the Medical Informatics Department for the U.S. Army in Europe. Jonathan's research interests include online modeling, stream parallel systems, streaming architectures, compute near data, and massively parallel processing. He is currently a senior research engineer with Arm Research in Austin, Texas. Jonathan, welcome to the show. Thanks. I think I've done way too much now that you've read that. I really spent way too long in school.

I was just thinking you have four times as many degrees as I do. And you did all that while serving as an Army officer? That's pretty impressive. I did the first two before, and then I joined the Army for some reason. And then I got a master's, and then I did the Army for some reason. Then I got a Master's, and then I did a PhD. Were you stationed in a lot of places? Did they move you around a lot? Oh, yes. I spent a little bit of time in South Korea, in Dongduchon, which is pretty close to the DMZ.

Then I spent the rest of my time in Heidelberg, in Germany. Wow, we were just in Heidelberg last year. Well, it's nice. Did you guys spend a lot of time in downtown, or where did you hang out? We stayed at a hostel. We were only there one night, actually, but we stayed at a hostel that was right at the base of the Heidelberg Castle. And then we spent some time downtown and along the river. Yeah.

It's very nice. So did you go to the Hemingway's Cafe on the river? No, no, we just did lots and lots of walking along the river, actually. I think we walked something like 15 kilometers that day, according to my wife's speedometer. Wow. So did you convert it to kilometers when you went over there and then convert it back to miles? No, actually, it would always count it in miles while we were there. But we were talking to the locals, so we converted it to kilometers for them.

And now I can't. I was just thinking about it in kilometers. I got you. I was just curious. Very cool. Well, we have a couple news articles articles to go through jonathan feel free to jump in and comment on any of these and then we'll talk to you about your raft library yeah this first one is sea lion 2016.1 was just released and uh they they just changed their

versioning because i think it was you know 1.2 or 1.3 the last time we talked about it, and now they're calling it 2016.1. I guess that's an easy way to just track how many releases they're doing in a year, and you always know kind of how up-to-date your build is. It's 2015.1. You're a year old probably. But lots of new features in here. Better C++ language support um variadic templates are in there now that's very nice more code generation uh new features for cmake a new feature called reset cmake cache and they also added python and swift support

in addition to c++ um now swift is open, I guess they're able to do that. It's not restricted to the Mac platform. Yeah, that's some interesting stuff. There's still a couple of things still missing, like constexpr support, but it's awesome to see them continue developing it. Yeah, and it's still just a really good option to have, especially if you're on Linux and you're looking for a good IDE, if you're not able to work with Vim or Emacs anymore.

Next article. Did you have something to say, Jason? No. Go ahead. This next one is a Q&A with Bjarne Stroustrup about C++17, of course. And he's going over his thoughts with this InfoWorld reporter. It's kind of interesting to see C++ talk in the real news, but it is such an important language, so I guess it does make sense.

And it's just nice to see Bjarne's thoughts. Obviously, we've been talking a lot about C++17 for the last few weeks. He's going over his thoughts about what he thinks are the major features and what we have to see in the future. Is there anything you wanted to call out in this article you guys? I did notice that he mentions he's a little disappointed that concepts aren't making it in. He personally thinks they are ready. Right.

It'll be interesting to see how soon they do get in. It did sound like that vote was very close. Yeah. So have you guys played around with concepts at all, out of curiosity? No. No, I have not. No? Okay. Have you, Jonathan?

I have not. That's why I was wondering if you... Okay. Have you, Jonathan? I have not. That's why I was wondering if you... Okay. There is a keynote from Andrew Sutton from last year's C++ Now that is up on YouTube that he goes through what concepts we'll cover, and I think it's a pretty good video, and it would be worth watching if you want to get a high-level view of it. One interesting note here uh that bjarne makes at the end of the article is you know he was asked if it would have made sense to

delay shipping c++ 17 for a little bit to uh get concepts in there and he makes a good point that that would have made it you know instead of c++ 17 it would have been 18 and then we would have probably had c++ 22 or 23 instead of 20. So sticking to this three-year cycle, he believes in. And I think I can agree with that. Yeah. Yeah. This next article is about a new library called,

is it just called Subprocess? It's Subprocessing for C++. Yes. He based it on Python's Subprocess module, and he wanted to bring that type of feature into C++, and he couldn't really find another library. He said Boost Process was the closest one he could find, and it wasn't lightweight enough,

and I guess it wasn't actually an official Boost library. that right yeah that's what he says i i would have sworn it was if i had been asked but i i you know i had to believe him i've only used q process extensively so there is that exists also actually it does seem like a pretty powerful library so if this is something you're looking for it has piping support. Is there anything else you wanted to add to this one, Jason? I would say if it supported Windows, I would probably already be using it. Oh, right. It is a Linux-only library, right? It is. It's Linux and Mac, I believe.

Right. No, no. He says Linux. Oh, yeah. Linux and Mac. Sorry. Okay. Right. Cool. Well, Jonathan, let's start talking to you. Could you maybe give us an overview of what stream processing is? communicating with multiple actors. And so instead of composing the program as functions, you think of each one of those functions as, say, a pure function with no side effects. And you're communicating with what is the outside world or your other compute kernels, in this case is what you usually call them, via distinct ports.

And so you're reading into and then writing out two multiple FIFO ports. And so it's a nice simple way of composing an application that can be executed in parallel without side effects and without having to worry about all the non-determinism that really makes traditional parallel processing difficult. Comparing your streams to futures, which is the highest level threading construct that's in the standard library today,

this is even higher level than that, correct? Yeah, I would definitely consider it higher level than that. Right now I can compose one of my applications with the Raft library with essentially the right shift operators connecting kernels together and execute them in parallel and then let it go. Which is kind of nice.

Whereas Futures, I mean, requires a little bit more work and a little bit more thought. And overall the construction is definitely not side effect free. Although one thing within C++, unfortunately there's really not a good way to do... I mean, I wish there was, say, like a pure keyword, which would be awesome.

And so you could specify a function not to have any external dependencies and then enforce that at a language level, but we can't really do that yet. Interesting. So if a user wanted to use your library with non-pure functions, you have no way of preventing that? Oh, you can cause all kinds of craziness, yeah. Okay. If you stick to the specified API, then everything works nicely.

But as with anything C or C++, you can still shoot yourself in the foot if you really try hard enough. So can you give us like, I know it's difficult on air, if you will, to describe programming concepts, but what does this actually look like from the user perspective? If you want to set up a stream and how does the parallelization come into play? Well, the easiest way would be to look at an example on the GitHub repo. However, so if you're constructing application you extend a base class which is a kernel class and then you interact well you set up ports first which is the way you interact with the outside world and so you have multiple name ports you set up a type for any of those everything strictly typed and then you instantiate um basically the run virtual function whatever

you want and this is how you actually do work and then in your main class when you're actually putting these together or well you can do it in function however you want to but you instantiate a map and then you do the add assign operator overload to the map class and you add to the map a string of kernels. And when you instantiate those kernels, they're connected via FIFO-like constructs. And it's really abstracted away from the user. So those FIFOs could actually be anything. So it could be shared memory, TCP, it could be heap, it could be essentially whatever. The point is the user has no, and it's still executed just as you specified the topology of the application, but the runtime takes care of the rest.

Okay, so the named ports are automatically paired up by your system based on the input and output names being the same or something like that? Yeah, so essentially you'd say, you know, so if you had foo with an output port of X and then bar with an input port of X, and you can connect those up via the right shift operator. So you have one on the left-hand side, then you have the right shift operator, and then you have your kernel you're connecting it to on the opposite side, that right shift operator. And then you just add those to a map, and that makes one link between the X and the Y. Okay.

Horts of those two kernels. They don't have to be the same name. They just have to be the same compatible type. I see. And you use the C++ static typing system to ensure that they're expecting the same types? Yeah, it's actually a little more complicated than that, but yes. And so everything's dynamic, and so it actually checks the type

at runtime. But yeah, it does use the well, it actually uses the type ID and so the runtime type information to get the types. Okay. So can you have multiple writers writing to one reader or multiple readers from one writer, that kind of thing? So right now, the way you'd actually do that is you'd have one, if you look at it as a producer consumer, you'd have one producer and you could have multiple consumers, but the way that would actually be implemented under the hood would be either dynamically adding more ports to the producer,

which would be transparent to the user, or you'd have what amounts to like a fork kernel, which would split the output. Okay. All right. So then anything that can then run in parallel does? Exactly. And so it's not just like running in parallel,

but I mean, it's running, you're really, you're performing computation while you're doing the memory accesses. And so you're overlapping both of those and, you know, essentially doing pipeline parallelism plus task and data parallelism at the same time. So does your system then manage how many threads are running at a time for you? Yes. So that's one thing I've been working on. So it actually was a lot cooler a few months ago, but I was asked to add Windows support. And I'm discovering how much

I'm having to strip out of the Linux API to make everything work nicely with Windows, and I'm working on putting it back together. And so the vision of this was to make parallel programming easier, because initially I was doing biosciences and

computational biology and I wanted to be able to write super parallel programs because most everything is really easily parallelizable if you work at it. Just about everything I looked at, you have to know lots about the software and lots about the hardware. Initially

I didn't want to become a hardware expert, although I am now. I work for ARM. That's actually one of the paths I took to get here, but that's a segue. Yeah, you shouldn't have to know all the information about the cache structure, the hardware you're working on. You shouldn't have to know any of that stuff.

You should be able to sit down and write a relatively performant parallel programming, or a program. And I think that's, you know, Raftlib is one way of doing that. Okay. So that's actually the first time you just mentioned the name of the library. But Raftlib, I think it says on the website that you actually, at one point was Raft's language.

Can you tell us a little bit about that and how you went from a Raph language to the Raph Lib C++ library? Oh, man, that's actually a long story. But we have a few minutes. So I started off my thesis, and I really wanted to model stream parallel systems. And so I was going to do mathematical modeling. And as any young grad student wants to do they want to go write their own language because languages are cool and so i sat down and started writing a language and i got so far as writing the entire bnf so i have a full front end for the language it's actually on github if anybody ever cares to go take a look

um but what i did not get around to was writing the back end. I came to the realization one night that there are thousands of languages out there. I mean, literally thousands. If you go on GitHub, every grad student, undergrad, and probably even every 13-year-old that learns how to program basic programming skills, they want to go write their own language.

But almost none of these ever take off. I mean, you can, you know, name the upstarts, you know, on one hand that have actually made it into the top 10 list. And I can guarantee you almost every single one of those, well, with this exception of Rust, which I'm not sure if it's actually become a major language yet, although I do like it. Almost every one of those has huge corporate backing behind it and incentives for programmers to use. I mean, look at Swift. Would anyone have actually picked up Swift over, say, Rust if Apple wasn't behind it or if one of these other big companies was not behind the language?

And I had a realization that nobody was going to use Raft language. And so what do I do? I went and looked at what was most popular out there and what people actually use for performance and ease of use. And it turns out C++ is still, you know, the primary vehicle for getting relatively high performance at a relatively high level. And so I decided to go build a template library. And so I pulled all the stuff that I had started building for the Raft language, and I packaged it up and put it in the library. And then built a little bit more of

meta-template programming around it to make it look semi-decent. And then I used it for my thesis. So how long ago was that transition to the Raft Library? When did you start the Raft Library, I guess? Well, I actually had the realization while I was flying to Florence for a conference. And so I can probably narrow it down to September of 2014. So while sipping coffee on a plane, I was like, you know what, this isn't going to work. Let's build a library.

By the time I actually landed back in the States, I had a good start to the library. I've been hacking on it in my spare time ever since. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. You have an extensive test suite, right?

You're using TDD, continuous integration, and other best practices. But do all your tests pass all the time? Getting to the bottom of intermittent and obscure test failures is crucial if you want to get the full value from these practices. And Undo Software's live recorder technology allows you to easily fix the bugs that don't otherwise get fixed. Capture a recording of failing tests in your test suites and debug them offline so that you can collaborate with your development teams and customers. Get your software out of development and into production much more quickly and be confident that it is of higher quality. Visit undo-software.com to see how they can help you find out exactly what your software really did

as opposed to what you expected it to do and fix your bugs in minutes, not weeks. So what state would you say Raph library is in currently? Is it something you would recommend C++ developers go try out or is it still fairly unstable? Well, the API itself is fairly stable. I've actually had a decent user base so far and they've And they've had, you know, quite a few comments. And I think it's to a point where I'm not going to have to change anything to add Windows support. The, yeah, pretty much

the API is totally stable. The only changes might come on the backend. And those are mostly going to be transparent to user. One thing that I want to add back in sooner rather than later is the multi-node support. And so one of the cool things I had worked on as a grad student

were, like I mentioned, TCP connections. So you can actually communicate from one node to the next. So it basically runs a daemon on each one of the server nodes and tells your home node what's running elsewhere. And so you can load balance balance, and optimize at a more global level as opposed to simply running on one machine. So I don't know about you guys, but I have lots of extra computers of various vintages running around my house. And sometimes I really want to use all of them. So, yeah.

So that's interesting. So did the multi-node support then require you to have the same program installed on each computer, I assume? Well, the program that actually needs to be installed on each computer is the daemon, which gets everything kicked off. What you need, once you actually hit execute on the host computer or the start computer is access to the original code. And so basically it sends the code around and recompiles it, and then all I need to know are the indexes of which virtual functions. And so when you distribute your computation, you're not actually sending in real time the binary itself.

You're sending the code ahead of time. It gets recompiled and then loaded. There's other ways you could do that, as in shared libraries or fat binaries, but really there's got to be a better way to get around having, say, looking to my left, my old Power Mac G5 on the same network as my newer Mac Pro. So to be perfectly clear, you're saying ship the source code around? Yeah, exactly. And so essentially, old school just in time compilation, unless you can pack a fat binary with multiple, you know, sets of assembly code, basically.

Okay, so you ship the source code off, the source code is built on the receiving daemon, then what mechanism do you use for streaming or serializing the data between them? that you've instantiated. And so it knows what's there. And so it matches up basically the stream representation that the host computer saying, hey, I want to stream data to this function. And so the other binary knows, hey, I need to pick up this function that matches this string and load the hash and load the function and then begin executing it. And so basically, that's fed through from the daemon that executes the binary itself, as one of its arguments. Wow. All right. So although long story short, that needs to be made a little bit more performant than it is now, which is one of the reasons I pulled it out. Well, that and Windows compatibility. Yeah, that's what I was going to

get at next, because cross platform compatibility is kind of one of my things. So you said you had to pull out some features for Windows, and that was one of them? That was one of them. And so I'm fairly good at Linux and Mac network programming, but I am learning all the nuances of doing that on the Windows platform. Okay. So you're doing this from scratch, if you will. You're not using Boost, ASIO, or something. Yeah, so I am doing this from scratch,

although I've considered using Boost. The initial reason for that is, well, so I put the Boost demangle library embedded within Raftlib now instead of using the simple CXX ABI interface, which I guess the Boost one calls it under the hood anyways. But yeah, I had a few complaints about that. So initially, I was trying to keep as few external dependencies as possible. But yeah, I totally agree.

It would be much easier to rely sometimes on more external libraries. All right, so this is just a little bit of a tangent, but you pulled out the Boost demangle library. No, no, no, I left the Boost demangle library. I pulled out the cxxabi.h. No, no, I mean, are you requiring Boost, or did you extract the pieces of Boost that you need? No, no, no, so when you actually run the CMake file, it does the git pull and the version of the demangle within git.

Okay. And so it downloads the version and the reference for the actual copy that I used. So that way, yeah. I'm sorry, go ahead. No, I was saying so that way you get the exact version, no changes, etc. Matches up nicely. Okay. There is an official tool from Boost for extracting just a piece of it that you need.

And I can't remember the name of it. I just thought I'd mention if that might be helpful to you. Yeah, I ran across that. Although, I don't know, I kind of like the cmake and get um sub module download sure but yeah it just seems like a nice way of packaging things up so that way it's all just transparent relatively to the user okay i like easy so you said you've already gotten a fair bit of user feedback uh what types of applications are developers building with Raftlib? So right now it's mainly my test stuff.

And so most of the people that have used it have used it for things like computer vision. So, for instance, I had one guy that, and this actually describes a lot of the development worker feature request. And so I had one guy that wanted to use OpenCV with Raftlib. And getting the CV matrix objects, the smart objects, to work nicely was a challenge at first. So their internal reference counting was a little bit different than some of the other smart objects I had run into. So just making sure the destructors and constructors are all called nicely. It's kind of funny. So the Raftlib FIFO interface is actually three separate interface templates

under the hood, which are all called for different size objects. And so you have one template that's called for a certain L1 decache size. And then you have another template that's called for objects. And then you have another template that's called for objects, and then you have another one that's called for very large objects. And it all optimizes where and how the data is pushed to and pulled from. Interesting.

So if you're taking data like that and pushing it over the wire for your daemon-based solution, I'm still just wondering how in the world you deal with the different binary formats. Say you're sucking it off of a 64-bit Intel onto your G4, like you were saying.

G5. G5, yeah. Then you have to go change all the Indian-ness and, yeah. So is that something that the user has to tell you? That's taken care of by the daemon. So when the data stream is actually pushed over, the receiving daemon

checks and says, okay, this is coming from an Intel machine. I need to change this from little to big and done, or vice versa. Wow. Okay. That was one of my pet peeves is giving the user too much stuff to do and too much stuff to manage. I mean, it has to be done and you have the information for the runtime to do it. Why not just go ahead and do it?

Right. Okay. Are you the sole contributor to Raft or are you taking other contributions from the community? Oh, I'm always taking other contributions. We've only had a few small ones so far, but yeah, if anybody else would love to, I'd be happy to receive input. I'm curious if you've done any performance

testing for how well it scales up. So the performance testing I've done so far was only on one machine, and so we've scaled it up to, I think, 64 physical cores. And yeah, so far so good. The feature that I was most interested in scaling up was the automatic parallelization. And so if you give it single entry, single exit sections within the graph, because I guess I skipped that part. So the raft library looks at the application as a directed graph.

And so the user gives it out-of-order hints as the user is constructing the application itself. And so the runtime can look for single entry, single exit sections of the graph that are allowed to be out-of-order. And so it doesn't really matter what order the input or the output is. And so it can take those and then duplicate the kernels that are within that single entry, single exit section and basically parallelize the heck out of it. So that's what I was looking for with the scale up experiments. And so far so good.

It does fairly well. It does better when you use the partitioning library, which is another one of those things I pulled out temporarily. And so I've used both Metis and Scotch partitioning libraries and you can partition the application to really take advantage of data locality. And so you partition based on locality and scheduling. And so you want to

schedule things close together that are highly communicative and further apart when they're not. In other words, to spread out the computation and minimize the data movement. Okay. So, I'm sorry, go ahead. Well, I was going to say, so there's one interesting example with the parallel BZIP, which I posted online. I need to go do example with the parallel B zip which I posted online I need to go do a threading building blocks which I just found the implementation and run it on the same hardware and so I just wanted to show how easy it was to construct a parallel B zip with raft lib as opposed

to the classic one that's already out there and then compare the performance across threads it's actually quite good. It actually outperformed the standard pthreads-based bzip. Very good. So, go ahead, Rob. No, I was just going to ask about you're going to have a talk at

C++ now, and is there anything you're going to go over in that talk that you haven't talked to us about yet? Oh, lots. So, I left out all the mathematical details and interesting background stories. And yeah, there's lots of fun, queuing networks and machine learning

and other API stuff that I could definitely talk about. And I do plan on it. I also plan on doing a little bit of live coding towards the end, because I mean, that's really the fun part. Unfortunately, we can't really do that on the air. Yeah, I know. I was disappointed. You've got to figure out a way to do that over audio. Do it in Morse

code. Exactly. There you go. Or have like the old audio modems toned. You could have people pick up a microphone and hold it up. Right. So just maybe for kind of a wrap-up kind of clarification for me, I'm building this mental model in my head

that your streaming library kind of feels like a build tool that has a bunch of files that need to be compiled and a build system can automatically determine the dependencies, parallelize the bits that it can, and then link the objects together at the end. Is that a fair comparison? Kind of, but it's also more of a, I'd say it's a build tool plus built-in OpenMP plus MPI with a way to hook together a computation and not just build it. Right. Okay. Okay. Well, I think that's all I have, Jason. Yeah, I just wanted

to clarify. So you've got Mac and Linux support right now and Windows you're working on, right? Windows I'm working on. So you've got Mac and Linux support right now, but when Windows you're working on, right? Windows I'm working on. So I've got the, uh, I'm working on getting the CMake to build right now, which is fun. So if you want to contribute to that, feel free. Uh, but I might take a look at it after the show. We'll see. Did you have any idea when the Windows port might be ready? I was aiming for the end of March. Okay. Well, you've got a few days. Yeah, exactly.

I'm heading to a conference tomorrow, so I think I will work it on the plane. I'm very close. And I'm assuming this already compiles with GCZ and Clang and Windows retargeting Visual C++? And it's also run through Travis CI for continuous integration. So every push gets checked. Don't forget about AppFair once you get your Windows stuff working. Of course. It's very helpful that way.

Well, Jonathan, it's been great having you on the show. Where can people find you online or learn more about Raftlib? So you can go to my website. It's jonathanbeard.io, or you can go to raftlib.io okay and the repo is on github and you can check it out there right yes okay well thank you so much for having

for letting us have you on the show awesome hey thanks for having me thanks for coming 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.