Code::Dive conference report

Wrocław Fountain @Wikipedia

Scott Meyers and Venkat Subramaniam in Wroclaw, November 5, 2014, at a new programming conference? I couldn't miss that!

Additional info: most topics related to C++, one day, 13 presentations, great weather and a beautiful city. What more do you need?!

Continue below to read my report from this great event.

Plan

• Conference
• Presentations
• Scott Meyer's presentations
• Venkat Subramaniam's presentations
• Takeaways
• Summary

Conference

The code::dive conference was organized for the first time. The main sponsor behind this event was Nokia. The organizers managed to gather around 1000 people and I think it is a notable achievement!

The event took place in Wrocław Congress Center at Centennial Hall (Hala Stulecia) which is a nice set of buildings located in beautiful part of the city.

Presentations

Below is my short summary of each presentation I attended. Note that Scott and Venkat have their own sections.

C++ CONCEPTS, by Robert Matusewicz

• This was a short talk about the status and the general idea of Concepts Lite feature. The feature has its experimental implementation in GCC 4.8 and maybe, it will be included in the C++17 standard.
• Robert showed several code examples of the past way, current way and future way of generic programming. In short, we would like to have a way to express more details in terms of types requirements:
  • template<Sortable Cont> void sort(Cont& container);
  • concepts add special keyword resquire that puts some requirement on a type in a template.
• I wish this talk had been a bit longer and contained more interesting information.
• Additional info about Concepts: Concepts Lite: Constraining Templates with Predicates—Andrew Sutton, Bjarne Stroustrup at isocpp

SEEING THE BIGGER PICTURE -- PART II, by Andrzej Krzemieński

• Andrzej (from akrzemi1.wordpress.com/) prepared actually the two parts of this presentation. I was only at the second part.
• The presentation described how to handle errors in our applications. Sometimes a simple mistake can cost you a lot.
  • If our app calculates weight of a plane, we cannot simply return -1 as an error weight!
• We can throw an exception. But where should we catch it?
  • Ideally our application should contain only several meaningful catch points - usually at the beginning of the module.
• Our application can crash and often it's much better that computing a totally wrong result.
• Nice talk, with a story behind.

THREADING: DOS AND DON'TS, by Bartosz Szurgot

• Energetic talk about potential problems with multithreading
• False sharing, why it can block scalability of an application.
• Alignas keyword and how it can help:
  • We can use it to be sure that other variables will not occupy the same cache line.
• Why volatile is bad
• Interesting talk, some overlap with Scott's topics on CPU caches. For some people the presentation might have too fast pace.
• Bartek's blog is located here

Others

Unfortunately, because of collisions I skipped three potentially interesting topics:

• "HOW TO BUILD ARCHITECTURE OF YOUR SYSTEM?" by Jaroslaw Palka
• "WHAT IS A GOOD CODE?" by Bartek Kuczyński.
• METAPROGRAMMING IN C++ by Sławomir Zborowski

If time allows I need to watch in on the code::dive site.

Scott Meyer's presentations

This was my first time I've seen Scott's presentations live. I like not only the technical side of his talks, but also his style. I was not disappointed! Even such potentially boring topic like 'caches' was done in a funny and interactive way. And what's important, a lot of knowledge is memorised.

I hoped that Scott's new book Effective Modern C++ will be available somewhere at the conference. But unfortunately it was not in print yet. So, unfortunately, I got no signed copy.

CPU CACHES AND WHY YOU CARE

• This is actually a well know presentation. On Scott's site I've noticed he started doing this material around 2010.
  • another link: www.aristeia.com/short-courses.html#cpucaches
• Perfect introduction to the topic of CPU caches.
• He showed matrix traversal example in the beginning.
  • Row major order is doing much better than column major order. Why is that? CPU should do the same amount of job (we visit the same number of cells), so why there is a difference?
• Then, there was an example about scaling a simple problem: calculate number of cells in a matrix.
  • When a array of global variables is used (each thread updates its assigned global variable) even using 20 threads/cores we get only 40% of the speedup! When using below 10 threads the performance was even worse than single threaded version! Why is that?
  • But, when instead of global variables we use a local ones (and make only one write to global variables at the end of calculation) we got a perfectly scalable solution: for 10 threads we get 10x the initial performance. for 20 threads we get 20x speedup.
  • each thread has it's 'own' global variable, so no conflicts should occur. So why we lose the performance? Why local variables help?
• After examples we got into CPU architecture and Cache hierarchies.
  • System memory is veeeeerrrryyy verrryyy slow! The more data fits in cache the faster code can run.
• Then we could answer questions introduced in the beginning.
  • Row major order is faster because we can use caches effectively. When we read one element from a row, the following elements are also fetched from the main memory (one cache line is always read). So when we access the next cell it's already in the cache. Next element in this order is located in consecutively in the memory.
  • Column order: one element is read into the cache (along with the following elements in a row), but then we lose that cache line when we move to another cell. Next element in this order is located in the memory i+RowSize.
  • Counting problem: global variables, although not conflicting with each other might share the same cache line. CPU cores in order to keep cache coherent invalidates not single variables but whole cache lines. So each time one global variable is updated then all the other variables (in the same cache line) are invalidated and this make things so slow.
  • When we use local variables then there is no false sharing problem.
