C++ and Beyond 2011: Herb Sutter - Why C++?
- Posted: Sep 07, 2011 at 9:47 AM
- 167,410 Views
- 115 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- High Quality WMV (PC, Xbox, MCE)
- MP3 (Audio only)
- Mid Quality WMV (Lo-band, Mobile)
- High Quality MP4 (iPad, PC)
- MP4 (iPod, Zune HD)
We proudly present Herb Sutter's opening presentation at C++ and Beyond 2011. Thanks to Herb, Scott, and Andrei for allowing C9 to film this and air it 
Here, Herb Sutter answers the question "Why C++?" in his usual thoughtful and well-articulated manner. He shares his perspectives on C++11 (yes, the name of the next version of C++ is officially official now!) and the C++ Renaissance as well as why C++ still matters and will continue to matter far into the future. This is a great introduction to the current state of the language, including a glimpse into the future of general purpose, performance-intensive, power-friendly, powerful native programming. As Herb says, C++ has legs and will continue to enable us to run fast into the future.
Download the slides for this presenation
Tune in. Go native!
Follow the Discussion
Very interesting video, definitely a must watch for every developer!
Telling us how great is C++ is nice and all, and I would really like to thank Channel9 and especially Charles for taking an interest in the native zone and for starting the Renaissance campaign, but what would be really great is if we could see the more technical talks at "C++ and Beyond", what I'm trying to say is that pep-talks are nice but knowledge is better.
Making C++ more productive is simple, just make IntelliSense work with C++ as in C# ^^
that's a good question! WHY C++?! who cares really?!
@KikiAlex: You're welcome!
Fair points. This talk, however, is really meant to showcase why it is that we keep talking about C++ around here. It's about time we do that, too. You've not heard this perspective before - not on C9, anyway. It's well worth the watch/listen.
In terms of the more technical sessions from C&B 2011, we most likely won't be airing those here (or anywhere, for that matter). There are plenty of good reasons for this and we don't have to share what they are
You will see more technical, narrowly focused C++ content on C9. Have no fear.
C
Very interesting stuff! But the conclusion really hits the mark. Not the syntactical sugar, meta data, garbage collection or any other nice things in managed languages like c# (which i know) makes managed code so important. The .NET-Framework with its huge functionality in this user-friendly way is the real value.
Creating a library like the .Net-Framework for nativ code with respect to the performance, that c++ developer expect, standardize this, and mix it with some little improvements to the ide for c++ (like announced für VS vNext) will eliminate the need for a .Net-Framework, c#, vb, etc. in many cases (even though i like c# for UI-programming or to try something out in a quick and lazy way).
I spent many years writing SSE-optimized numerical and imaging code in C++. After moving to C# and the .NET framework I swore I would never go back to that tedious, error-prone and mind-numbing endeavor. I can understand why Apple and Google would stick to C++ for mobile apps, but when it comes to developer tools Microsoft should be held to a higher standard. I expect more from them than just sprinkling some foo-foo dust and syntactic sugar onto C++ and claiming its the future. The speaker points out that C++ has certain benefits over C#/.NET, and C#/.NET has certain benefits over C++. Why then must the solution be to revert to C++? This does nothing to offset many of the drawbacks of this language. Why can't we take C# (which has already tackled - and solved - many of these drawbacks) and start focusing on improving JIT performance and efficiency instead?
Lastly, the speaker draws our attention to the productivity vs. performance trade-off every business must make. I think a 3rd factor (closely related to productivity) would be time-to-market. This is especially true for mobile app developers where a particular domain quikly becomes saturated with me-too offerings. In the case of productivity vs. performance vs. time-to-market, .NET wins hands-down for most shops.
Please...computers are supposed to get easier, not harder.
Herb should probably add to his points about how the new C++ will help developers from having to build abstraction layers. Back in the day we were building our own private libraries (mostly on a smaller scale and specific to a vertical market) then Microsoft came along and committed some dedicated folks to creating the .NET libraries on a large general purpose scale. Our not having to re-invent libraries with each job/career/vertical change is the elure of .NET (managed or not).
It would be interesting to see a cost analysis debate between the .NET and C++ camps.
@LKeene: Responding to your points in order:
* I imagine writing SSE-optimized numerical and imaging code in C# would be significantly worse than tedious, error-prone and mind-numbing :).
* C++11 isn't a Microsoft language, why are you complaining about them putting sugar on C++? (Especially given that a lot of the 'sugar' is improving expressibility by orders of magnitude.)
* Who's saying the solution is 'reverting' to C++? I've only heard 'upgrading' to C# isn't always an upgrade.
* A lot of the reasons why managed languages shouldn't be used in a situation is that by *definition* you can't control certain aspects of the execution of your program: when you have a goal of *always* putting a frame on screen in 16ms, you don't have the luxury of letting the runtime figure out when to remove garbage, for a simple example. In other cases, you could use a managed language, but you're not buying yourself much, and in others, there is no runtime to run on!
* Time-to-market is included in productivity.
* As someone who literally *needs* to use C++ (though unfortunately not for as sexy a reason as a game), I love that my job is being made easier and more fun.
Those are good points you raised Simon. I don't want to turn this into another programming language "religious war". I think what I said can be boiled down to: Microsoft has not been aggressive enough with .NET runtime performance and that has forced people to look elsewhere when developing super-snappy software. They've done some things to automate threading, which helps, but that's about it. They've been beaten to the punch by the Mono project which released SIMD extensions to their runtime (with an automatic fallback) 3 years ago:
http://tirania.org/blog/archive/2008/Nov-03.html
And now there's even a tool for pure managed jitted GPGPU in .NET:
www.tidepowerd.com
I guess I would have liked to have seen Microsoft do some of this. And you're right...for stuff that has to run in a deterministic time-frame native is the only game in town. I should add, though, that theoretically a jitted language is ultimately supposed to perform better than a statically compiled one as the compiler is aware of the computers state at each moment. This is the promise, anyway.
@Charles. I don't expect all of Herbs hard work and experience for free on C9 but don't be all denfensive about it. If it's simply that if Herb gave all his talks for free then nobody would pay to go to his conference, then why not just say that. That sounds like the reality and is all very reasonable. :)
Herb's talk is interesting as always. I've been asking MS for a ages now: "why the sudden C++ renaissance at MS?". I mean, MS all but abandoned its C++ customers in the past IMHO - for C# - despite the asbsolute hounding protests of everyone else. Then suddenly MS returns acting like C++ is its long lost best friend! Herb answers "Why" in his talk but there are other translations of what he says.
The glaring absence of C++ from the the Windows Phone slide is surely there to amp windowsbuild rumours that a Windows Phone C++ SDK is coming. Also, I agree that a 100% .NET O/S can't yet power both mobiles and datacentres efficiently, but MS's C++ renassance is really about sucking C++ apps into the cloud and why C++ friendly HTML UI libraries (another windowsbuild rumour) are now required for that. Windows Phone will be a testing ground/path for those things until windows 8 gets here and finishes the job off. But the renaissance is really about Microsoft realising that it now needs C++ apps locked into Azure clouds and that (as Herb says) C++ apps will reduce the hosting bill for MS a lot more than C# ones will! There was me thinking that MS was now listening to C++ customers purely out of the kindness of it's heart?! lol
@Glen: Sorry, Was trying to be funny, not defensive!
C
I have been a hobbyist C# programmer since VS 2005. Long story short it inspired me to go back to college and become a professional developer. I get out of college and what do I do? I get a job as a MFC C++ programmer. Hated it for the first week or two, I mean hated it. Then I started to like C++. Actually liked it a lot while creating non UI logic. But then came the day when my boss put me on UI projects. Just getting a label on the stinking screen is horrible. Trying to get text into or out of it.... Wow. Speaking of text... there are like 3-5 different types. C++ as a language is right up there with C# in many respects but interacting with C++ based UI is the deal breaker. I got a call from a .Net web development shop and jumped boat. That's my story, probably a very common one.
Interesting stuff. I guess Microsoft will be pushing more native development with Windows 8...
That's exactly point number 2 on my //BUILD/ predictions. http://janhannemann.wordpress.com/2011/09/07/placing-final-bets-build/
Am I the only one who thinks it's faulty logic to show a pie chart summarizing the expenditure of a cloud-based provider, say that the investment in people maintaining the cloud (sysadmins and so forth) is so small that it's not even in the chart, that 87% of it is power and power-related, and from that conclude that developer productivity will matter less in the coming decade?
Wouldn't you have to include the cost of all the software developers in all the companies making the actual software that runs on the cloud to make that argument?
Hi Herb,
Your talks and articles are always are pleasure and enlightenment because they are so thoughtful and articulate.
I am a C++ developer. Few years back in 2007 I was very concerned about the future of C++ because of the lack of new projects being undertaken in C++. Most of what we had in C++ is the databases, directory servers, OS, compiler (but pretty much in maintenance phase) Not much of new projects implemented in C++. However, my experience over these few years tells that the trend has indeed started to reverse. Especially in the demanding and emerging industries like data warehousing, mobile apps, cloud computing, efficiency ( perf$(W|T|C) ) is of paramount importance.
I have a question though. Hadoop which is developed for handling and querying petabytes of data. It is written in Java vs Google MapReduce written in C++. Do you think some day they will also have to embrace C++?
Thanks.
Thanks for the shout-out
The IE ATL add-in was an interesting experience. I'd still like to see C++ evolve so there's not so much ceremony to do things like the add-in. That might be part of what you take on for the additional performance and power, or that may just be my own lack of knowledge of modern C++.
Either way, good talk.
Pete
44 minutes? Here's a summary of the spirit of C++11 in two sentences: http://2.bp.blogspot.com/-rsGjOdeF6eU/TZtp6jdbliI/AAAAAAAAACk/QxCPb0gA2L0/s1600/holygrainotdead.jpg
Great talk! Here's a summary that recaps on the main points: http://www.alejandrosegovia.net/2011/09/08/herb-sutters-why-c-talk-sum-up/
All these stuff before BUILD can be a sign. not a good sign for .net peeps like me
I wish Windows 8's new UI used C++ as the preferred development language instead of HTML and one of the cofee-based languages, Javascript.
Could not resist. The allusion to Lord of the Rings: The Return of the King is great. Keep it up, Herb, Scott, Andrei.
Silverlight video player? Really?
Anyone got a link for a decent video?
Software development at the cross-roads between the use of managed languages and the renaissance of C++ and Javascript.
Great video with historical insights into programming languages evolution, global warming implications, Moore's law, multi-cores and performance vs. productivity software development paradigm.
Thank you @Charles for keeping the dialogue open. We are living very exciting and interesting times!
@SpeculationAndFear: This talk has nothing to do with "Windows 8" or the BUILD conference... I'm sorry that you have to guess about the future, but you really are wasting your time making up stories to suit your fears - though it is understandable that all this C++ content on C9 has you scared (if you're, say, a .NET developer).
The C++ Renaissance is not nor has it ever been about the end of something else - like .NET, for example. I thought we made this crystal clear when we first unleashed the terminology on C9. It's simple, really -> For too long we have ignored native languages like C++ and, more importanly, the developers who use them. This is no longer the case and will continue to no longer be the case..
C++ is a powerful and rich language that has been modernized in C++11. This fact has absolutely nothing to do with the status of other general purpose languages which evolve according to their own schedules, user needs, etc...
There will never be one tool to rule them all.
C
Mr Herb do you know what real-time means?
C++ is designed to be IntelliSense-impossible b/c of all those macros it inherits from C.
When you have a bunch of #ifdef or #ifndef around IDE cannot tell what those MARCOs really mean so it cannot intellisense them for you.
ahermm..?
50:ish minutes of a c++ sales pitch in a c++ conference anyone else see the redundancy here ?
All of us c++ devs, i hope, already know why c++ is so great so this talk is wasted time.
I don't see the point in this talk, i think it's stupid in the context of C++ and beyond.
Though i think the windows 8 devs would need to see it, at least twice.
w8 is going down the crapper like vs2010 with all the very slow tech microsoft is yet again force feeding us with.
Html apps using IE tech (just that alone runs a shiver down my spine), more .net bloat, etc..
I think microsoft have adapted a basterdiced intel tick-tock schedule:
vista (tick) - w7 (tock) - w8 aka vista again (tick)....
You get to wonder if they do this just so they can say in next release that they have improved the speed and performance.
Do they think we forgot they messed up the performance in the first place ?! Revolting
@Mr Crash: Whatever. Crash...
C
@SpeculationAndFear: It's totally understandable .NET people worry if windowsbuild means the end of .NET, WPF, ASP.NET or their favourite technology. Only recent history needs to be looked at to see how MS treated C++ developers once MS *decided for us* that C++ had no future (see herbs quote about manged interfaces) - C++ support fell off a cliff, despite MS denials. Even getting basic resource editor changes or dare I say it, dialog boxes changed to resizable, was an impossible request for MS after that. Not only were things not added, but useful C++ things were removed! So if MS can do that to C++, when it is used in most of their own products, and against huge public backlash as well, then anything is possible.
@.NET developers: As it happens, I can't see .NET going away, it has its place. I think windowsbuild will simply make C++ an equal partner on the playing field, which it should have been all along. What happens after that is up to developers, but at least C++ guys can play without having one arm tied behind their back and use what they know and prefer - freedom, if you like.
I just want to see MS support developers, not shoe them down roads they don't want to go by a) forcing them to use technologies they don't want use or b) forcing them to rewrite code they are happy with by neglecting them. I think if MS doesn't do the right thing this time, they wont get another go at it nor deserve it.
The windows build slogan "Use what you know, do what you've always imagined" seems to suggest MS might understand that now. We will see. I'm keen now to just see what is behind the curtain.
@Crash: Windows 8 looks great to me and the blog is good too!
@Mr Crash again: I get some of your points about Herb's C++ "sales pitch" and I see how one could view it that way. But perhaps you might view it another way: C++ like any other product does actually need some selling, especially when it can be done in a reasoned and fair way from an expert who knows what he is talking about rather than a marketing guy. I would be willing to bet that without people like Bjarne and Herb promoting and supporting C++ the way they do, often for free (like the video above), C++ would have a lot less of a base and we would all now be stuck using a proprietary language on our favourite platforms. People like Herb put the community into the language and that work helps support you in your sales pitch in whatever you do, as well as ethuse young people to pick up C++, which is an old language that keeps re-inventing itself - like all class acts do -ho ho ho.
If only there was something like LINQ for C++, maybe I would consider it for some projects instead of c#.
-Why are you still doing C++?
-The answer is... legacy knowledge.
My skills built for several years would lose a lot of their value if this depreciated language designed more than 30 years ago lost space to more modern approaches, so I'll do everything to keep it alive. Not the best thing to do for the future of software development, but the best thing to do for legacy C++ programmers. I'll try to lure as many new programmers into C++ as possible, so I can continue being a lead developer. Who could I lead if people just left it for more modern approaches? I should switch to a more modern language? I invested too much into my C++ skills for that.
^
The only honest answer.
Well stated. Herb's assertion that almost all the value proposition revolves around performance is a risk. If your app is spending a large amount of time waiting on IO, your gains might be rather trivial compared to the cost and risks associated with unmanaged code. Futhermore, it's naive to believe that C++ has some innate "magical" performance sauce which you simply need to pour out to have your app perform. Inefficient, poorly written code is just that - in any language.
I, for one, do not wish to relive the "bad old days" of buffer overruns, pointers to oblivion, and tedium associated with C/C++ unless it's absolutely necessary.
It could also be argued that many of Herb's remarks around Moore's Law were quite dyspeptic. For example, he does not allude to any innovations in fundamental wafer fabrication techniques such as what we're beginning to see in 3D silicon:
http://www.siliconrepublic.com/innovation/item/23462-ibm-plans-3d-silicon-skysc
Nor does he allude to any innovation in basic wafer materials such as Graphene.
http://www.physorg.com/news125574730.html
It's not a steady-state universe - fabrication techniques and materials will likely change. Long term soothsaying in this area is a very risky business and should not be presented asa priori fact.
Is C++ 11 really innovative, or is it just more "lipstick" on a very old pig?
Frankly, I wish the energy was invested is something really new and truly innovative...
What I want in a future C++ revision: packages (YES! like in java), GPGPU standard basic library/common interface or whatever, deleting all syntax-ambiguities (and if necessary breaking C compatibility), concepts (* yeah!), html inside documentation (C++docs?), and.... dear ISO, please, don't take over 3-5 years to make a revision, goddammit!
@Charles: Well, I believe most of our worries stem from Microsoft's change in attitude toward .NET. Javascript and C++ get plenty of love from a lot of huge companies, but the only giant behind C# is MS.
When we bet our career on C#, wee also bet our career on Microsoft, and it paid off very well for a long time. What happened to C# and the .NET Framework from 1.0 to 4.0 was incredible. Then, since around PDC10, the love from MS for C# seem to have changed, and it only looks to be sliding downwards ever since. Sure, you can say that none of this is taking away anything from C#, these are just additions for other developers, but compare, for example, how much C#-related stuff _ANY_ MIX event had prior to 2011, to MIX11's C#-related content.
.NET is definitely not getting the same attention from Microsoft it received before, and there's no other multi-million dollar company that is seriously interested in developing it, unlike the technologies MS just began to push.
So sorry, but regardless what you guys are saying, I really don't think our worries are without reason.
A year ago, what began as an increased focus for another platform did turn out to cause a lot of harm to .NET developers. I find it very likely, that Microsoft's "C++ Renaissance" is going to take away other potential areas from C# developers, much like the "Javascript Renaissance" took away the web.
http://msdn.microsoft.com/en-us/ff380143
Silverlight is not even listed in the web section anymore, it's in the desktop section now for "rapid application development". Oh, great addition above WPF.
@Glen: I'm not against pimping c++, i just think it's a waste to do it in a c++ conference.
There's a time and a place for everything, pimping c++ in a c++ conference is not really the place.
The talk would fit nicely in a more general programming conference.
Don't you agree ?
@Charles: Still in denial ?
*poke* *poke* 
@Mr Crash: No. This talk is about explaining why the language still matters and continues to matter, an explanation of what this C++ Renaissance thing really means.
Herb isn't pimping anything except, well, knowledge, but apparently that's not really something that matters to you....
Stop trolling this thread.
C
I tend to lean toward the other end of the spectrum for most mobile apps(not all). High performance PC and server apps, I get it. With managed and javascript+html5 generally comes much higher stability and security generally speaking.Not that you can't get this in native code, its just less for free.
If we could solve the issues of GC and jitting the MSIL in a parallel manner on phones than I'd much rather stick to managed there.
I was like "OMG. YES!!!" when Herb Sutter showed the ios, android and wp overview. For one second I believed he is gonna unveil something ("native is coming for wp") right there...
Oh well, I keep dreaming :)
Hi C9, many thanks for this. I'm totally on the C# and F# bandwagon but this has made me think again about c++. I will try and give it a hug every now and and then although it as a habit of biting me.
Using code every day myself to solve problems however, there is a subject that this talk completely sidesteps: correctness and knowledge.
I still believe is much easier to get things right with C#/F# because you're not hunting memory leaks or pointer into the wrong section of memory etc. So although c++ will be faster in the end, for a long time the C# side will be leading the race, and will be probably be further ahead in churning out features while being fast enough.
The other part is knowledge, knowing all about caches and cachelines and prefetching etc is crucial to getting that last drop of speed out of a box. However it takes time to master these concepts and that takes away time from mastering business concepts like finance of math (and may actually lead to people that think the world consists solely of registers and cachelines). Thinking you've mastered these concepts can lead to very nasty bugs that can leave you stumped for weeks, if you notice them. So now to solve an actual problem you need to put a geek and a suit together, that does not always work out too well.
So yes, c++ is getting more love than it has been and for all the right reasons. In data centers and mobile devices, Herb is very right, and I am enlightened. But there is a huge world outside these subjects where C#/F# and other easier, safer languages have a definite edge over c++, this talk ignores that.
Where do people get this idea that a significant portion, or even any portion whatsoever of a C++ programmer's time is spent hunting memory leaks? You don't get memory leaks if you don't manually manage memory. And there is rarely a need to do that unless you are doing systems programming or writing the standard library yourself. In the managed world, that would be equated with writing the JIT compiler yourself. I haven't had a need to type delete or free in my C++ code in years.
@Gert Jan I don't think you saw recently how modern C++ code looks like nor what can be done with it. And as Benjamin said, there is virtually no need to manage memory manually. Libraries are for that. And Benjamin... C# isn't fast enough.
You get the performance advantage over managed languages even if you do not manually manage memory in C++?
@Benjamin, hmm.. even more doubt. I always have to remind myself that a flaw in a technology might be fixed since the last time I looked. This stems from a while back indeed of a service a programmer wrote that we just coulnd't get fixed. have to say that the guy wrote his own routines for comparing two strings, and then got it wrong (for the case where s2 was longer than s1 but identical for the first bit). That one took a while.. When we moved to C# all that nonsense went away and we were flying. Can't blame c++ for that one actually.. Fact remains that c++ is a lot more complicated when compared to C# with the header files and <iostream> vs "iostream" etc. All that I think is really obselete and should be fixed. (Or is it already, then I will have a hard look again
And, as Parker states, how much of the perf advantage do you keep when you use automated memory management? Does anyone have some real life examples of c++ vs C# on windows?
Another point is that the CLR has become very good at code generation exrpession trees etc, does that come as easy in c++? First thing I noticed that compiling code takes significantly longer in c++. C# is much faster. If you quickly generate and compile a model and then run it, that matters.
@gjvdkamp:
Personally, I've never tried to do a performance comparison between C++ and C#. It doesn't interest me much as long as they are comparable. I use C++ because of it's expressive power, and it's portability. Even if C# matched C++ performance, I would still choose C++ for these reasons. I also find C++ more syntactically appealing, and I find reference semantics of languages like C# and Java to be really awkward, although I realize these are things that I would probably get used to if I used those languages on a regular basis.
You are right about compile times. The first time I tried C#, when I hit F7, I was utterly shocked at how fast the compile was after using C++ for so long. But I'm okay with waiting a bit longer to compile what is, from my perspective and for my purposes, a far superior language.
I'll say one more thing about the performance issue. I don't know if you know much about Herb Sutter, but to us C++ devs, he's a well known and generally respected guy. Anyway, he's known for advocating Modern C++ usage, and that means staying away from manual memory management for the most part. So if he's doing performance comparisons using C++, I'd like to assume he's being honest about it and utilizing the techniques that he himself espouses.
On top of that, I do have some understanding of how the internals of the facilities provided by the standard library for automatically managing memory work. And I don't see any reason why performance would increase if I managed memory myself.
@Crash: I can understand you feeling that Herbs C++ sales pitch is a waste of time when a) it's preaching to the converted and b) it wastes time that could be spent on things of more interest to you. That's a fair enough argument.
But I think the argument that works better for me is this one: MS neglected C++ way too much. The fact that MS is having a C++ renaissance at all reflects that fact. For a lot of people, C++ never went away, only MS's support for it went away! MS now wants to come back to the party they left and stole the booze from! I hate it when MS picks a winner *for* me (C#), and I hate it more when they come back later saying "we got it wrong!" and want to be let back in to the party!
In this context, Herb's speech is not just a sales pitch. It's an addmission - that things went too far against C++ (see Herbs report about MS's managed everywhere decree). Herbs speech is also an explaination of *why* MS got it wrong (so we can believe it). Just as importantly though, it's a much needed morale boost to the people who stuck with C++ and an invite to others to join the party and start using C++ anew (excuse the pun). I think that is good for all of us and where better to make such statements than at one of the premier C++ conferences.
For me, all of those messages were very important to hear - besides, Herb had to create some free stuff to promote his show so this fits that bill without giving any other of his secret sauce away lol. Lets be reasonable about this.
To those worried C#/NET will now go away: I don't think it will. C++ and C# both have their place. So let's not make this blog all about language wars. Lets make it about letting MS know they should stop trying to pick winners in language wars and just support people in using what they like - there should be room for all. I hope that is the lesson MS has learned and that appears to be what MS is saying. Charles?
Herb,
Have you considered the excellent Qt libraries as a way to fill the CLR gap in C++?
@parker:
Yes.
@gjvdkamp:
1. Perf wise C# is on average 30% to 70% slower than equivalent C++ app.
2. Compile times? What? I think you're forgetting that we (devs) are creating product for users who don't really care what was the time this app was compiled within. All they want is functionality and performance. C++ deliveres it, C# doesn't. As simple as that.
@Glen:
Couldn't agree more with you, when you say why MS have "their" C++ Renaissance.
@Elazar Leibovich:
Qt has duplicated STL for no valid reason. It also doesn't plan to start using std::thread anytime soon. So it's kind of annoying.
@MrEd: Well put (and you didn't even mention optical/photonic computing).
Even with the new features in C++, it still needs more productivity features, and even when it would have them, they're still all very language centric and IDE features built around that turn out to break easily or be difficult to build/test etc and runtime cost of IDE/analysis features can be higher than with simpler languages.
I thought about if it would be possible to have the full C++ compiler considered as the "HTML4" and then have a "strict"-like subset of the full language and libraries used either solely or alongside in the a project but there's a lot of compromises and hard questions there and seems like high risk vs reward.
Besides Yet Another Language some other ideas could be (from the perspective of "I want to use C# but have the perf of C++ where needed") : take the C# compiler and make it spit out C++, or add a /native switch that turns C# into native code and allows free native interop so instead of making C++ slow with C++/CLI, give C# programs ability to do perf critical parts in native code with zero interop penalty and make the transitions completely static so in the compiled release binary it's seamless where the C# ends and C/C++ begins.
To all those people bashing the performance of C#:
http://www.codeproject.com/KB/cross-platform/BenchmarkCppVsDotNet.aspx
It’s true, most of the features of the C# language aren’t made with performance in mind as the first priority, normally code quality precedes it, and it makes them less suited for performance-critical code, you’re not forced to use them.
I’ve yet to see C++ code whose performance cannot be reached with C# code (disregarding JIT compilation time of course, which can normally be only noticed when starting up the application and it's a small constant lag).
While the quality of highly efficient C# code is noticeably lower than C++ code that achieves the same (you need to use unsafe context, manage memory yourself, revert from using generics etc.) so people normally don’t do it, it CAN be done in C#.
Even for most high-performance applications, in practice, a relatively little share of the codebase is responsible for the actual performance.
If you need write a highly efficient application, in C#, you can write the majority of the code in high quality, and resort to low-quality, high-performance code in the few critical sections. In C++, the quality of performance-critical sections is better (need to make much lower trade-offs in quality), but the quality of the majority of the codebase is lower.
While C# isn’t best suited for high-performance code, it can perfectly be used for a lot of “high-performance applications”, maintaining the same efficiency, and achieving overall better code quality than a C++ codebase.
Not for all applications of course, but for a lot, depending on their critical/non-critical code RATIO.
Really, both languages have their places. Even in the high-performance world.
Oh yeah, forgot, you can actually compile C# into native code so if you want to eliminate that negligible start-up time / memory footprint overhead, you can get around it as well.
@Charles, Since when, expressing one's opinion (even though negative) is a trolling? One have to have right and freedom to do it.
Take a chill pill Charles and relax.
@Dave you have absolutely no idea what you're talking about. And no C# isn't suitable for high-perf code/app. You must remember that C# is nothing else but java, with the difference that it came out of Microsoft and not from Sun.
Poco C++ libraries can be a good start for a native and modern framework.
See http://pocoproject.org/
@KMNY_a_ha:
"you have absolutely no idea what you're talking about."
"C# is nothing else but java"
Those two sentences in the same comment made me choke.
C# (as a language) by now is a LOT more than Java.
First off, you can use unsafe context in C#, which will remove the performance overhead from array-range checks, enables you to use (limited-) pointers, and –if used correctly- removes most overhead from automatic memory management. Even when you’re not in unsafe context, C# generics work different beneath the hood, and perform way better than Java generics for example. I won’t go into the million features in C# that are not made for performance, but increase code quality over Java by an incredible amount. If you seriously thought C# is just like Java, you should read a bit after how it is way different by now, and how much more it will improve in C# 5.0.
Anyways, since you’re just making senseless comments without any basis or citations, and looks like you’re not willing to look anything up, show me some short C++ code (without inline assembly), that you think cannot be done in C#, and I’ll show you the C# code that has equivalent functionality and practically no performance overhead (compiled for Windows).
@KMNY_a_ha: It's HOW one expresses his or her opinions that's the issue... One is free to express themselves here - that's always been the case. It must be done in a respectful manner. It's all we ask.
C
@KMNY_a_ha
Obviously Crash is a troll. His only purpose here is to non-consructively bash Microsoft. Read his profile and you'll see that clearly. On this thread, he non-sensically states that "w8 is going down the crapper", something he cannot possibly have knowledge about. Hence, Troll. He also speaks of being "force-fed" Microsoft products, as if he doesn't have a choice. Surely he is aware of the GNU/Linux community.
C++ is a language with lots of noise in it distracting you from the real logic you are trying to implement. When you code you should not be wasting time defining a copy constructor or assignment operator private just so you don't burn your butt accidentally for example. A language with such kinda bizarre gotchas is a badly designed one and drains energy away from developers.
C++ needs to clean itself up. Get rid of the useless language traps and make it at least intellisense-able and refactor-able FGS. Perhaps we need a language D that has the native perf edge while without the juvenile language goofs.
@Dave
Comparing a few lines of code is meaningless, we should at least compare simple programs as we do not design and write native and managed code the same way (yes this is not about C++ vs C# but about native vs managed code).
What I would like to do with you is to continue what Raymond Chen and Rico Mariani started a few years ago when Raymond decided to write a Chinese/English dictionary reader in C++ and Rico did the same in C#.
The problem is quite simple: given a Chinese-English dictionary file (Big5 format), the application should load its content in an appropriate data structure.
The dictionary contains a list of entries (one per line), each entry consists of the chinese word, the pronounciation and the translation.
Comments (starting with the pound sign) should be ignored.
The dictionary file can be downloaded here: http://www.mdbg.net/chindict/export/cedict/cedict_1_0_t_big5_mdbg.zip
We want our application to:
- execute as fast as possible
- consume as little memory (private bytes) as possible
Here is my first version, written in C++ (not much optimized and no intrinsics nor inline assembly code at this point).
VS2010 project: http://demo.ovh.com/download/0d17ff4700d84bad6ad7d8aa0019a53c/Dictionnary.zip
If you agree to play with me, you are welcome to write a C# (or with any other managed language) version and to compare it with the native version.
Process Explorer will tell us a lot about memory consumption and I think the Visual Studio instrumentation features can be useful to see how long it takes to execute the applications.
What do you think?
@Larry Ray:
What would you suggest, that copying be disabled by default? I'd rather not waste time defining a copy constructor when all of my class' members already know how to copy themselves.
@LarryRay
I agree. Having native code does not exclude a productive and consistent language. Stuff like forward declarations or header files IMHO don't belong in a modern language, a compiler should be able to figure that stuff out on it's own. Now I remember what turned me away from c++. Surely we should be able to have the speed of a compiled native language without all that nonsense? Is that what D is about?
@KMNYa_ha
The remark about compile times was actually very valid in my case because I wrote a program that built models from a DSL. A user would change something, see the result, change something etc. Then these compile times definitely matter, a pause would let users loose their train of thought. For most people this is not a issue tho I agree.
@Glen: I didn't mean to say it's just a sales pitch. It was sort of an historical:ish overview of the c++ language's success in many areas.
Interesting points though when ms did abandon c++ many did try to say to them what a mistake it was. I was one of them.
Technically they didn't say "we were wrong " but they should. Pride and denial is in the way as usual.
Herb mentions many examples of how good c++ is and with this knowledge in mind you can wonder why ms abandoned c++ in the first place. The info was there and clear even back then.
This c++ renaissance ms have started is just to hype up the c++ language before they release new products for c++. So just another business move. It's quite clear.
They only give c++ some love when they can make money out of it.
I really don't like how they treat their c++ user base. Prioritizing ms owned stuff first like c#, as an example just look at what features and tools are in vs2010 and which were pushed to the next release _again_
"I hope that is the lesson MS has learned"
Yes we can always hope but experience with microsoft tells me they can't learn from their mistakes. They just say they have aka lies (so ppl will buy their product) and then they go ahead and makes the same mistakes all over again with a twist.
@Charles: So you still haven't looked up the definition of trolling ? Why, it's just one google search away, sigh.. i'm disappointed in you.
You complain about how i express myself but you do not offer up any suggestions or explanations of what erks you. You take the time to complain but not to explain what specifically erks you. Now how is that really useful to me ?
You complain about me expressing myself "wrong", well right back at ya.
If you want me to consider changing my how i express myself then instead of whining about it you can use that time to instead explain what erks you. It's called constructive-criticism.
How many times do i have to explain this to you ?
You and i have different views of what is respectful, it's cultural differences.
Not everyone thinks like an american you know.....you do know that, right ?
I know americans can be a bit ethnocentric and non-tolerant of different cultures / thinking but come on, please learn already, it's not hard at all.
@Benjamin: "something he cannot possibly have knowledge about."
You just did the same thing to me right now. How do you know i do not have this info ?
Who's trolling now ?
" Surely he is aware of the GNU/Linux community."
I guess you have never work for a company. A business just can't switch like that, it costs more money then to stick with what they have. Use google to learn more about this.
Assumption: Your love to ms is making you blind to their faults.
Any good physiologist would say that is most likely be a bad thing.
I tell it how i see it and what i see is ms doing a bad job and treating it's user base like garbage and only sucks up to them, even lies, when ms needs their money.
I find c# to be a nice little interesting language, I like reflection and delegates, I hate garbage collection, lake of near machine options a.k.a. real pointers, ability to set things in memory as I want, ASM, SSE or other vector extensions, I also hate it's lake of expressiveness(I can only program in an oop manner, no flow-programming,no component based programing,badly designed model for templates and more), but I could live with all of this if it wouldn't be this slow.
I find C++ a good language, it is very expressive, most compilers generate fast code for most CPUs but it has a stiff learning curve and it has some weird syntax sometimes ( type Object::*Name or return_type Object::*FunctionName(type var2,type var3)) and lets not forget template errors(you get a Sherlock-Holmes vibe after a few years) and because of multiple-inheritance compilers have a hard time generating really really fast code and I also don't get any reflection or any delegates or an unified dynamic library system, but for most of the problems I get a workaround, so I find C++ as the language if you want to do any fast, portable, reliable work.
@LordKain:
"Comparing a few lines of code is meaningless, we should at least compare simple programs as we do not design and write native and managed code the same way"
We also design and write code in different ways when we go for performance and when we go for code quality. Also, writing a simple program will be barely comparable to writing a robust application. The C++ code you wrote could very well be C with a tiny modification.
Sorry but I don't have that much time for this.
I'm fine with comparing the effectiveness of a simple custom implemented data structure, or file IO, or other light functions, but not a whole program. Way too many (hidden) aspects that can be optimized there. I'm not familiar at all with the Big5 format neither.
If we compare the effectiveness of the data structure and file IO, we can pretty much deduce from that how the application would perform, written well optimized.
"(yes this is not about C++ vs C# but about native vs managed code)."
If I go for optimization, although the code will be C#, it'll barely share characteristics normally associated with "managed code".
If you want to compare native vs managed practices, then yes, for C++-features performance usually precedes code quality, while for C#-features code quality usually precedes performance, so, as I believe you already know, the C++ way will be faster.
I only said you often CAN achieve high performance with C# in the few places you really need it.
This is so funny!! It's an interview with Bjarne Stroustrup where he totally trashed c++.
http://www.stokely.com/lighter.side/stroustrup.html
After this post on VCBlog, which lists new features of C++11 coming in the so called "vNext" of Visual Studio - turns out there are almost none:
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
...I can't help but agree with this statement of Mr Crush:
"Yes we can always hope but experience with microsoft tells me they can't learn from their mistakes. They just say they have aka lies (so ppl will buy their product) and then they go ahead and makes the same mistakes all over again with a twist."
C++ renaissance??? Where is it?
@ACG
Man, that was a fake interview anyway
@ACG: That interview is fake.
http://yosefk.com/c++fqa/
This fqa however is perfectly real.
@mr crash: I agree with the essence of your last post but your remarks would be more focused and more appreciated by others (including your compatriots), if the "tone" was more respectful (more often) to people like Charles and Herb. Pointing out examples of that to anyone who is as "passionate" as yourself, is, by definition, usually a waste of time, as passionate people usually have to see it for themselves to believe it. :)
If it helps (it helps me at least), remember that Herb is a world class engineer. He has forgotten more than I ever knew. It can be easier to write good than write what you mean without inflaming good people, but do try as hard for both! :) I'm not directing anything at you that I don't direct at myself.
Infact, I am struggling not to be a hypocrite here right now! Watch!
@Charles: you are doing a brave effort of putting lipsick on pigs!
Can I direct you to this fine post from STL: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
Microsoft completely taxes ones ability to be fair to them. I can't believe VS.Next will be missing most of the core C++11 language features I was expecting (according to the link)? Stuff like this makes me feel pretty much suckered every time it happens. In this context <b>I feel Herb's video should have been entitled not "Why C++?", but "Why Microsoft?"</b>
I've watched some of the WindowsBuild conference now and seen some awesome stuff, but so far I think Microsoft is in danger of throwing away so much good work and good will by dropping the ball *again*, on the "simple" things?
How can one not question Microsoft's commitment to straight C++ when Microsoft can produce all of those Windows 8 features, yet still fail to implement sufficiently more of the basic C++11 language features, like the loop construct etc. in the time frame of VS 11? Not even the "final/override" keywords will be finished properly and they were half done already!
Is Microsoft still holding its foot down on the neck of C++ to give C# the edge? That's how it looks. These are features other compilers already have, or will have, way way sooner than when Microsoft will now deliver them. Which is when now?
If they come at all, they will be very inconveniently timed compared to other vendors and at additional expense beyond that for v.next?
Not exactly leadership there!
This makes a mockery of the renaissance and Microsoft. <b>Surely the most important job of a C++ renaissance is to make sure the *C++* part is part of it?!?</b> Come to my party, but I wont be there. Hmmmm. Thanks!
As the premier platform provider, if Microsoft doesn't fully support C++11, they make it harder to justify using those C++11 features on the other platforms that do have them - thereby pulling the whole pack down to Microsoft's lowest common denominator. It invites a cynical perspective that that is exactly what Microsoft plans and wants to happen?
To a layperson, a lot of the C++11 language features represent low hanging fruit in comparison to everything else MS has done since - like all of Windows 8!?! So how did Microsoft fail us again in this regard? It's not about resources, you have the money to pay for those. It's about Will in absense of a resources excuse, surely?
For all the talk of "experience this" and "immersive that", I think <b>"meet customers basic expectations"</b> seems to be the phrase most missing from Microsofts vocabulary? I don't appear to be alone in this point of view.
PS: For windowsbuild I was hoping more for a C++ + HTML freedom more than the C++ + XAML lock in that I can see so far. But I've yet to assess that topic completely!
Your thoughts on all of this, please.
I was really optimistic when these videos started appearing on C9. This all changed yesterday when I saw the post in VCBlog that lists the C++11 features - it's shocking. There's a lot of negative feedback and there will be more, I'm actually wondering if MS will postpone the release of VS to implement the missing C++11 features. I mean that blog post rather discourages buying the new VS.
@Charles:
"For too long we have ignored native languages like C++ and, more importanly, the developers who use them. This is no longer the case and will continue to no longer be the case."
You know, Charles, after seeing just how little of the missing C++11 features you are going to implement in the next version of VS, I just can't see how you can say the above with a straight face.
To be absolutely honest with you, I am fed up with all this empty talk about how Microsoft totally gets that C++ is important and totally hears us on the performance issues with VS2010 and whatnot, yet continues to do almost nothing about it. Everybody can talk. It's what you do that is important. You aren't doing much.
Are you kidding? You should thank Microsoft for finally bringing c++ on par with .NET which it has been promoting all these years. What's the last framework windows developers had for building applications..MFC? Several companies I worked for were thinking of dropping c++ altogether just to use WCF,WPF and all of that. Now everything just uses WinRT and c++ developers can take advantage of all that goodness and finally the Win32 will be able to die a peaceful death.
First, Herb, please, dont tell me anymore about Tom Cruise, really
I understand why MS desperatelly needs to push C++ (or native code in general) back to frontpage for partners and students, as its really nice to prepare for stragetic shift of using computers in all its forms during this decade and up.
But its all about right tools for the job. I like Andres Hejlsberg talks a lot more, as he never was arogant about C++ or native code. He even knows very well something about native code as his TurboPascal and Delphi is native and uses even more effective parameters passing throuhgout whole language than C/C++, the same as win32 api uses
. But in this native(!) world of Delphi, code is often written with "brute force" style, speed is tried to be here due to nativeness of loops, but there almost nobody knows about hashtables, whole library is full of brute force searched stringlists (sometimes hopefully sorted), and why the hell native apps written in delphi feel so slow very often?? They can be badly written, architected - as in any language, including C++, as developers are also often stupid in average. There is very few of them who can do C++ effectivelly, very few - and I myself am not that guy, although I know about machine code a lot too. I simply bet that in real world, C++ will still be mostly usefull for optimizations after good profiling of quite good architecture written in C#/VB (today it doesnt matter) and one perfect example of this is rewritten Windows8 core to have Silverlight(psssst) AgCore merged into WinRT API - its superb to have such thing wrapped for all possible languages (but there ARE added some static metadata even for C/C++ tools, because "no metadata, no tools" ...).
To be nice (and I always want to be), its beautifull what MS does today. Everything existing stays here, even WPF and SL are enhanced for desktop apps, because they will stay here forever, but many more new things are possible and even with C++ against WinRT/XAML/Metro (and probably far more important to extend this with native XAML based user controls, where really native code matters a lot). I believe there wil be also native FreePascal/Lazarus IDE back soon.
Finnaly, as Atmel released his new AVR Studio based on VS10 IDE shell, including GCC and better tools, its time to learn again ALSO C++ quite a bit, to create new "perfectly good idea" devices
.
Thanks Herb and Charles for all your effor for C++ back again.
C++ ROCKS </ET>
Re why doesn't VS11 have more C++ conformance features:
Legitimate question, and we're as disappointed about it as you are. For details, please see the opening 5 min or so of my second Build talk that I gave today (http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T -- not online yet as I write this but should be online within 24 hours) for why we didn't implement more C++11 standard features in this release.
Short version of the answer: We intended to do that and made a serious effort to implement variadic templates in particular, but got caught in a very frustrating trap, despite which we will continue to implement C++11 features as quickly as we can whether they fit into VS11 or soon after. We continue to consider improving C++11 conformance as a Pri 1 feature for our team.
BTW the link is http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T . The page is there without video now, but video should be posted soon.
@Herb Sutter:The video is on and by the way: nice presentation!
@Dennis wrote:
I think that, although the point that Microsoft is better supporting C++ and making it easier to use is valid, Herb Sutter is making quite a stretch to say that it is necessary only due power and performance it provides as compared to "Coffee languages" and trying to make an inference that there is a trend towards a. For example, this trying to show there is a trend towards C++ using smartphones was completely phony, as follows:
1) Apple has always tended to use native code compilers and has a company culture/bias against VM's.
2) If Herb knew enough about the Android Native Development Kit, he would know that it has limits and is not recommended for other than to augment the capabilities of the Java platform (as in to be p/invoked = called through JNI). Google has the following to say: "
".
3) Further, with performace gains made since about five Android versions ago (the first Gingerbread), the NDK has not been updated since, perhaps because it is somewhat less necessary. It is stated that perhaps its main use would be for large bitmap buffers or other memory intensive operations that exceed the current limited size of the application heap space or to augment performance for such specific compute intensive tasks as pixel manipulations.
4) That doesn't a trend make.
Herb conveniently didn't mention Rim's Blackberry's which have always used Java and will likely always use Java.
It also still isn't clear whether Microsoft's Phone OS will allow p/invode calls to native code.
Where's the trend?
As Herb does state correctly, each of the language approaches have their place; however, it is easier to p/invoke to call specific C++ modules from C# in order to enjoy these performance gains where required than it is to call C# modules from C++.
@Dave wrote:
Agreed, but it should be pointed out that using the same algorithms that C# code will be up to about 2 to 2.5 times slower mostly only for very tight loops of only a few instructions or so, if one looks at the generated native code that most of that loss is due to the compulsory array bounds checking with a very slight percentage (perhaps a factor of 1.1 to 1.2) due to better efficiency of the compiler. The array bounds checking is necessary for safe code, so if one has a choice, safe code with C# or when highly optimized the faster but unsafe code of C++.
For instance I wrote a highly optimized benchmark using C that could calculate the number of primes in the 32 bit number range in about a second using one core with most of the time spent culling composite numbers at about 2.5 machine cycles per cull. The C# version using exactly the same array based algorithm respecting the cache sizes of the CPU took about 6 machine cycles per cull. Upon inspection of the generated code, the difference was primarily the C# array bounds check, which could not be written around and still use the highly efficient algorithm.
It should be noted that the original C program from which I derived the work took about 50 times as long as the final C version and therefore about 25 times longer than the final C# version due to not respecting and optimizing the size of the cache and just using a huge linear array rather than paging the work as well as bit compressing the prime candidates; the point being that in any language, well written code using better algorithms for the specific purpose is more important that the choice of language.
@Dave wrote:
Sorry, Dave, although you can use unsafe code context and thus use pointers in C# without range checking, there is (by design) no performance gain in doing this due to there being less code optimization done in unsafe mode: it's about a wash in performance between the techniques.
Unsafe mode is there so that one can do things that might not be possible from normal safe mode, but the reason is never for performance gains else many programmers would be tempted to use it as a matter of course.
But of course we have the option you raised in your previous post of p/invoking a native module to do the performance intensive tasks in a language such as c++ with the parts where performance isn't generally an issue such as the UI more easily written in C#.
@GordonBGood:
"Sorry, Dave, although you can use unsafe code context and thus use pointers in C# without range checking, there is (by design) no performance gain in doing this"
What?
Well, I don't know if they designed it with performance in mind, but I know that IN PRACTICE you can achieve huge performance benefits using unsafe context in the right places.
Even the MSDN documentation says:
"As examples, using an unsafe context to allow pointers is warranted by the following cases:
Dealing with existing structures on disk
Advanced COM or Platform Invoke scenarios that involve structures with pointers in them
Performance-critical code"
Yep p/invoking critical functions works too, and often can result in better performance and code quality than writing code in C# that it wasn't designed for at all.
It seems like it might have a great future in Windows 8, with this new C++ extended with C# features, that let you write C# compatible classes in C++. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T
I suppose there'll be much more solutions in Win8 containing both C# and C++ projects.
I do not agree with the mobile segment adopting more and more C++. What about the Meego OS, Qt, great gui, great framework but no phones to implement apps for.
@Dave wrote:
[quote]
3 days ago
"Sorry, Dave, although you can use unsafe code context and thus use pointers in C# without range checking, there is (by design) no performance gain in doing this"
What?
Well, I don't know if they designed it with performance in mind, but I know that IN PRACTICE you can achieve huge performance benefits using unsafe context in the right places.
Even the MSDN documentation says:
"As examples, using an unsafe context to allow pointers is warranted by the following cases:
....Performance-critical code"
/quote]
Dave, I only know what native code the compiler generates as one can view with Visual Studio (even the Developer Express VS - view Assembly code after a breakpoint Alt-8) and the actual measured results, both with optimization turned on in full release mode, as follows:
1) The following classic contents of array counting loop takes about 245 milliseconds to run 10,000 times on my machine with an 8K buffer array, much of which time is revealed to be used by array bounds checking (the cnt and buf variable both local to the scope of the loop):
for (int j = 0; j < buf.Length; j++) cnt += buf[j];
2) The following code enclosed in an unsafe block with a fixed block pinning the array to the byte pointer "ptr" runs in about 285 milliseconds for exactly the same conditions:
for (byte* j = ptr, lim = ptr + SIZE; j < lim; j++) cnt += *j;
Inspection of the native code produced by the JIT compiler reveals that although there is no array bounds checking for this unsafe code, the code is quite poorly optimized with repeated reloading of contents of registers even when they already contain the right data.
I had already read this to be the case: that less optimization is done for unsafe code than as usual. I confirmed the same results with both Visual Studio 2010 and the new Developer release of VS 11.
Although MSDN is correct on the first two reasons for using unsafe mode, they are wrong that one uses it for performance.
This makes sense as if the differences in performance were so extreme, programmers would be tempted to use unsafe mode as a matter of course by default. Basically, one uses it when one can't get the job done another way or where the other way would be inefficient. There may be situations where the use of unsafe code and pointers does aid in performance gains, but tight loops certainly isn't one of them as demonstrated above.
C++ compiled with full optimization to release on the first loop runs in 42 milliseconds and the second style runs in 62 milliseconds, both due to very efficient loop optimization. The second form suffers from implementing the extra indirection through pointers with both unrolling the loop to an small amount. Unrolling the loop doesn't help C# in the first case because most of the time is still spend in array bounds checking and in the second case because the pointers are reloaded into the registers for every access. In actual practice, both forms are very close in time for C++ but very much optimized as compared to the C# forms, with small further gains if one manually unrolls the loops further. Remember, the C++ code is running an average of just over one machine clock cycle per memory access so very little additional optimization can be done do matter the form!
In conclusion, the ability of C# to perform very tight loops is many times slower than C++, partly due to the required array bounds checking but also due to the C# JIT compiler not optimizing as highly, but in practical use the end result of the same fast algorithms in C# as compared to C++ results in code that is about two times slower on average as not all of the processing time can be boiled down to such trivial tight loops as this. As I said before, if one requires the very utmost in performance use or call C++, but that comes at the cost of more "unsafe" code.
The hardware of mobile devices and batteries will soon enough have the power needed to run managed code with no fret... I am sure everyone can see that coming.
And the powers of desktops and laptops are already more than can be used by most programs, except of course high-end games.
Seriously, this prep-talk makes Herb look a bit dumb.
"Idiot developers" are on the rise, not "performance developers". Yeah, sure, some people in the datacenter might care, but most dev's will write in (IMHO) awful languages like PHP or JavaScript. I personally don't like the direction the worl'd taking here. I fondly remember the cycle-counting days writing assembler. But no matter what, we're moving further and further away from native code. Yes, there *is* a niche-market for C++ and there will always be, just as there is one for assembler. But I wouldn't expect a new series for assembler programmers on C9.
To me Herb's world-view seems at least a bit odd. WP7 does only managed code, Android mostly, WebOS mostly, Win8 Metro mostly, all websites (client- and server-side), .... What renaissance?
@GordonBGood:
It was obvious to me right after reading your comment, that you messed up some settings with the project. Either compiled Debug version instead of Release, or somehow explicitly set the project not to optimize code.
Regardless, did the test, and _never_ saw unsafe code run slower than safe one.
http://pastebin.com/ViFcyJnW
Here's the code.
It's actually pretty easy for the compiler to bypass range checking here even for safe code, and it sometimes does it, sometimes doesn't.
On my machine, the 2nd and 3rd calculations run at the exact same speed, ~48ms, while the 1st one run between around 48ms-90ms. Never faster than the unsafe ones. (the JIT usually managed to optimize it right after startup and at times when I made it run continously by holding the enter)
@GrodonBGood:
If you try it with a an array of longs, the unsafe code is always more than twice as fast as the safe one.
@dave and @gordon. Interesting argument over which is best C++ or C#. Many might think, just use the one you like where you like. A possibly more interesting question would then be: can you actually do that now and in the future? When you pick a favourite language, can it actually be used where you like for what you like, or will some big company make that too hard for you or limit you in self serving ways? If that were to happen to your favourite language it wouldn't matter which one was best would it? What's your thoughts on that?
@Dave
Come now, Dave, I do know the difference between Debug and Release settings and to check that the compiler Optimize Code switch was on. However, I was running on a 64 bit machine and there is a difference (both for Release mode), as for your example code:
For 64 bit code, all routines whether safe outside or inside the unsafe context or the unsafe loop using pointers ran at about the same speed or about 71 milliseconds on my 2.3 GHz machine
When forced to 32 bit x86 code, both the safe and the unsafe ran at about the same speed as above but the safe loop outside the safe context ran slower at about 109 milliseconds. Inspection of the code reveals this is because the safe loop outside the unsafe context was actually not optimized as well and was using more memory operations rather than more register operations, which is also why the 64 bit version outside the loop runs faster: it uses register operations for both cases.
Inspection of the code shows that none of the "safe" loops eliminate buffer range checking, but that isn't the biggest consumption of machine cycles; rather it is the question of how well ordered the instructions are and their efficient use of registers. As to why one optimization is different that another, it is likely just as for why sometimes the array bounds checking is eliminated and sometimes not: a question of what scope the various variables are - range checking is only eliminated when all variable have the right scope and the loop has exactly the right form.
I didn't say that the unsafe code would run slower than the safe code, just that you won't get the gains you think you will as compared to C++, and often the speed is just about the same.
@Dave
You are correct that the unsafe code is much faster than the safe code when dealing with eight byte data rather than one byte data. This is because the JIT compiler isn't very optimized for dealing with these where as the pointer arithmetic uses the built in machine instructions directly.
However, the real reason for this argument is your feeling that "unsafe C# code can be just as fast as C++ code". It's not. Coding just the accumulation of an array of longs which takes 71 milliseconds on my machine in 64 bit Release mode with Optimization On, C++ takes 31 milliseconds to do the same job.
This is because of the differences in the generated native code:
The C# generated native code has 11 machine instructions in its inner loop of which 8 of them are reading or writing to memory. The C++ compiled native code generates 7 machine codes of which four are memory reads per four loops as it automatically unrolls the loop to that extent, for an average of one memory read and 0.75 other register based instructions per value added. Interestingly, the pointer version of the loop actually takes longer in C++, and even longer than that for 32 bit code; however the very slowest implementation of C++ code is never slower than the very best of the C# code.
And that was the point I was trying to get across: that there are many cases where C# will not perform quite as well as C++ by a factor of two or a little more, and in these cases one should likely either write in C++ in the first place or p/invoke the C++ code from C# for those critical parts. One does not get these performance gains by just writing C# unsafe code using pointers.
EDIT ADD (next day): I've been thinking about this matter of C# performance as compared to C++ native code a little more and do concede that using unsafe context can speed up code in some but not all situations. To take this a little further, rather than just do the trivial task of summing an array, I decided to look at using a Look Up Table (LUT) array as is often used to do fast data transforms, in this case to count the number of bits in the array.
The LUT was generated as follows:
byte[] LUT = new byte[256];
for (int i = 0; i < LUT.Length; ++i) {
byte n = 0;
for (int j = i; j != 0; j >>= 1) if ((j & 1) != 0) ++n;
LUT[i] = n;
}
Now, calculate the sum of the bits in the byte[] array as follows:
fixed (byte* ptr = buf) {
for (byte* j = ptr, lim = ptr + buf.Length; j < lim; j+=4) {
cnt += LUT[j[0]];
cnt += LUT[j[1]];
cnt += LUT[j[2]];
cnt += LUT[j[3]];
}
}
fully optimized, 64 bit code, Release mode takes 97 milliseconds on my machine where the same algorithm on C++ takes 75 milliseconds. While the above pointer based code is much faster than "safe" code because of the elimination of the multiple unavoidable array bounds checks, it still isn't as fast as the highly compiler optimized C++ code. BTW and interestingly, using pointers for the LUT reference in the above manually unrolled loop actually takes about 10% longer than the above code. Also, automatic array range bounds checks are only eliminated if the variable are local non-static variables, which means that they would never be eliminated for your original console application where the tests are done inside the static Main method of the Program class.
In short, use the appropriate language and language implementation for the job. Although it performs very well for a "Coffee" style language, Microsoft's implementation of C# can't quite keep up in performance to Microsoft's implementation of C++ no matter what optimizations are made if the same optimizations are allowed for both languages. However, you have made me reconsider testing whether using C# unsafe context will get some code "close enough" to C++ so it isn't worth the bother of using it for a additional 30% gain in performance.
@Glen
I suppose as example of what you describe is that it was harder to write C++ code including interfaces to window controls for native code with Visual Studio 2010 than it was to do much of that work using C# or another CLI language. With Microsoft's C++ "Renaissance", this has been fixed, at least for Windows 8 style Metro apps. Another example is that it is much harder to use C/C++ native code in Android than it is just to code with Java.
When it is more difficult to code, one uses the easiest tools at hand to get the job done, but if those tools can't get the job done one then looks for whatever it takes to do it. Previous to this "Renaissance", one called C++ code as necessary from DotNet CLI. Now we have the option to code an entire metro application in C++, but as I find C# easier to code, I will continue to stick with it for most apps unless I need performance, in which case I will call C++ native code for those critical portions, just as I do for Android. That is the approach of most programmers except for those very familiar with C++.
If the performance is the only criteria which matter in programming, then we will have "Assembler Renaissance" after that "Machine Code Renaissance" and probably "Microcode Renaissance".
@Jedrek głupiś jak but. Who said and where that performance is the only criteria? Oj głupiś jak but synu.
@Jedrek
While I agree with your implication that this wasn't one of Herb Sutter's best presentations (his two presentations at the BUILD conference were excellent, but he didn't dwell on the "C++ Renaissance"), and that the real new is just the re-entry (or rather acceptance) of C++ native code compilers as one of the first class supported languages of Windows 8, specifically Metro, I have done a lot of tests with comparing VS C++ native code generation with what I can do hand generating assembly language code, and although if one doesn't miss a single trick in the "book" one can sometimes squeeze out an extra 10% to 20% for very tight loop performance (if one does miss a trick, it can sometimes go the other way). I don't think any of us want to go back to that, or even lower to microcode for such small gains except for very small portions of critical code.
However, there is an interesting new capability that is (currently) only included with the C++ native code platform: this Accelerated Massive Parallelism (AMP) code generation that can run computations using the Graphics Processing Unit. Microsoft will offer this as a standard so that eventually it will be adopted by other compilers and (hopefully) by the ISO standards committee. This seems very interesting and seems to be a better solution than Render Script that Android has come up with under Java. This could be very interesting for computationally intensive applications, and could make much more of a performance difference than just some 10's of percent.
If successful, I suppose that this might get ported to other languages.
GordonBGood@ Even in c/c++ applications there is a lot of possibilities for performance optimization. For example in ATLAS (math-atlas.sourceforge.net) performance is tuned automatically based on given hardware. In other words the same c/c++ code will run significantly faster/slower depending on lower level performance optimization (performance is done on "assembly languages" level).
In this particular case performance is tuned automatically by the ... program.
The real message behind "C++ Renaissance" is that the user will be always better in code optimization than some lower level code optimization done by the compiler.
In the case of ATLAS IT IS NOT TRUE (it is possible to do that even better - look at Intel MKL Library). Only very few people have time and knowledge to compete with that kind of technology. It is also possible to say that linear algebra is a very specific problem so code optimization is especially easy in this case.
In theory by using lower level compiler optimization it is possible to make c#/java/python (compiled python) program 5 times faster than c/c++ program (without optimization).
But such technology is not available yet (for general purpose programs).
Regardless of the programming language the executable file is just sequence of machine code. At binary level it is hard to say what was the original programming language.
It is also possible to do code optimization at the source level (c++). I have seen people who are able to speed up the program 10 time just by automatic rewriting code (there are tools for that) in a proper way (the code is unreadable but very fast).
I am sure that c# program may be 100 times faster than c++ program only because the programmer experience (even java script may be faster than C++).
From performance point of view in theory "Assembler Renaissance" would be much more beneficial than "c++ Renaissance" but that is not practical solution at this moment.
The choice of programming languages is important only because lower level code optimization is very difficult at this moment but who knows what will happen in the future?
Okay so I'm sitting here wondering, after having watched the video and having read most of the comments, why doesn't Microsoft rewrite all of those OS libraries that were written in managed code in C++? Why not write the .NET framework in C++ while keeping the APIs as they are? Then the only meta data that is needed is for the .NET app itself, not the entire framework.
If you have developer productivity managed apps that are running as a thin layer on top highly optimized C++ doesn't everybody win? What am I missing?
I think you are missing that the entire Win32 underpinning of Windows still is and has always been native code (C++) and that all that is new in Windows 8 as per the WinRT libraries that support the Metro applications are also native code with a thin covering of metadata so that any of the support languages can call through to it, including the managed ones. The only libraries that are not in native code are the DotNet Framework ones, and as most of those call though to the Win32 API as required, there would be no real performance advantage of re-writing them such as for the WinRT. In fact, there is a performance disadvantage to repeatedly call through to native code as implemented as for WinRT as they are modified COM interface methods which are artificial to managed languages and would actually cost performance when repeatedly crossing the gap between the managed and unmanaged code. Also, some of the most crucial DotNet libraries are actually in native code format as they have been ngen installed into the Global Assembly Cache.
Managed languages are slower than native code mostly because of the delays of JIT compilation (often negligible but sometimes very onerous as for complex unrolled state machine operations) and the limits in optimization that may be done by such "on-the-fly" compilation as compared to the multi-pass compilation and in-depth optimization of a native code compiler as Microsoft's C++ compiler. As well, the managed system has the overhead of managing (mostly garbage collection) of the managed heap.
As one who has fairly frequently converted code between C# and C++, a more interesting concept would be to offer a more efficient multi-pass native code compiler for C# code. This partly already exists as the ngen capability of DotNet, which generated special pre-compiled files for use as shared system files, but is not likely as efficient as native code from the C++ compiler. What I observe is that in many ways, the external capabilities of C++11 and C# become very much similar: generics are a somewhat different by similar in use form of templates, C++ smart pointers take over from requiring a managed heap by providing automatic reference counting and release, the compiler could be set to "safe" or "unsafe" mode as to checking array bounds limits and pointers or pointer type conversions, etcetera. This is made more and more necessary because they now are both forces to support the same common library, the WinRT. In fact, C++ still lags the managed languages in full support of futures (ie. Promises, Tasks, whatever) and asynchronous programming models; for instance, even some of the BUILD conference async demo's don't currently run on the Windows 8 Development Preview (and will require major work one the underlying libraries) where as almost all of the managed code ones do (one with a very slight modification but using existing libraries). In effect, I am proposing the reverse of the C# Renaissance in adapting the C++ language to be more conformance to modern language forms and syntax to rather making C# in native mode produce code that is identical to what would be produced by C++: unmanaged heap with automatic reference counting under the covers and so on.
The fact that C++ produces much higher performance code is then offset by the fact that for production programming, it is much harder to write bug free code in C++ than in C# (or VB for those would still like that syntax). To say that C++ is undergoing a Renaissance because the only way we will be able to write code that gets more done per watt is by all of us writing C++ code is stretching things! Come now, Herb! With properly written programs and apps that use good asynchronous programming models (note that C++ still doesn't very well support that!), much of the UI front end of Win8 Metro apps is spent doing nothing as it has already been farmed off to another thread, which probably has as much if not more to do with consuming power for the actual front end of the apps than the language. Then, let C++ get on with those parts at which it excels, as in crunching the numbers, running the tight loops, and so on.
@GordonBGood: C++ is a widely used general purpose programming language that is at a level of maturity in C++11 that makes it more productive than you're giving it credit for. As Herb states, he and the standards folks need to put more emphasis on libraries, standard libraries for C++. Of course, this means they are, they will. A native BCL doesn't make much sense, but a set of portable, standard, efficient(of course, this is C++!) domain-specific libraries certainly does.
What is the C++ Renaissance in your opinion? How would you define it? I'm not sure it's the same as we, Microsoft, intended. Please elaborate.
C
I'll grant you everything you say in the first paragraph. C++11 indeed is much easier to use than any previous C++ standard, and from the Windows 8 Developer Preview and Visual Studio Developer Preview we can see that progress is being made on developing libraries to make it easier to do most of the things that one can already do very easily in equivalent generations of C# (or now VB).
As per Herb's talk here, Microsoft's view seems to be that the C++ is making a comeback or "Renaissance" in that it will become the programming language of choice for almost all applications programming due to the need for "more bang for the watt". At least some of his extrapolations are flawed, such as that mobile devices application programming is moving to C++; as I stated in a previous post, Apple has always been pro native language programming and of the other (two) major programming environment providers (other than Microsoft), C++ is at most a somewhat poorly supported secondary programming environment as compared to the "Coffee type" languages, meant more to be called through p/invoke (actually JNI) calls. Thus, there is no trend or movement to C++ there. As to use for server code, the point is likely well made that there is a requirement for the higher efficiency of C++ - other than that ASP.NET might still be desired as a more tightly controlled security model
Where there is a movement toward better native C++ support or a "C++ Renaissance" is within Microsoft itself, with native code C++ support in Visual Studio now making it feel like a first class language as compared to a distant cousin. This goes in hand with the support for WinRT, which of course is actually a native code implementation under the covers. With this movement, C++/CLI now feels like a distant cousin without much of a future as it is one of the languages without a formal connection to the new WinRT "Metro style" apps.
The view expressed in this video seems to be that higher and higher percentages of application programming will be done in native C++ over the next ten years due to this need for more "bang for the watt". I don't see that happening. As always, one will choose the appropriate language for the job. For faster development times where maximum performance isn't crucial, languages like C# (or even the quite low performance F#) will be chosen; where there are limitations in a VM environment, either a "pure" C++ development will be chosen or one will use a hybrid of VM languages calling more efficient C++ written libraries as required to overcome those limitations or for maximum performance. Nothing has changed, other than that C++, especially for Microsoft environments, has been made a little easier to use. If Microsoft really believed that most programming for the future needs to be done in C++, than those other languages would be de-emphasized with ways of porting existing code to native.
So that's my view: Thank you Microsoft for an improved C++(11) including conformance to the new standard(s) and libraries that support previously sorely lacking standards such as new asynchronous programming models and even advanced concepts such as AMP; however, even with all of this it isn't going to replace C# (and maybe VB) where programming productivity matters. As to other programming environments, one does what one must. I will likely (reluctantly) develop an Android app completely in C/C++ in order to overcome some limitations of the Android Java environment restricting memory use, but the majority of applications will continue to be written in Java in spite of the potential performance hit; for other applications such as games, C/C++ will be chosen for performance over Java. I would think that the same decisions would be made as for developing applications for Windows tablets or for a new version of Microsoft Phone (assuming it might support writing apps in native code), with a decision to use native C++ eased somewhat by the fact that Microsoft have provided a much easier to use and more powerful set of development tools for C++ for Microsoft products than as provided for Android's NDK.
G.
Excellent insightful presentation!
Thanks!
Excellent and inspiring presentation.
I'd like to do a presentation about this internally in my company, and it would be great if I could just use Herb's slides in PPT format instead of the PDF static versions available here? If so, where can I get the PPT slides?
I will obviously respect any copyright and will not proclaim I did the slides
.
Thanks.
OK Mr. Sutter, I'm sold.
I'm all for C++ because it's super fast and has incomparable performance-per-dollar, etc etc. I would even be ready to switch from "coffee languages" to straight C++ and never look back.
But wait - I have no where to go in terms of web programming! Why isn't C++ on the web application scene yet? Why can't I write C++ server pages? Where can I find C++ web-application frameworks and libraries such as the myriad of choices available in "coffee" languages?
Wouldn't C++ equivalents of "coffee-web" languages/frameworks have a huge performance-per-dollar gain, as you explained? If all 'Enterprise Java' websites out there were using C++, wouldn't they be running much faster and saving your claimed 44% of cost?
It would be nice to hear what you have to say about this.
I suspect I speak for many others when asking this question.
Thanks
Related (from Bjarne!): http://www.jroller.com/craiger/entry/where_are_all_the_c
Hi!
To all
I am not as experince as you all guys are.
So kindly accept my regards to all of you.
What I am thinking that why microsoft is promoting C++ now because MS has learnt that C++ is the only language with the help of which MS can beat JAVA else its very difficult for C# to do so. Its my personal opinion if I am wrong please correct me.
Thanks in advance.
It is probable that programmer costs do not showup
in data centers costs is because most data centers run on open source software.
@DudeMan:C++ its already in the web application scene, check out BinaryTiers
@Kid_Programmer
Well said, coming from Python background and I can pretty much understand what you mean by "Lazy", After learning C++ for a week or two I just realize how lazy I am and how "Performance matters".
I wrote my first Python software in the second week of study, while it takes over 6 months to get familiar with C++ concepts, but I'm happy right now since I know more about computers and hardware in general, something that I never learn by Managed languages and even help me to use Managed languages more logically.
C++ is a language that any programmer need to know in the first place in my opinion, even if performance doesn't matter.
I'm looking forward to C++ future.
RE: web GUI toolkits:
Wt http://www.webtoolkit.eu/wt
QWebClient http://labs.qt.nokia.com/2009/09/18/qt-in-the-cloud-with-qwebclient/
I always wondered why MS didn't concentrate more on domain-specific languages. "Back in the day", all my code was C++ server/logic with VB GUIs. That approach worked really well, so a really easy to use (ie not WPF) GUI-specific language would complement a system really well.
Remove this comment
Remove this thread
closeComment on the Post
Already have a Channel 9 account? Please sign in