Day 2 was jam packed with more great talks so lets get right to it!
Most people should be familiar with Jason from cppcast and his talks from various conferences over the last couple of years.
The title of the talk almost led the audience into a the idea that Jason was that exeptions should be used more. At the end the point of the talk was made clear. We should use language features like exceptions as mental tools to make us think about the code we are writing more.
Like a lot of Jason’s talks, there was a lot of focus on the language intricacies that at first seem simple but when you actually break it down, can adversely affect performance. Things like copying std::strings, moving out of a function vs relying on Copy Elision from the compiler and using noexcept specifiers to allow the compiler to optimize effectively for generic code.
The fun things about Jason’s style is that there is a lot of back and force from the audience and allows an open discussion into the way the language works. It’s often illuminating to realize that there are many subtle things in c++ that are going on with functions and objects. With use of the godbolt compiler explorer, we saw that adding noexcept to some functions can make code get optimized away. benchmarks were shown along the way that showed how small changes affected perfomance in the Chaiscript library.
I’m not an expert in exceptions and largely ignore them in favour of simple error checking (enum classes FTW). But this talk is a great resource for making you think about them more, which was the purpose, so he did a good job.
Low Latency c++ for fun and profit
I’d already watched Carl’s version of this talk at cppcon on youtube so this was largely the same but was still good to see again. Carl is also an active contributor to the SG14 group (like Matt Bentley the previous day’s speaker). SG14 is geared toward high performance and low latency (basically Games and Finance, I’d like to add VFX to the mix but there doesn’t seem to be any prominent VFX industry members in the group).
The point of view of the financial trading industry is not on how MUCH processing you can do in the shortest amount of time (throughput), but rather how FAST or QUICKLY you code can respond to some event (latency).
Carl showed various techniques that has proven to him (with measurement to back up his claims) make c++ faster in terms how fast code can run.
It mainly boiled down to Keeping your CPU cache filled with the instructions that you want executed.
The order of error code checking and handling made a big difference. If you check all errors, one by one and handle them then and there, you will be delaying the code that you actually want to run. If you check errors and combine all the flags into one then you can run your code first on the condition that there is no error and handle the error in an else if there was one. This subtle change around can make the compiler order the instructions in a way that you are doing less jumping in assembly and the cpu cache is used effectively.
This is also related to compiler attributes to decorate your code as being more ‘likely to be run’. This gives hints to the compiler which branch you are expecting to be the most hit upon case and again the assembly can be ordered to run that code first. The hardware branch predictor can then go to town and you will get less pipeline stalls etc which equals fast code.
Another technique is to always run all the instructions in a code path in a loop right until the last minute before a buy/sell request is made. There will be a last minute check to see if a request was actually made and then because the previous run’s instruction was there in the instruction cache, the CPU can run it really fast without having to go and load the instructions (that previously would have been flushed from cache) and make the buy/sell. This is similar to how the VR industry deals with latency with rendering latency. The whole rendering pipeline is run to make all the data go to the GPU and at the last minute, the head’s position is updated to make it render the right view (which might have changed in the last 16 milliseconds). This can make a difference to the smoothness of the experience. This isn’t exactly the same as CPU instruction cache but it’s a similar technique of ‘late-latching’.
A surpising thing which can make a difference is to turn off all cores on a multicore machine so that the one core can use ALL of the L3 cache which usually gets shared between all cores. Gasps from the audience. 🙂
Check it out on Youtube if Low latency is your thing.
Trimble – New Zealand
Type-safe state machines with C++17 std::variant
This talk began with quite a big overview on what a variant actually is. Lots of questions were asked and was a good intro for people that aren’t familiar. I got a sense that there was a small section of the audience who wasn’t fully up to date with the standard and where the language is these days.
Nick tried to then show how variant can be used to provide a type-safe way to transition between states vs using a naive manual approach using enums and also an approach using heap allocation and an Object-oriented approach with virtual functions. These types of discussions can being out the language elitists in the audience and this was one such occasion where there was too much focus from audience questions on the comparison with the OO approach due to the difference in heap allocation. I myself did wonder about if the Curiously Reccuring Template pattern and some kind of std::array could be utilized to make another comparison and Nick said that he did look into it. There was even a follow up tweet to address that.
But the point was that variant can provide a compile time way to manage states and allow/disallow states to transition from/to one another. A good point was made about how functors vs generic lamdas technically do the same thing but that functors might be easier to read even though they are defined out of place of where you need them. Lamdas can be written in place but can start to look a little messy. I tend to agree with Nick on this one.
Would have been good to see more complicated examples of states. The example given was a sprite animation that could start with idle, transition to walking, pause and then go back to idle. The only disallowed transition was from idle to paused. This could be caught at compile time so that no runtime state could ever be made to get that transition to happen. This could be important if you are sending someone to the moon or trying to control a plane.
Similar transitions are used in the Unreal Engine and Unity Game Engines to manage animation state transitions which is one of my interests so this was a good talk that I enjoyed.
Also Nick joked that he was going to make the talk hobbit themed and wondered if there were any people from Weta Digital in the room (Weta Digital is the company that created the visual effects for those movies). I work at Weta Digital and worked on those movies. Probably a good idea that he didn’t otherwise I might’ve had flashbacks to working long hours in a dark room for weeks on end.
Smithsoft Pty Ltd – Australia
Postcards from the Cross-platform Frontier
This talk was a brave one as it had LIVE CODING!
It was interesting because Sarah argued that c++ can be as popular as other ‘cooler’ languages out there and can be made to be like a scripting language. Was also interesting to hear Sarah’s experience working on mobile platforms in the years preceeding the release of the iphone.
Sarah used Qt to prove that a twitter client could be made in c++ using the Qt SDK. Then we got a live demo of using Qt to parse data from the web and stick the data into standard c++ containers and display it to a UI that was made using Qt Designer (a helper app to create UI’s visually).
The coding went by without me fully understanding it so I’m not sure I got it completely but the point was that there are frameworks out there that make it easier to do things that other languages can do easily out of the box.
It was touch and go if it was going to compile and run which actually was good to see because it highlighted the inbuilt debugger and syntax highlighting in the Qt Creator IDE. In the end it compiled and ran. I think it might’ve went a little too long but it definitely showed what c++ could be like if it had libraries readily available.
I’ve always been interested in c++ as a scripting language. It is actually possible with cling (a c++ interpreter built on top of the LLVM/clang compiler/toolchain and built by CERN, an organization that built the Large Hadron Collider). And libraries like Chaiscript and languages like Lua and Python show that there is a demand for a quick and dirty c++ scripting language. I personally believe that this is what people want when they ask for c++’lite’ or subset of the language.
So overall the this was less of a technical talk and more of a philosophical one which raised some interesting questions about where the language is going and should go.
Equivalence in cross-compiler warnings