Sutter’s Mill

atomic Weapons: The C++ Memory Model and Modern Hardware

2013-02-11 by Herb Sutter

Most of the talks I gave at C++ and Beyond 2012 last summer are already online at Channel 9. Here are two more.

This is a two-part talk that covers the C++ memory model, how locks and atomics and fences interact and map to hardware, and more. Even though we’re talking about C++, much of this is also applicable to Java and .NET which have similar memory models, but not all the features of C++ (such as relaxed atomics).

Note: This is about the basic structure and tools, not how to write lock-free algorithms using atomics. That next-level topic may be on deck for this year’s C++ and Beyond in December, we’ll see…

atomic<> Weapons: The C++ Memory Model and Modern Hardware

• Part 1: Optimizations, races, and the memory model; acquire and release ordering; mutexes vs. atomics vs. fences
• Part 2: Restrictions on compilers and hardware (incl. common bugs); code generation and performance on x86/x64, IA64, POWER, ARM, and more; relaxed atomics; volatile

This session in one word: Deep.

It’s a session that includes topics I’ve publicly said for years is Stuff You Shouldn’t Need To Know and I Just Won’t Teach, but it’s becoming achingly clear that people do need to know about it. Achingly, heartbreakingly clear, because some hardware incents you to pull out the big guns to achieve top performance, and C++ programmers just are so addicted to full performance that they’ll reach for the big red levers with the flashing warning lights. Since we can’t keep people from pulling the big red levers, we’d better document the A to Z of what the levers actually do, so that people don’t SCRAM unless they really, really, really meant to.

Topics Covered:

• The facts: The C++11 memory model and what it requires you to do to make sure your code is correct and stays correct. We’ll include clear answers to several FAQs: “how do the compiler and hardware cooperate to remember how to respect these rules?”, “what is a race condition?”, and the ageless one-hand-clapping question “how is a race condition like a debugger?”
• The tools: The deep interrelationships and fundamental tradeoffs among mutexes, atomics, and fences/barriers. I’ll try to convince you why standalone memory barriers are bad, and why barriers should always be associated with a specific load or store.
• The unspeakables: I’ll grudgingly and reluctantly talk about the Thing I Said I’d Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don’t use them! If you can avoid it. But here’s what you need to know, even though it would be nice if you didn’t need to know it.
• The rapidly-changing hardware reality: How locks and atomics map to hardware instructions on ARM and x86/x64, and throw in POWER and Itanium for good measure – and I’ll cover how and why the answers are actually different last year and this year, and how they will likely be different again a few years from now. We’ll cover how the latest CPU and GPU hardware memory models are rapidly evolving, and how this directly affects C++ programmers.

Videos: Panel, and C++ Concurrency

2013-01-15 by Herb Sutter

I’m about two weeks late posting this, but two more C++ and Beyond 2012 videos are now available online.

The first is my concurrency talk:

C++ and Beyond 2012: C++ Concurrency (Herb Sutter)

I’ve spoken and written on these topics before. Here’s what’s different about this talk:

• Brand new: This material goes beyond what I’ve written and taught about before in my Effective Concurrency articles and courses.
• Cutting-edge current: It covers the best-practices state of the art techniques and shipping tools, and what parts of that are standardized in C++11 already (the answer to that one may surprise you!) and what’s en route to near-term standardization and why, with coverage of the latest discussions.
• Blocking vs. non-blocking: What’s the difference between blocking and non-blocking styles, why on earth would you care, which kinds does C++11 support, and how are we looking at rounding it out in C++1y?

The answers all matter to you – even the ones not yet in the C++ standard – because they are real, available in shipping products, and affect how you design your software today.

The second is one of the panels:

C++ and Beyond 2012: Panel – Convincing your Colleagues

From C++ and Beyond 2012, Andrei, Herb and Scott present Convincing Your Colleagues – an interactive panel.

Abstract:

You can’t do a better job if you don’t change what you’re doing, but change is hard.  It’s especially hard when what needs to change is your colleagues’ approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they’re not doing, other times to stop doing something they’ve become accustomed to.  Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you’re proposing.  But how can you do that?

