I'm not convinced by this argument - I'd say we should judge a language by what it looks like in that language, not what it would look like when translated into another language. Performance is dependent on factors such as the choice of algorithm, or data access, and I would argue what's most important is being able to write good fast algorithms or arrange data in a way good for performance. If the code looks more complex, it's harder to track down those issues. I'm not convinced that the code that looks simplest in C is therefore the quickest.
Neither me or anyone else made that argument...!...?
The point of mentally translating your C++ code to C code is to be aware of the actual meaning of what you're writing. If you can't carry out this exercise, then you don't really understand C++ and are a danger to your project. In the *specific* example given, you can see that the vtable is simply a completely useless extra layer of indirection, and only serves to force an extra cache miss and a branch misprediction for no reason. In that simple example, then moving the DoStuff function pointer out of the vtable struct and into the A struct would remove these performance costs (and coincidentally make the C code look simpler), however, the typical C++ programmer would default to using the unnecessary vtable implementation simply because it's easy.
Simpler looking C code being faster isn't always the case, but this specific case demonstrates why it's an important mental exercise nonetheless.
Also the point of this straw-man example (where translating to C shows how some typical looking C++ code is actually making retarded performance-decisions) was not meant as an attack on C++, but as an explanation for why Linus might prefer his contributors to write in C over C++ -- i.e. He doesn't trust his contributors to think through their use of C++ features thoroughly. This is a project-specific management decision.
Whilst DOD may be different from strict OOD, it's not clear to me that this is an argument against OO in general, or C++. One can still think in terms of OO, just that your objects are not things like a single polygon or sprite or player, but collections of things like meshes, particle systems or groups of players. One can still take advantage of concepts like encapsulation, inheritance and polymorphism, and one can still write DOD code with C++. On the flip side, it's possible for C programmers to make the same mistake - you still have structs, and one can still make the mistake of arranging data on the level of a single object, in a manner that is poor for performance.
No, this had nothing to do with C or C++. I see DOD being orthogonal to, and often compatible with OOD - it requires an augmentation of your OO designs, and can make use of OOP tools in it's implementations.
N.B. it's not as simple as "OO is single objects; DO is collections" - that's a common manifestation of the core ideas, but not the core ideas themselves.
There can be simpler manifestations, such as taking a typical OO class with many methods, but splitting it into two versions of the same class, each with their own subset of the original methods, and each with their own data-layout that is optimized for its set of methods.
This was more an admission that OO is based on some performance fallacies, and has to be adapted/used with careful thought if its to be used optimally in HPC.