C++20 format library now available in Spanish/Biblioteca de formato de C++20 ahora disponible en español
Should the new Mac mini M1 be called a Big Mac?
For the past week I’ve been enjoying the new Mac mini M1 (with Apple Silicon), and boy, what a thing of beauty.
Externally it looks the same; the back, as has been reported, has less extensibility, but I don’t mind–I use either Thunderbolt 3 or Bluetooth accessories, so no problemo. I paired it with and older Apple Wireless Magic keyboard and trackpad, a Samsung 34″ C34J791 Thunderbolt 3 monitor that can double as a T3 hub, extended storage with a Samsung Portable X5 SSD with Thunderbolt 3 and this thing is fluid.
I also own a 2019 MacBook Pro (Intel Core i9, six-core), and informally they’re on par in terms of performance, but Geekbench reports, the Mac mini M1 beating the MacBook Pro hands down.
I’ve been running versions of IntelliJ IDEA for Apple Silicon and CLion for Apple Silicon. Startup time almost instantaneous from a cold boot. Kudos to Phil Nash, Anastasia Kazakova and team for these great tools.
It took around 3 weeks to receive it since I ordered it, but it was worth the wait–and I wasn’t in a hurry. If you can get your hands on one of these, or are undecided, highly recommended.
CPPCON2020 Plenary Session Review: Performance Matters
This was my favorite session. I must confess that I’ve seen it three times, and had the time to go slowly over the topic discussed: performance.
Emery Berger needs no introduction. Just check his LinkedIn profile, but just in case, his credentials are at the beginning of the session and just the fact that the CPPCON organizers scheduled him for a plenary session is telling: He’s got the goods.
What made this session useful and memorable? On one hand, Emery supports the topic of performance taking a meticulous approach supported by sound math, statistics, data, you name it. At the end of the post I add references that are mentioned in the session.
Chillax, have a mojito
Emery starts the session with a simple example: performance of a given system in the ’70’s, cool ’80’s, and today, but soon things get super interesting. In the past, you gained performance just by…upgrading your computer, right? Of course! Who doesn’t remember those Gateway 486SX computers with 4MB of RAM (and don’t make me go to 386SX, 80286, 8086…)
Moore’s Law right? Dennard’s Scaling, correcto?
Well, with the advent of multicore/manycore processors, things changed, and for the better.
Gains in performance cannot be stated by “I ran it once and it ran better”. Given two systems, A and A’, if A’ performs better and making a claim, what is the reason? Our typical approach is to find opportunities for better code, but why? It shouldn’t be black magic, right?
So, without spilling the beans, this is what you will learn from the session:
- Variance when there are factors that may affect performance
- Data Layout (from code to how it’s really laid out in memory)
- Link order and its impact on function addresses
- Environment variable size (moves program stack)
- Changing libraries
- Running a program in a new directory and its impact on layout
Make sure you check the reference he makes to Producing Wrong Data Without Doing Anything Obviously Wrong!
Furthermore, Emery will introduce you to randomization as a way to eliminate the effect of layout with the Stabilizer tool, and how it eliminates the layout bias. In this section of the talk he references Null Hypothesis, Central Limit Theorem, Student’s t-test and Analysis of Variance (ANOVA), so be ready to do some reading.
Moreover, Emery introduces causal profile and Coz, and how to approach a performance problem. What he exposed reminded me of Control Theory with a feedback loop. I asked Emery in a follow up Q&A about the difference between BPF and Coz, and he mentioned that BPF is an observing tool, while Coz is a predicting tool. I would think they would be a great complement to each other. On verra.
In this section of the talk you’ll be introduced to:
- Experimentation and what slowing down a component reveals
- Latency and throughput
My favorite reference was Little’s Law, which I have used exactly twice in previous projects. A specific resource where it is mentioned–and used–is in Windows Server 2003 Resource Kit: Performance Guide.
Hopefully I got you interested in this session. If you have an hour to chillax with a mojito, I encourage you to check this session. You’ll derive hours of satisfaction following up the papers and putting into practice what you learn.
Word of the Conference
Many of the sessions, such as Emery’s plenary session, and Herb Sutter’s capstone plenary session, make use of the word incantation. Presenters use it to present a non-apparent solution to a given problem. It seems that every CPPCON conference I’ve attended there’s a catchy phrase. We’ll see what next year brings.
References
- Moore’s Law
- Dennard’s Scaling
- Producing Wrong Data Without Doing Anything Obviously Wrong!, Myktowicz et al
- Null Hypothesis
- Central Limit Theorem
- Student’s t-test
- Analysis of Variance (ANOVA)
- Little’s Law
CPPCON2020 Session Review: Back to Basics: Concurrency
Arthur O’Dwyer’s session is a lap around the concurrency facilities present in C++, starting with C++11. He starts the session with a gentle introduction to concurrency and parallelism pre-C++11 and walks you towards the memory model present in Modern C++, then he proceeds by presenting threads, joining threads, mutexes, scoped lock, atomics, shared_mutex, condition variables, counting semaphores, latches, barriers, promises, futures. You get the idea. He goes further by introducing usage idioms for some of these mechanisms.
Ay Chihuahua, Singleton again!
I mentioned in a previous post that Singletons are posible in Modern C++ using std::call_once and std::once_flag. That is explained here, too.
A cursory view of std::memory_order (or if you prefer Spanish, std::memory_order) will give you more details on the different relationships and their formal definitions, synchronizes-with being, IMO, the easiest.
As a side note, if you want a holistic approach for concurrency in C++, be sure you check Anthony Williams’ book, entitled C++ Concurrency in Action, 2nd Edition, and it’ll be a great complement to Arthur’s talk.
I like the fact that CPPCON is devoting time and speakers to Back to Basics sessions. I think they’re much needed and help bring novices or engineers coming from other languages into mainline C++ programming, helping them to navigate intricate–or sometimes historical–aspects of the language and are time savers, or simply help pointing in the right direction.
I also like the fact that Arthur does not make the session complicated. It is a nice introduction and leaves it up to you to dig up deeper on each of the facilities.
The Blue/Green Pattern
I like the last couple of slides defining this pattern. When sliding in new versions or services/microservices/configurations, is important to do it right. In my particular case, this was the highlight of the session and wished there had been more on it, but alas, Arthur was pressured with time. The technique is what I’m interested in, particularly since he mentioned C++20.
In a nutshell, I liked the approach that Arthur had. Easy going, reaching the Goldilocks principle: not too deep, not too shallow, just right. Got an hour to spare? Jump in!
CPPCON2020 Session Review: Test Driven C++
I was interested in this talk by Phil Nash to see his approach with C++. TDD is an approach that, as it states it is test driven (and Phil clarifies that it is different from test first). Saying that, there is an assumption that you know your OOA/OOD/OOP well, along with your SOLIDs, or template metaprogramming well, and so on. So, you don’t abandon any of these well-known and well-learned principles; you rather apply them to converge fast on the things that you need to pass a test. The assumption is that such test is the most important thing to do: it may realize a use case, implement a user story, add a piece of functionality, and so on.
As Phil explains, TDD starts with a failing test. Perhaps you’ve written your base classes or interfaces or protocol classes or abstract classes, or primary templates, or…the name doesn’t matter. The thing is, you start with a test that will fail and write the minimal amount of code to make that test pass. That will bring you to a refactoring opportunity, then you try again until the test passes, and so on. This portion of the talk takes 10-15 minutes, but I say they’re well spent to get the best grasp of the talk.
On minute 17 Phil addresses a question on how to introduce TDD on legacy code, and he’s right: it’s very hard. The reason, which is easy to visualize, is that you must have designed your classes with testing in mind–say, X-Injection (constructor, property, parameter), easy to stub (fake, etc) by writing to an interface (or if you use templates, then perhaps a primary template with partial and explicit specializations). You get the idea. This process can be painful, depending on how well you broke your dependencies.
Enough said. Now let’s check the meat of the talk. As the author of Catch, Phil conveniently makes us of it in the talk–and conveniently, too, CLion has built-in integration with Catch. While the examples are with Catch, what matters are the principles, the approach on how to write the test, make sure it eventually passes, and how to go about working with your C++ code to make the TDD cycle happen.
One thing you’ll notice is that source code and test code are together. That’s a style that Phil uses, and he explains that you can move the code out–hey, whatever floats your boat; you may decide to first write a minimal portion of your class, class template, or other artifact, and then write the tests by including those minimal files, and see how that goes.
What I liked about this talk is that it shows you how to go about TDD in a simple way–I perused through the Catch2 documentation and the framework is simple to use and seems like a short learning curve. The examples that Phil gives are designed to show how to go from test to working code in short iterations, little by little, poquito a poco. Hey, had to use some Spanish.
At the end of the talk, Phil answers some interesting questions. One that he addresses that is very common has to do with design and testing: do you give up design when you use TDD and the answer is a resounding no. Any approach that uses tests–POUTs or Plain Old Unit Tests (you see, I can also invent my own acronyms) and TDD, have evolving designs. You design little by little and adapt the design according to the results that you’re getting from the tests. Approaches that I’ve used in the past tend to do a full design (you could call it an architectural baseline to make it sound cool) that takes longer to do. None of them are wrong and one may make more sense given your particular circumstances. The point here is that TDD is a tool that does not forego design, it simply starts with a different assumption and builds from there.
The question remains, though, what will happen when Catch reaches version 22. Will it be called Catch-22?
CPPCON2020 Session Review: Retiring the Singleton Pattern: Concrete suggestions for what to use instead
The Singleton design pattern has been discussed ad naseaum over the years. Peter Muldoon starts with the motivation for this talk: an occurrence of Singleton in the workplace, oh my!
The premise of the talk, is not whether to keep it, but what to replace it with.
Over the years, I’ve seen people being captivated by Singleton, as some sort of the Highlander syndrome, where “there can only be one”. In Singling Out Singleton, I have a short blog stating that Singleton refers to single state, rather than a single instance, and even provided an option–what I call the Nifty Singleton, inspired by John Lako’s technique, which in itself, if I remember correctly, came about in the C++ ARM book of old. For a modern alternative, one can use std::call_once and std::once_flag, which I don’t consider a singleton, but rather a requirement of the particular problem at hand. You can also resort to libraries such as Boost.
In my particular case, I’ve lived very well without it, thank you very much. Perhaps Singleton should be relegated to the annals of Design Patterns lore and used only pedagogically?
Peter takes a more wholesome approach, tackling different aspects that arise with a replacement. You can “cut to the chase” and go to minute 59 of the talk if you want to, but than would have to back trace to understand the reasons. Some of the problems mentioned go beyond Singleton, and we can all learn from it.
CPPCON2020 Session Review: Back to Basics: Class Layout
There are two types of knowledge: timely and timeless.
Knowing how your types are laid out onto physical hardware is programmer’s gold and it is timeless knowledge. It never leaves you. I would recommend strongly this talk if you work closer to the metal, or if you work with code bases that make use of object-oriented programming–and before you say that OOP is dead, consider digging (and I mean digging) into RocksDB, TensorFlow, and so many other successful open-source pieces of code where you’ll see how layout is important and the amount of OOP code in them.
I enjoyed this refresher on class layout by Stephen Dewhurst, and was pleased to see the use of no_unique_address attribute and the has_unique_object_representations type trait mentioned in the talk (and of course, you can find them in Spanish, no_unique_address and has_unique_object_representations)
But then again, I’m biased. I took a class with Stephen back in 2003 (and the other instructors were Dan Saks, Scott Meyers, Andrei Alexandrescu and Herb Sutter). Stephen has had a lot to do with the success of C++, but in particular, by being an educator and an evangelist.
I used to own his book Programming in C++, and still own C++ Common Knowledge, which I consult when relevant.
Last year, in CPPCON2019, I had a chance to talk to him and catch up. If you see him in a future CPPCON hanging out in the halls after a class or session, stop and say hi. He’s still the same easy going guy.
CPPCON2020 Session Review: The Future of C++ Parallel and Concurrency Safety Guidelines
“I test, therefore I exist.”
Paraphrasing René Descartes, what do you do if you’ve been conditioned from your engineering “birth” to test, and test everything.
This session is a fit for you if you program systems that require safety as one of its most important features (think 911 Public Safety, Avionics, Automotive), if not the most important. Additionally, if you’ve worked on a company that has a development process compliant with ISO 9001, then this session is for you, too.
Having worked for two companies that implemented ISO 900x, I’m very familiar with the intricacies that are needed to implement even simple changes. Often times the issue is not the change, but what it triggers (e.g., a system recertification, or an infinite number of tests; in other words, change is expensive). On the other hand, I’m grateful that such standards exist and that companies follow it.
Michael Wong starts the session with testing this type of systems for parallel/concurrent/manycore/multicore/{add your term here} systems. How do you do it? Well, it’s a tough question to answer.
So, now that we’re trusting our lives to compute systems controlling our cars, planes and toasters, wouldn’t you want to know that such systems have been tested exhaustively and meet standards for safety? Me too.
Enter SIL (Safety Integrity Level), “bins for levels of safety based on effects if the fault is not mitigated”. Reminds me of the Titanic blueprints shown in the movie that water would spill into another level, and another, until it would become “uncontrollable”
Meet MISRA, too, a suite of software required guidelines that you can apply to C++ to develop systems that are SAFE to use.
The slide on Unintended Acceleration brought bad, related memories: we have a Nissan Armada that one good day my wife said it would not stop after she stepped on the brakes. Being the engineer, I said that most likely it was the ABS and there’s no need to step on the brakes repeatedly…until it happened to me, on the freeway. Sure enough, the problem was firmware and there was a recall. Researching on the Internet, I learned of other drivers that had had an accident due to that error (calling it a bug is very nice).
Michael starts with the C++ Core Guidelines, identifying a gap in the rules that have to do with concurrency. Quickly he moves on to rulesets/standards that make more sense–Joint Strike Fighter Air Vehicle C++, MISRA, Autosar.
Ilya takes care of the second part of the session, and he shared the document that they’re working on. That got me doubly interested.
In the past I’ve worked in what I consider large designs using UML, and making use of use cases, business rules, and so on. Having the formality of writing this type of guideline is a lot of work, and I appreciate that effort by Mike and Ilya and all that are involved, whether it is in providing feedback, the definitions and the implementations to detect whether the rules are correctly applied or broken when writing real software.
What I liked about this session is that it is for software that will be running for quite a few years–say, a decade? two decades? You’d be surprised the longevity that your written code may have. I have been, and I wish these types of guides and standards were around at the time.
A virtual “tip my hat” to Michael and Ilya.
CPPCON2020 Session Review: The Hidden Secrets of Move Semantics
I “virtually” attended this session and followed it fully, and went through it again to write this short session review. But then, I’m biased. I have been reading C++ Move Semantics – The Complete Guide, since Nico started publishing the first chapters, and recently posted a minor review for the book. Furthermore, I translated his best-seller, C++17 – The Complete Guide, to Spanish.
Therefore, I was very familiar with the material, and yet, enjoyed the session very much. A cursory review of move semantics–or better, get a copy of his book–will let you derive the most value from this session.
Nico picks up a simple class template where all you want to do is insert elements. Sure. Then he starts peeling away the different ways in which move semantics comes into the picture, what to use, what to avoid, and a number of do’s and don’ts at the end of the session. If you want to learn what the term temploid means, check this out. If you want to overload by a reference qualifier, check this out.
Still controversial for some is the use of universal reference, which I guess is one of those terms that we’ll get stuck with and generate polemic conversations when compared with forwarding reference. Consider the translation of email in some languages (courrier électronique, courriel, correo electrónico). Nah, simply say email. Same here. Unless you want to pick up another polemic term.
You can check forwarding references in cppreference or in Spanish in es.cppreference.
By publishing professional C++ books, Nico is an educator, and do we need more of those. So, if you’re wondering if it will be time well spent should you choose to watch it? You bet.
CPPCON2020 Session Review: Collaborative Development with Visual Studio Code
Julia Reid walks through three main topics in this entertaining session about Visual Studio Code: the Visual Studio Code, CMake and vcpkg trifecta, remote development, including containers, and collaboration using LiveShare.
I did a review on a different session last year (link at the end of this post), and it’s great to see that VSC and CMake enjoy such a close collaboration, and vcpkg gaining ground as a package manager. All is welcome.
If you do remote development, particularly on headless, remote machines, this talk is for you. I’ve been using this feature over the last year and have been really happy–allows me to have a central dev machine and connect to multiple servers at once. Furthermore, this session tackles developing from containers, which I’ll definitely revisit. Oh, and also port forwarding!
Julia also covers pair programming à la mode; that is, virtual. I’ve used this feature once, and mostly to make sure it worked. But, if it floats your boat, go ahead.
What I liked about this session is that Julia peels away the complexity in setting up a development environment using Visual Studio Code that is complete, and covers every aspect of the development cycle, from setting up, compiling, building, debugging, and yes, SCM. As a side note, have you noticed that Compiler Explorer now seems to be using VSC under the hood? Couldn’t help but notice that the Find dialogs look exactly the same. Oh, well.
The C++ extension is now 1.0. Wow, it’s been some time in the making–four years, per the talk, but will check it out. It comes with support for Linux on ARM/ARM64, VC code formatting, and an extension pack, packed with goodies. Oh, and support for Doxygen comments. Will pick them up and show them. Nifty.
Sneak Peek: UI for vcpkg.
Ready to jump in? Enjoy the session.
Tara Raj did this session last year:
Se Habla C++ 