• As for the summary: small code is fast code.

SUPPORT FOR EMBEDDED PROGRAMMING IN C++11 AND C++14

• This is a new presentation that shows modern C++ features especially helpful in embedded programming. Still, those concepts might be useful in 'normal' code as well.
• Scott covered mostly auto and constexpr. He tried to introduce enhanced enums but there were too many (sometimes simple) questions from the audience that decreased time for the presentation.
• Auto - it is a well covered topic, but several things caught my attention:
  • Most of the time we should prefer auto over a explicit type when declaring a variable.
  • auto is not only the faster version of writing types but also prevents us from doing errors.
  • For instance: type 'shortcuts' or 'close' types: like short and int. When you use auto you will always get a proper type.
  • Code example: int s = vec.size(). int is close, but not the best type for size_t.
  • Auto will also automatically work in 32 to 64 bit upgrades: for instance auto s = vec.size(); will work properly under 32 and 64 bits.
  • Mandatory initialization: when you use auto your variable must be initialized. That way you reduce chance of using initialized variables. Quite important point!
  • auto is also preferred way of storing lambdas. Each lambda has, usually, a compiler dependent type, std::function is actually the closest approximation.
• Constexpr - another interesting feature of C++11/14. Basically constexpr adds pure functional meta-language that is executed at compile time.
  • In embedded environment this might be useful because it allows to move more data from RAM to ROM.
  • It simplifies template meta-programming so it will be very useful in that area.
  • C++14 relaxes constexpr rules so it can behave as almost normal function.

The interview

Here is the interview from code::dive with Scott:

Venkat Subramaniam's presentations

I haven't s meet Venkat before... I know - such a shame! I was not aware that a person can make such energetic and inspiring presentation! His style is unique: lots of funny stories, examples, live-coding, no slides (only text editor!). You should see it yourself.

BTW: Venkat is author of several interesting books about Agile, Java, Functional Programming, Groovy and even more. For instance: Functional Programming in Java, or Practices of an Agile Developer

CORE PRINCIPLES AND PRACTICES FOR CREATING LIGHTWEIGHT DESIGN

• We went through several very important topics that can make software much better: this was mostly SOLID principles, YAGNI, DRY and SLAP.
• He asked an important question in the beginning: who writes terrible code? It's easy to judge people and say that "they write that horrible code...". In fact, we have to take responsibility of our code and try to improve it. No one is perfect.
• another one: If you see a very long method, what do you do? usually people add a new code to that... making it even longer.
• Why they do that? Because they are lazy... and also because they are afraid: afraid that they will spoil something.
• That is why unit tests (and other tests) are so important! Make that change, run tests, if they pass that means your change is great.
• If you do not have tests you cannot be sure and you are less enthusiastic about making refactoring and improving code quality.
• First rule: DRY - Do Not Repeat Yourself. Copy and paste pattern should be treated as a crime ;)
• Second: YAGNI - You aren't gonna need it. Write code that is good not perfect. If you need only a simple solution why you want to create a generic solution that handles all possible cases.
• SOLID design:
  • SRP - One of the most important rule. Your object, methods, functions should do only one thing. If your class contains 30 methods - are you sure they are related to only one responsibility? Maybe such class needs to be divided into smaller types?
  • OCP
  • LSP
  • ISP
  • DIP
• SLAP - Single Level Of Abstraction. What is the best size for a method? 5 lines? 7 lines? 20 lines? If you use SLAP then you might have an answer for this question. Just keep the same level of abstraction in a method.
• At the end Venkat told a story about his visit in Norway and how he learned YAGNI and SOLID from a receptionist.
• Another advice from Venkat: if you want to be better organized in your life you need to get wife ;)
• I cannot easily count how many times people (including me) laughed. This presentation was great!

FUNCTIONAL PROGRAMMING? TECHNICAL REASONS TO ADAPT

• Venkat showed why functional style of programming might be useful.
• it can not only help with much better and cleaner design, but also with better scalability in multithreaded environment.
• important concepts:
  • immutability
  • functions as first class citizens
  • function cannot have side effects: This helps a lot in unit testing. If you have a void Do() that calls 100 different singletons or global objects inside it's quite hard to reason about such code. Instead just make your function as 'pure' as possible.
  • functional style can produce code that can be potentially easier to read
• Venkat claimed that when we are about to write a for loop we should feel dirty ;)

Takeaways

image from Wikipedia

• Multithreading is hard, especially if you want to squeeze the performance
• If you have some basic knowledge of CPU architecture then slowly you can properly manage multithreading code.
• Think about errors in your app, do you handle them in a right way?
• Prefer auto than explicit type specification. I need to read Herb's comment on that.
• Practice with SOLID, YAGNI, SLAP and DRY principles.
• Take responsibility of my code. Maybe it's not that perfect?
• Functional style of programming might improve the quality. It can be mixed with normal style.
  • For instance: try to make 'pure' functions, with as little side effects as possible (ideally with no side effects at all!)
• Get wife! But what if I have one?

Summary

Great conference and I would love to attend next year. I hope Nokia (or maybe others sponsors) will decide to host this event in 2015 as well.