In this panel session, Andrei, Herb, and Scott share how they go about convincing their colleagues to change and take questions from the audience.

Truth be told, the panel ranged widely and probably most of the time was on other topics!

I hope you find them useful.

Java vulnerabilities

2013-01-15 by Herb Sutter

With the help of friends Robert Seacord and David Svoboda of CERT in particular, I posted a note and link to their CERT post today because people have been misunderstanding the recent Java vulnerabilities, thinking they’re somehow really C or C++ vulnerabilities because Java is implemented in C and C++.

From the post:

Are the Java vulnerabilities actually C and C++ vulnerabilities?

by Herb Sutter

 

You’ve probably seen the headlines:

[US-CERT] Java in Web Browser: Disable Now!

We’ve been telling people to disable Java for years. … We have confirmed that VU#625617 can be used to reliably execute code on Windows, OS X, and Linux platforms. And the exploit code for the vulnerability is publicly available and already incorporated into exploit kits. This should be enough motivation for you to turn Java off.

Firefox and Apple have blocked Java while U.S. Homeland Security recommends everyone disable it, because of vulnerabilities

Homeland Security still advises disabling Java, even after update

Some people have asked whether last week’s and similar recent Java vulnerabilities are actually C or C++ vulnerabilities – because, like virtually all modern systems software, Java is implemented in C and C++.

The answer is no, these particular exploits are pure Java. Some other exploits have indeed used vulnerabilities in Java’s native C code implementation, but the major vulnerabilities in the news lately are in Java itself, and they enable portable exploits on any operating system with a single program. …

Some other C++ experts who have better sense than I do won’t add the following bit publicly, but I can’t help myself: Insert “write once, pwn everywhere” joke here…

Video: You Don’t Know const and mutable

2013-01-01 by Herb Sutter

At C++ and Beyond in August, I gave a 30 min talk on the changed meaning of const and mutable. The talk video is now online:

You Don’t Know [keyword] and [keyword]

const means const.

Bonus: mutable is useful and continues to mean ‘already as good as const.’

This is another way C++ has become simpler: const now means what people always thought it meant, and the four-line code example doesn’t need deep analysis at all – it just works.

But we analyze the four-line example anyway as a motivating case to see why and how it works, so we can fully appreciate this new simplification in C++11…

An implementation of generic lambdas is now available

2012-12-20 by Herb Sutter

For those interested in C++ standardization and not already following along at isocpp.org, here’s an item of likely interest:

An implementation of generic lambdas (request for feedback)—Faisal Vali

This week, Faisal Vali shared an initial “alpha” implementation of generic lambdas in Clang. Faisal is the lead author of the proposal (N3418), with Herb Sutter and Dave Abrahams.

To read and participate in the active discussion, see the message thread on std-proposals.

Here is a copy of Faisal’s announcement…

Read more at isocpp.org…

Compatibility

2012-12-04 by Herb Sutter

On yesterday’s thread, I just wrote in a comment:

@Jon: Yes, C++ is complex and the complexity is largely because of C compatibility. I agree with Bjarne that there’s a small language struggling to get out — I’ve participated in private experiments to specify such a language, and you can do it in well under half the complexity of C++ without losing the expressivity and flexibility of C++. However, it does require changes to syntax (mainly) and semantics (secondarily) that amount to making it a new language, which makes it a massive breaking change for programs (where existing code doesn’t compile and would need to be rewritten manually or with a tool) and programmers (where existing developers need retraining). That’s a very big tradeoff. So just as C++ ‘won’ in the 90s because of its own strengths plus its C compatibility, C++11 is being adopted because of its own strengths plus its C++98 compatibility. At the end of the day compatibility continues to be a very strong force and advantage that isn’t lightly tossed aside to “improve” things. However, it’s still worthwhile and some interesting things may come of it. Stay tuned, but expect (possible) news in years rather than months.

That reminded me of a snippet from the September 2012 issues of CACM. When I first read it, I thought it was so worthwhile that I made a magnified copy and pasted it on the window outside my office at work – it’s still there. The lightly annotated conclusion is shown here.

