Stroustrup & Sutter on
C++ 2008, Second Showing
October 29-30, 2008 Boston, MA, USA
(Note: This is a repeat of the material in our spring 2008 seminar in
Santa Clara, except that Bjarne is substituting a talk on "C++ in
Safety-Critical Systems" instead of his design and evolution talk.)
This two-day seminar is getting billing on two different conferences that
are running at the same time in the Hynes Convention Center:
SD Best Practices and the
Embedded Systems
Conference. S&S is technically part of both conferences, which
means you can attend S&S via either one… either
and both ways will include options that include our
two-day seminar. Here are the talks:
C++0x Overview (Bjarne Stroustrup)
Safe Locking: Best Practices to Eliminate Race Conditions
(Herb Sutter)
How to Design Good Interfaces (Bjarne Stroustrup)
Lock-Free Programming in C++—or How to Juggle Razor
Blades (Herb Sutter)
Grill the Experts: Ask Us Anything! (Bjarne Stroustrup &
Herb Sutter)
Concepts and Generic Programming in C++0x (Bjarne
Stroustrup)
What Not to Code: Avoiding Bad Design Choices and Worse
Implementations (Herb Sutter)
C++ in Safety-Critical Systems (Bjarne Stroustrup)
How to Migrate C++ Code to the Manycore “Free Lunch”
(Herb Sutter)
Discussion on Questions Raised During the Seminar (Herb
Sutter & Bjarne Stroustrup)
Machine Architecture: Things Your Programming Language Never Told You (Google video) (pdf slides) September 19, 2007 Northwest C++ Users Group, Seattle, Washington, USA Programmers are routinely surprised at what simple code actually does and how expensive it can be, because so many of us are unaware of the increasing complexity of the machine on which the program actually runs. This talk examines the “real meanings” and “true costs” of the code we write and run especially on commodity and server systems, by delving into the performance effects of bandwidth vs. latency limitations, the ever-deepening memory hierarchy, the changing costs arising from the hardware concurrency explosion, memory model effects all the way from the compiler to the CPU to the chipset to the cache, and more -- and what you can do about them. |
Understanding Parallel
Performance Dr. Dobb's Journal,
December 2008. From the article: "Let’s say that
we’ve slickly written our code to apply divide-and-conquer algorithms and
concurrent data structures and parallel traversals and all our other cool
tricks that make our code wonderfully scalable in theory. Question: How do
we know how well we’ve actually succeeded? Do we really know, or did we just
try a couple of tests on a quad-core that looked reasonable and call it
good? What key factors must we measure to understand our code’s performance,
and answer not only whether our code scales, but quantify how well under
different circumstances and workloads? What costs of concurrency do we have
to take into account? …" 
Writing a Generalized Concurrent
Queue Dr. Dobb's Journal,
November 2008. From the article: "Last month, I
showed code for a lock-free queue that supported the limited case of exactly
two threads—one producer, and one consumer. That’s useful, but maybe not as
exciting now that our first rush of lock-free coding glee has worn off. This
month, let’s tackle the general problem of supporting multiple producers and
multiple consumers with as much concurrency as possible. The code in this
article uses four main design techniques: …"
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software, Slashdotted December 2004. In print Dr. Dobb's Journal, 30(3), March 2005. The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency. This is the widely-cited landmark article that first coined the term "concurrency revolution" to describe the turn to parallel hardware and its impact on the future of software.
Software and the Concurrency Revolution (with Jim Larus), ACM Queue, September 2005. The concurrency revolution is primarily a software revolution. Soon all new machines will be multicore, and the difficult problem is programming this hardware so that mainstream applications benefit from the continued exponential growth in CPU performance. |