File size

File size

File size

File size

File size

854.7 MB

In 2011, we saw a resurgence of interest in native code - in C++ in 2011 and in C++11. Is this "C++ Renaissance" a flash in the pan? Is it a long-term trend?

This is an interactive panel. This means you, the attendee in the room or online, will be first class members of the conversation - you drive it. You ask the questions. The theme has been provided. Where do you want to take it? It's up to you.

First I think it was an amazing day and made me think alot! I am a game developer (thanks Andrei for the mention and care about locality, cache and cache misses. I don't know if my question will get an answer but here it is.

I was confused by something Bjarne said. I am confuse on how you can talk about the difference between list and vector in performances because of their layout and design and at the same time say that you shouldn't teach student about cache lines, and the low hardware stuff. I think I miss undertstood him but anybody can clarify?

I don't think those need to be reflected on the language but they have to be reflected in the learning material because they are parts of the first things you need to consider when designing librairies, systems, frameworks..., games and applications. I can only refer to all the material about concurrency that Herb put on the net about those issue. I don't see them as optimization but as design. (usually when you are at optimizing it is too late to optimize those things).

I know I am kind of mixing things here like performance of vector and list, with concurrency code, but to me they share some of the same concern. I could call that the reconstructed family of locality memory, which are cache misses, memory layout, sequence iteration, cache lines and caches. I believe that every programmer should know about this because as good compiler will be they will never rewrite your architecture. If one day a compiler change my code from a tree to a vector or a list to vector i would be shock.

So to me it kind of contradict to say you should use vector because of this and that and then say you shouldn't know why. And then I surely misunderstood.

> I am confuse on how you can talk about the difference between list and vector in performances because of their layout and design and at the same time say that you shouldn't teach student about cache lines, and the low hardware stuff.

1. vector and list are massively different in terms of what you can do with them - vector has op[], list has push_front, etc. In contrast, caching effects don't affect what you can write - only how fast it is. (Hardware engineers go to great lengths to preserve the illusion that memory is flat and simple!)

3. The difference between vector and list is very simple to explain - it can be explained to beginning programmers with simple diagrams. Caching effects are not as simple.

4. The difference between vector and list is fundamental and architecture-independent. Caching effects are strongly architecture-dependent (and have changed over time).

5. It is easy to deal with the difference between vector and list - use vector as your default sequence container because it's so awesome. It is not trivial to write code that respects cache lines and so forth.

When I'm explaining vector to beginners, I usually say, "Look, it's contiguous. This is space-efficient, and processors love blasting through memory in a straight line", and leave it at that. That's all you need to know when you're starting out.

The key difference between "list" and "vector" is that, unless I am forgetting some "list" members here, "list" is just plain useless. The right way to do it is shown in boost::intrusive where the list type actually makes sense, and you get remove elements by reference O(1) and have pratically no allocation overhead compared to the vector. In that case, the list beats the heck out of a vector, at least when element counts go beyond some certain threshold, say 1000 or something higher and you DON'T want to traverse this thing frequently... As soon as you traverse a container a lot more frequently than making non-trivial changes, a list is definitely going to suck no matter how good it is...

# Costs for inserting an element at an arbitrary position into a list is O(1). For a vector that is O(n).# The traversal is O(n) for both, but with a much lower constant for the vector. # Now let's consider insertions for the vector in detail. What you do is simply allocating a new chunk of memory with n+1 space and traversing the original vector, copying all elements into the new chunk. All of this costs O(n) with likely still a lower constant than a list traversal. # So what happens now is that if you have a sequence of T traversals and D insertion/deletion and "T = k * D" for a constant k > 0, the vector is still faster than the list, since every list traversal somewhat pays for a constant amount of insertion/deletions in the vector (the overhead) and so implicitly, the vector now also got like O(1) modification performance (amortized). Well the last statement is not really true but it gives you the dist of it ^^. It only holds in this particular setting with the list as reference.

I actually also have a question. Since I came back to C++ the day I heard of C++11, I really like the new features and am kinda disappointed about the varying support, which is a problem especially in my case where I need to be cross-platform.

I was wondering, why even bother to create a compiler ^^. I mean CLang is really outstanding, especially with regards to standard conformance and error diagnostic, as well as tools integration. Why doesn't Microsoft invest in this technology and build a Microsoft Frontend around it, which by compiler option can either enable or disable the Microsoft extension that are required for Windows applications. So we would get nice tools integration, Microsoft would contribute to all the world, and if other big companies, like Intel for one, put their efforts in developing CLang with Apple instead of breeding their own thing, we could probably get a nice, cross-platform toolset that compiles code equally good on all platforms...

Well sorry, I am thinking incrementally, and I have no option for editing posts here :(.

When talking about being native, we also have to mention things like the Microsoft project "Phoenix". What happened to this one? Was it buried in favor of LLVM?! I mean the point is, NET is so slow, because it can't afford all these fancy compiler optimizations. But that is not quite true. It is just not implemented. The creator of LLVM had an internship at Microsoft where he created a NET to LLVM prototype and as far as I remember it could also inline native code into NET and even do interprocedural optimizations between native modules and NET. Stuff like that would be realy great and maybe you guys could talk about it a bit ^^. I mean the whole discussion of being native is kinda pointless if you only consider NET as it as and not as it could be. There is so much room for optimizations and you can't compare it with C++ because NET as it is currently is chained and doomed to be slower...

First of all Thanks for your answers. My question was more about the academic side, what to say to programmers.

I usually say, "Look, it's contiguous. This is space-efficient, and processors love blasting through memory in a straight line", and leave it at that. That's all you need to know when you're starting out.

I totally agree with this, but how long can you go on without giving then the explanation even Bjarne (I re listen to the keynote this morning) didn't gave support to this fact without talking of locality.

Locality is really a generic term that means related stuff from different point of views. For example, and array or linked list ( array has it's memory more local) or caches L1, L2 (L1 is closer to registers than L2).

And this concept is amazingly important. And overlooked to many times. I understood a lot better what to thrive for when writing efficient code, when need be. For fun I asked fellow programmer today how many were told at school how locality of memory (and their different manifestation example: data structures ( vector), memory caches) is important. And for most of it is that they didn't know. Until they wrote creepy slow code/architecture because of caches misses.

My point is, I think those concept need to be introduce to student early enough, so that they can start think how to write with the hardware not against it. And for this reason before they graduate you need to tell them. This was my misunderstanding. How you can say vector is awesome because of memory locality and never teach them why so that they can reproduce this awesomeness.

On personal thought, some will call that early optimization, I wouldn't. This kind of choice in design need to be done at an early stage of a design. You need to know early enough where things will reside, who own what and how you will traverse it. If not at the end it is too late.

# Now let's consider insertions for the vector in detail. What you do is simply allocating a new chunk of memory with n+1 space and traversing the original vector, copying all elements into the new chunk. All of this costs O(n)

Allocating n+1 space is a common beginner's mistake which would indeed lead to O(n) push_back performance. In reality, the complexity of push_back is "amortized constant time", because the space is not increased by a fixed addend like +1 or +10 but rather by a fixed factor like *1.5 or *2.

I'm a bit surprised STL did not comment on this since. Unless I'm mistaken, this issue is one of his pet peeves

NotFredSafe> I'm a bit surprised STL did not comment on this since. Unless I'm mistaken, this issue is one of his pet peeves

I missed it.

thesaint> Nobody is talking about push_back...

What are you referring to, then?

vector always grows geometrically, not arithmetically. This is true for push_back(), emplace_back(), element insert(), range insert(), resize(), everything. The lone exception is reserve(), which is permitted to give you exactly as much memory as you ask for (and typically will), which can trigger quadratic complexity if you're not careful (I've hit this myself).

I am referring to arbitrary inserts, as stated there ;). The point is that the memory allocation is not important. Even if you would reserve all memory in advance, the things I showed there would still hold. I kinda wonder a little bit what's so hard to follow what I have written there. This is simple undergraduate algorithmic analysis. And of course, the vector does optimize it, for example by allocating more than one element in advance. But that is not important since I showed only an upper bound. If the vector does it even better (which it does) so its nice... This make the difference between vector and list even greater.

Or to summarize what I did there at all. I was just proving that an (arbitrary) sequence of inserts and traversals, where both ops are linearly dependend, have the same asymptotical complexity for lists and vectors. And this seems to surprise people, so I proved it. That's pretty much it ;). I thought it would help, but obviously it does only confuse!

Basically, all the work is done by one instruction, the instructions before just set up the operation. This can be cache efficiently implemented, since the processor knows that the whole block needs to be accessed.

Memory allocation is OS / runtime bookkeeping, you don't want to call it very often.

"C++ does not need a garbage collector because C++ coders do not produce garbage"

You should add the adjective "good" to "C++ coders", because bad C++ coders do produce garbage (memory leaks, resource leaks, buffer overruns, etc.). Instead, good C++ coders, thanks to proper use of C++ destructors and quality container classes, have to work really hard to produce garbage and leaks

Probably one of the reasons for the introduction of "managed" environments was to lower the entry barrier in programming for inexperienced developers.

"What kind of an idiot says you cant use C++ in kernel?". I think this was a cheap shot at linus among others who seem to have an irrational hatred of C++

I would say, assembly coders don't produce garbage. bottom line is like C64 said, Use the right tool for the job. no matter it's .net, c, c++, it's all about trade off. it's either maintainability, time to market, cost of ownership, ease of development, speed. just pick one and go with it. however the message is clear now, C++ /11 is coming back, .net will stay low key for a little while or move to retirement mode but then it all depends on how popular c11 will be. nonetheless, it will be quite a bit of learning curve for the .net generation to pick up/brush up c++ again.

@C64: Thanks! It was a great two days and I miss the energy and love in the room. It was so nice to meet so many smart and passionate people.

Putting on a conference is like having a baby: I find myself elated that we pulled it off and also a bit depressed that it's over, but something new and special was born on Groundhog Day, 2012 and that's a great thing. Let's help it live and grow. Let's nurture it. Let's help push GoingNative and C++ in the right direction.

If we do this again, we will have to match (at least) or exceed the very high bar we've established in this first edition of GoingNative. I believe we can do that.

Thanks to all of you who were in the room, in the cloud and watching on-demand. This content represents some of the very best C++11 material you'll find on the Internet. HUGE kudos to the speakers for providing such excellent content. Incredible, meaningful, thoughtful, practical, future-looking talks.

I'd also like to congratulate the in-room and virtual audience for asking excellent questions and engaging the speakers in really meaningful and useful discourse. You really made the energy in the room. Thank you!

Now, what to do... There's C++ NOW! and C++ and Beyond coming up. Both excellent C++ conferences. I know I'll be attending C&B 2012 in August. Not sure about C++ NOW!, but I will try to get there, too. I know it will be an excellent affair. And there's Channel 9. Much C++ content to produce (and some D, too ).

I love Channel9 and I've been with you guys from the beginning. This is such an amazing pool of great resources and content that I've yet to watch everything I find interesting and useful, and I watch a lot of Channel9!I don't think there's any other site with this kind of quality, deeply technical and high level content on the web.

Thanks again, man! And kudos to you all for your great work and effort!

It may be too late, but there's an important (IMHO) question that was not asked here. First some context.

If you look at what managed people are talking about in their conferences (notably YOW 2012), they are using the exact same subjects as native guys do. JVM and .Net guys are more than aware that, locality, caching and lock free structures are the future (and name your other thing talked about in the native world). Their talks are all about how they can achieve great (according to them) performance by only carring on the lower layers where it matters (that is interlocked operations, immutable data, array traversal etc... ) and few parts of the code actually do. In the case of the JVM (at least) they can have dynamic optimizations that are, for now, forbidden to native code (e.g. virtual function inlining).

The lesson seems to be : you don't need to use a native language for the performance critical part, you can hint the VM and the JIT on the difficult part and rely on them.

My questions is this point of view too optimistic for managed languages (and why because I don't think anybody reading this will say 'no' ?

The lesson seems to be : you don't need to use a native language for the performance critical part, you can hint the VM and the JIT on the difficult part and rely on them.

My questions is this point of view too optimistic for managed languages (and why because I don't think anybody reading this will say 'no' ?

Just consider concrete examples.

Top-selling console videogames are performance demanding applications, and they are all written in native C++ code.

VS2010 IDE was rewritten using C# and WPF, and it is a performance disaster if compared to VS2008 (which was written in native C++ code). The fact that VS2010 IDE is slow is preventing several people from using it for large code bases that could be handled correctly by VS2008 (an example can be found in this interview).

C# and .NET give programmers a good level of productivity, but they don't scale up. I can use C# and WinForms to quickly build tools or database front-ends (LINQ and other C# facilities are very good), but for larger software and when performance is critical, I think native code is the only option.

I guess that the guys in finance are interested as much as the guys in video games in the speed of their code.

The point I was trying to make is that the approach for increased performance is pretty much the same in native and manage worlds. It is hard to see where, in theory, the advantage of a purely native language is. Please don't get me wrong, I write C++ all day long, I am just trying to get a better picture of the problem.

[...] It is hard to see where, in theory, the advantage of a purely native language is. Please don't get me wrong, I write C++ all day long, I am just trying to get a better picture of the problem.

I think your request is fair, and I'm trying to get a better picture of the problem as you do.

I see the advantage of native language in practice for power and performance.

I gave you VS2010 WPF IDE as an example. You may want to try it with some open-source very big code base, like Google Chrome. Try loading it in both VS2008 and VS2010, and see the memory consumption and the responsiveness of the two IDEs. Sometimes VS2010 hangs, becomes unresponsive, etc. Moreover, the start-up time for VS2008 is shorter than VS2010.

Note that (at least for me) the build times for VS2008 and VS2010 are almost the same, the problem is in the IDE. VS2010 offers us an improved C++ compiler and improved libraries: but they just deserve a better IDE.

Your comparison of VC 2008 and 2010 is somewhat unfair. You compare a mature design for older platforms with a new technology built with the future in mind. VS 2010 codebase is probably crappier than the one of its predecessor. It happens all the time with major/complete rewrites. I am pretty sure that the bloat comes from this rather than the technology choice. I wonder if VS 11 is developed in .Net or not by the way.

Then, WPF (or any GUI for that matter) is not really a component you'll find in *really* time critical applications (think finance, web servers) and is probably not designed with the same objective in mind.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.