The article itself was about a different technology, but the Lessons Learned conclusion remind us of the paramount importance of two things:

• Backward compatibility with simple migration path (“compat”). That’s what keeps you “in the ecosystem.” If you don’t have such compatibility, don’t expect wide adoption unless there are hugely compelling reasons to put up with the breaking change. It’s roughly the same kind of ecosystem change for programmers to go from Language X to Language Y as for users to go from Platform X to Platform Y (e.g., Windows to Mac, iPhone to Android) – in each case you have a lot of relearning, and you lose understood tools and services some of which have replacements and some of which don’t.
• Focusing on complete end-to-end solutions (“SFE” or scenario-focused engineering). This is why it’s important not to ship just a bunch of individual features, because that can leave holes where Steps 1, 2, and 4 of an end-to-end experience are wonderful but Step 3 is awkward, unreliable, or incomplete, which renders much of the good work in the other steps unuseful since they can’t be used as much or possibly at all.

Enjoy.

Perspective: “Why C++ Is Not ‘Back’”

2012-12-03 by Herb Sutter

John Sonmez wrote a nice article on the weekend – both the article and the comments are worth reading.

“Why C++ Is Not ‘Back’”

by John Sonmez

I love C++. […] There are plenty of excellent developers I know today that still use C++ and teach others how to use it and there is nothing at all wrong with that.

So what is the problem then?

[…] Everyone keeps asking me if they need to learn C++, but just like my answer was a few years ago, it is the same today—NO!

Ok, so “NO” in caps is a bit harsh.  A better answer is “why?”

[…]

Although I don’t agree with everything John says, he presents something quite valuable, and unfortunately rare: a thoughtful hype-free opinion. This is valuable especially when (not just “even when”) it differs from your own opinion, because combining different thoughtful views of the same thing gives something exceedingly important and precious: perspective.

By definition, depth perception is something you get from seeing and combining more than one point of view. This is why one of my favorite parts of any conference or group interview is discussions between experts on points where they disagree – because experts do regularly disagree, and when they each present their thoughtful reasons and qualifications and specific cases (not just hype), you get to see why a point is valid, when it is valid and not valid, how it applies to a specific situation or doesn’t, and so on.

I encourage you to read the article and the comments. This quote isn’t the only thing I don’t fully agree with, but it’s the one thing I’ll respond to a little from the article:

There are only about three sensible reasons to learn C++ today that I can think of.

There are other major reasons in addition to those, such as:

• Servicing, which is harder when you depend on a runtime.
• Testing, since you lose the ability to test your entire application (compare doing all-static or mostly-static linking with having your application often be compiled/jitted for the first time on an end user’s machine).

These aren’t bad things in themselves, just tradeoffs and reasons to prefer native code vs managed code depending on your application’s needs.

But even the three points John does mention are very broad reasons that apply often, especially the issue of control over memory layouts, to the point where I would say: In any language, if you are serious about performance you will be using arrays a lot (not “always,” just “a lot”). Some languages make that easier and give you much better control over layout in general and arrays in particular, while other languages/environments make it harder (possible! but harder) and you have to “opt out” or “work against” the language’s/runtime’s strong preference for pointer-chasing node-based data structures.

For more, please see also my April 2012 Lang.NEXT talk “(Not Your Father’s) C++”, especially the second half:

• From 19:20, I try to contrast the value and tenets of C++ and of managed language/environments, including that each is making a legitimate and useful design choice.
• From 36:00, I try to address the question of: “can managed languages do essentially everything that’s interesting, so native C/C++ code should be really just for things like device drivers?”
• From 39:00, I talk about when each one is valuable and should be used, especially that if programmer time is your biggest cost, that’s what you should optimize for and it’s exactly what managed languages/environments are designed for.

But again, I encourage you to read John’s article – and the comments – yourself. There’s an unusually high signal-to-noise ratio here.

It’s always nice to encounter a thoughtful balanced piece of writing, whether or not we agree with every detail. Thanks, John!