This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. You can watch the full conversation here: https://www.youtube.com/watch?v=uTxRF5ag27A
(more links below)

Podcast full episodes playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4

Podcasts clips playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41

Podcast website:
https://lexfridman.com/ai

Podcast on Apple Podcasts (iTunes):
https://apple.co/2lwqZIr

Podcast on Spotify:
https://spoti.fi/2nEwCF8

Podcast RSS:
https://lexfridman.com/category/ai/feed/

Note: I select clips with insights from these much longer conversation with the hope of helping make these ideas more accessible and discoverable. Ultimately, this podcast is a small side hobby for me with the goal of sharing and discussing ideas. I did a poll and 92% of people either liked or loved the posting of daily clips, 2% were indifferent, and 6% hated it, some suggesting that I post them on a separate YouTube channel. I hear the 6% and partially agree, so am torn about the whole thing. I tried creating a separate clips channel but the YouTube algorithm makes it very difficult for that channel to grow. So for a little while, I'll keep posting clips on this channel. I ask for your patience and to see these clips as supporting the dissemination of knowledge contained in nuanced discussion. If you enjoy it, consider subscribing, sharing, and commenting.

Bjarne Stroustrup is the creator of C++, a programming language that after 34 years is still one of the most popular and powerful languages in the world. Its focus on fast, stable, robust code underlies many of the biggest systems in the world that we have come to rely on as a society. If you're watching this on YouTube, many of the critical back-end component of YouTube are written in C++. Same goes for Google, Facebook, Amazon, Twitter, most Microsoft applications, Adobe applications, most database systems, and most physical systems that operate in the real-world like cars, robots, rockets that launch us into space and one day will land us on Mars.

Subscribe to this YouTube channel or connect on:
- Twitter: https://twitter.com/lexfridman
- LinkedIn: https://www.linkedin.com/in/lexfridman
- Facebook: https://www.facebook.com/lexfridman
- Instagram: https://www.instagram.com/lexfridman
- Medium: https://medium.com/@lexfridman
- Support on Patreon: https://www.patreon.com/lexfridman

C++ is an object-oriented programming language that creates, especially with newer versions as we'll talk about, higher and higher levels of abstraction.

So how do you design, Let's even go back to the origin C++.

How do you design something with so much abstraction that's still efficient and is still something that you can manage, do static analysis on, you can have constraints on, they can be reliable, all those things we've talked about.

So to me, there's a slight tension between high level abstraction and efficiency.

I could probably have a year's course just trying to answer it.

Yes, there's a tension between efficiency and abstraction, but you also get the interesting situation that you get the best efficiency out of the best abstraction.

And my main tool for efficiency for performance actually is abstraction.

You said it was object-oriented programming language.

I said C++ supports object-oriented programming and other techniques.

And that's important because I think that the best solution to most complex interesting problems require ideas and techniques from things that has been called object-oriented, has been called object-oriented, data abstraction, functional, traditional C-style code, all of the above.

And so When I was designing C++, I soon realized I couldn't just add features.

If you just add what looks pretty, or what people ask for, or what you think is good, 1 by 1, you're not going to get a coherent whole.

What you need is a set of guidelines that guides your decisions.

Should this feature be in or should this feature be out?

How should a feature be modified before it can go in and such.

And there's a, in the book I wrote about that, the design evolution of C++, there's a whole bunch of rules like that.

They're things like, don't violate static type system, because I like static type system for the obvious reason that I like things to be reliable on reasonable amounts of hardware.

But 1 of these rules is the 0 overhead principle.

It basically says that if you have an abstraction, it should not cost anything compared to write the equivalent code at a lower level.

So if I have, say, a matrix multiply, it should be written in such a way that you could not drop to the C level of abstraction and use arrays and pointers and such and run faster.

And so people have written such matrix multiplications And they've actually gotten code that ran faster than Fortran because once you had the right abstraction, you can eliminate temporaries and you can do loop fusion and other good stuff like that, that's quite hard to do by hand and in a lower level language.

There's some really nice examples of that.

The key here is that that matrix multiplication, the matrix abstraction, allows you to write code that's simple and easy.

But with C++, it has the features so that you can also have this thing run faster than if you hand-coded it.

Now people have given that lecture many times, I and others, and a very common question after the talk where you have demonstrated that you can outperform Fortran for dense matrix multiplication, people come up and says, yeah, but that was C++.

If I rewrote your code in C, how much faster would it run?

This happened the first time actually back in the ages with a friend of mine called Doug McElroy who demonstrated exactly this effect.

And so the principle is you should give programmers the tools so that the abstractions can follow the zero-overhead principle.

Furthermore, when you put in a language feature in C++ or a standard library feature, you try to meet this.

It doesn't mean it's absolutely optimal, but it means if you hand code it with the usual facilities in the language, in C++, in C, you should not be able to better it.

Usually you can do better if you use embedded assembler for machine code for some of the details to utilize part of a computer that the compiler doesn't know about.

But you should get to that point before you beat to the abstraction.

So that's a beautiful ideal to reach for.

So Where's the magic of that coming from?

There's some of it is the compilation process, so the implementation of C++, some of it is the design of the feature itself, the guidelines.

I've recently and often talked to Chris Lattner, so Clang.

What, just out of curiosity, is your relationship in general with the different implementations of C++, as you think about you and committee and other people in C++, think about the design of new features or design of previous features.

In trying to reach the ideal of 0 overhead, does the magic come from the design, the guidelines or from the implementations?

You go for programming technique, program language features and implementation techniques.

And how can you think about all 3 at the same time?

It takes some experience, it takes some practice, and sometimes you get it wrong, but after a while, you sort of get it right.

I don't write compilers anymore, but Brian Kernighan pointed out that 1 of the reasons C++ succeeded was some of the craftsmanship I put into the early compilers.

And of course I did the language design, of course I wrote a fair amount of code using this kind of stuff.

And I think most of the successes involves progress in all 3 areas together.

2, 3 people can work together to do something like that.

It's ideal if it's 1 person that has all the skills necessary, But nobody has all the skills necessary in all the fields where C++ is used.

So if you want to approach my ideal in say concurrent programming, you need to know about algorithms from concurrent programming, you need to know the trigger of lock-free programming, you need to know something about the compiler techniques, and then you have to know some of the program, sorry, the application areas where this is, like some forms of graphics or some forms of what we call a web serving kind of stuff and That's very hard to get into a single head, but small groups can do it, too it too.


Speaker 0: C++ is an object-oriented programming language that creates, especially with newer versions as we'll talk about, higher and higher levels of abstraction. So how do you design, Let's even go back to the origin C++. How do you design something with so much abstraction that's still efficient and is still something that you can manage, do static analysis on, you can have constraints on, they can be reliable, all those things we've talked about. So to me, there's a slight tension between high level abstraction and efficiency.

Speaker 1: That's a good question. I could probably have a year's course just trying to answer it. Yes, there's a tension between efficiency and abstraction, but you also get the interesting situation that you get the best efficiency out of the best abstraction. And my main tool for efficiency for performance actually is abstraction. So let's go back to how C++ got there.

You said it was object-oriented programming language. I actually never said that. It's always quoted, but I never did. I said C++ supports object-oriented programming and other techniques. And that's important because I think that the best solution to most complex interesting problems require ideas and techniques from things that has been called object-oriented, has been called object-oriented, data abstraction, functional, traditional C-style code, all of the above.

And so When I was designing C++, I soon realized I couldn't just add features. If you just add what looks pretty, or what people ask for, or what you think is good, 1 by 1, you're not going to get a coherent whole. What you need is a set of guidelines that guides your decisions. Should this feature be in or should this feature be out? How should a feature be modified before it can go in and such.

And there's a, in the book I wrote about that, the design evolution of C++, there's a whole bunch of rules like that. Most of them are not language technical. They're things like, don't violate static type system, because I like static type system for the obvious reason that I like things to be reliable on reasonable amounts of hardware. But 1 of these rules is the 0 overhead principle. The what kind of principle?

The 0 overhead principle. It basically says that if you have an abstraction, it should not cost anything compared to write the equivalent code at a lower level. So if I have, say, a matrix multiply, it should be written in such a way that you could not drop to the C level of abstraction and use arrays and pointers and such and run faster. And so people have written such matrix multiplications And they've actually gotten code that ran faster than Fortran because once you had the right abstraction, you can eliminate temporaries and you can do loop fusion and other good stuff like that, that's quite hard to do by hand and in a lower level language. There's some really nice examples of that.

The key here is that that matrix multiplication, the matrix abstraction, allows you to write code that's simple and easy. You can do that in any language. But with C++, it has the features so that you can also have this thing run faster than if you hand-coded it. Now people have given that lecture many times, I and others, and a very common question after the talk where you have demonstrated that you can outperform Fortran for dense matrix multiplication, people come up and says, yeah, but that was C++. If I rewrote your code in C, how much faster would it run?

The answer is much slower. This happened the first time actually back in the ages with a friend of mine called Doug McElroy who demonstrated exactly this effect. And so the principle is you should give programmers the tools so that the abstractions can follow the zero-overhead principle. Furthermore, when you put in a language feature in C++ or a standard library feature, you try to meet this. It doesn't mean it's absolutely optimal, but it means if you hand code it with the usual facilities in the language, in C++, in C, you should not be able to better it.

Usually you can do better if you use embedded assembler for machine code for some of the details to utilize part of a computer that the compiler doesn't know about. But you should get to that point before you beat to the abstraction.

Speaker 0: So that's a beautiful ideal to reach for. And we meet it quite often. Quite often. So Where's the magic of that coming from? There's some of it is the compilation process, so the implementation of C++, some of it is the design of the feature itself, the guidelines.

I've recently and often talked to Chris Lattner, so Clang. What, just out of curiosity, is your relationship in general with the different implementations of C++, as you think about you and committee and other people in C++, think about the design of new features or design of previous features. In trying to reach the ideal of 0 overhead, does the magic come from the design, the guidelines or from the implementations?

Speaker 1: And. Not all. You go for programming technique, program language features and implementation techniques. You need all 3.

Speaker 0: And how can you think about all 3 at the same time?

Speaker 1: It takes some experience, it takes some practice, and sometimes you get it wrong, but after a while, you sort of get it right. I don't write compilers anymore, but Brian Kernighan pointed out that 1 of the reasons C++ succeeded was some of the craftsmanship I put into the early compilers. And of course I did the language design, of course I wrote a fair amount of code using this kind of stuff. And I think most of the successes involves progress in all 3 areas together. A small group of people can do that.

2, 3 people can work together to do something like that. It's ideal if it's 1 person that has all the skills necessary, But nobody has all the skills necessary in all the fields where C++ is used. So if you want to approach my ideal in say concurrent programming, you need to know about algorithms from concurrent programming, you need to know the trigger of lock-free programming, you need to know something about the compiler techniques, and then you have to know some of the program, sorry, the application areas where this is, like some forms of graphics or some forms of what we call a web serving kind of stuff and That's very hard to get into a single head, but small groups can do it, too it too. You

See all Lex Fridman transcripts on Youtube

Bjarne Stroustrup: C++ Zero-Overhead Principle and Object-Oriented Programming