10 ms·

I find it amusing that there isn't a single word about runtime performance in the whole essay. In the end, when I code in C++, it's because I believe my code w

• easytiger 13y ago
  What gets me about MOST of the stuff I read on criticising c++ is the complete disregard for runtime performance. I write software that has to consume billions of messages a day per instance. I've done it in several languages for different purposes. At the end of the day if you implement the same algorithm in c++ it will be faster. I don't care what you think you can do in node.js, but you are wrong. When you have limited resources there is no option save for c and c++. It isn't a big deal, that is currently how we get things done. People fucking around with distributed web applications are so immune from the specific cost of adding a line of code because rarely is what they are writing executed repeatedly in a tight loop and thus they lose the ability to quickly measure performance impact
  • terio 13y ago
    I find it funny that when I had to switch to C++ I found it slow compared to C and Object-Oriented Pascal. There are also some tradeoffs when switching languages. Some people would never make the move from C to C++ citing unnecessary complexity (e.g. Linus Torvald). This is essentially a question of having the right tool for the job. Switching from C++ to Go is probably a good decision some cases and a bad one in others. But one should not remain so anchored in one language that won't be able to consider some other, probably better, option.
  • tlb 13y ago
    One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing) If your code consumes more than 300 cores, you should care about performance. If your code consumes less, you should care about productivity. Adding cores is easy while adding programmers is hard. Cores scale linearly while programmers don't. So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that.
    • anon1385 13y ago
      What on earth makes you think that all problems can be scaled out to as many cores as you like? This is exactly the web developer mindset that people are referring to elsewhere in this thread.
      • raverbashing 13y ago
        "What on earth makes you think that all problems can be scaled out to as many cores as you like" It certainly can't. And for example you can't do that on an app that runs on a phone, for example. But, when possible, this is the cheapest way to do it. Not to mention other cases where it's the "only" way to do it (like, CPU heavy processing, video processing, simulations, etc). A smart developer can help with a %, but with limited returns. For example, Facebook invested on their PHP compiler since their server usage would only increase, and the resources for that gain (in terms of people) are more or less constant.
      • PaulHoule 13y ago
        Well you're trading one kind of B.S. for another kind of B.S. There's a lot of B.S. that comes with C++, and there's an entirely different kind of B.S. involved with writing things in Java + Hadoop. Personally I stay out of the C/C++ ecosystem as much as I can because threads are never really going to work in the GNU world because you can't trust the standard libraries never mind all the other libraries. The LMAX Disruptor shows that if you write code carefully in Java it can scream. They estimate that they could maybe get 10% better throughput in C++ at great cost, but the average C++ programmer would probably screw up the threading and make something buggy, and a C++ programmer that's 2 SD better than the mean would still struggle with cache line and other detailed CPU issues. The difference between the LMAX Disruptor and the "genius grade" C++ I've seen is that the code for the Disruptor is simple and beautiful, whereas you might spend a week and a half just figuring out how to build a "genius grade" C++ program, taking half an hour each pop.
  • mathattack 13y ago
    With no disrespect intended to the OP, this is an interesting comment considering that he came from Google, which is one of the world's largest beneficiaries of optimized performance. (If there's one place where run time trumps human time...)
  • consultant23522 13y ago
    The number of places in most code where you're running a tight loop a jillion times is vanishingly small. In those cases you're usually better off writing the vast majority of the code in a language that increases developer productivity while writing the occasional C/C++ module when serious single-threaded crunching is required. This is why so many modern higher level languages offer C bindings. The world isn't all or nothing. And this thought isn't specific to Go. The main language could just as easily be Java, Python, PHP, or even (eek) Ruby.
  • mtkd 13y ago
    I think a lot people who are doing (successful) distributed web apps - are learning that performance actually does matter - and it can be painful to optimise poor architectural decisions. People who 5 years ago were sermonising to me on premature optimisation are now telling me they're rewriting something in a faster language or how many millisecs they've saved using some new profiling snake oil they've just bought. (whilst my background is in assembler/C, I now prefer to use prematurely optimised Ruby where possible just for the maintainability and the magic)
    • karterk 13y ago
      But optimizing later can also be the smarter thing to do. Especially when you're in the early stages, you don't know what direction your product/company will take. Optimization is a happier problem to have than say, trying to find enough people to sustain your business.
    • Pxtl 13y ago
      I think the lesson to learn is that you have to ensure you don't have barriers to optimization as well. Knuth's original statement on premature optimization presupposed that the cost of optimizing later isn't really that much higher than optimizing now. I mean, obviously it's going to be somewhat harder - code is harder to read than to write, and fixing a performance failure is going to take longer than getting it right the first time. But still, that's not a humongous cost and there are so very many opportunities for optimization that chasing them without performance data is a waste of time. But when you have an actual barrier to optimizing? Then you've got a real problem. If you're committed to a technology that has a hard performance ceiling and no easy way to break the slow parts out into another technology? That's a different problem. It seems evident that Knuth's advice about premature optimization can be indiscriminately applied when you're talking about code for an individual component... but should be considered carefully against the potential costs when thinking about large architecture.
      • jfb 13y ago
        People who quote Knuth as aphorism are rarely as smart as Knuth. The optimization quote is great, but it's usually deployed as an appeal to authority to justify a preconceived, ideological decision -- God knows, I've done this. Building software is hard, and it's not at all surprising (or reprehensible) that people will seek out shortcuts to winnow their decision space.
• jlouis 13y ago
  The reason is four-fold: * Performance doesn't matter for a large set of systems we write. * Performance is far more a product of the programmer than the language you use (within reason, naturally. Don't do Video decoders in Python :) * Large-scale systems where there is no single tight loop anywhere are way different beasts. Their performance stems largely from fast RTT in the edit-compile-test cycle and programmer productivity. Not from fast native code execution. * To some problems, latency or sustainability matters more than throughput.
• pmelendez 13y ago
  > "In the end, when I code in C++, it's because I believe my code will run faster" Completely agreed and exactly my point. I am not moving to Go because is solving problems that I don't have. Pike said: "That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost." So Go's philosophy is to make some compromises for the sake of making programmer's life easier. C++ is the other way around, there is a cost the programmer has to pay in other to have code abstractions without impact the performance. I don't think anyone "loves" to code in C++, but people tend to like the performance that C++ provides and are eager to pay the cost of programming in a monster language that no simple person fully understand.
  • jawr 13y ago
    I used to really enjoy writing C++, but that feeling can be compared to doing a really big workout. It's a gratifying hurt.
  • hackinthebochs 13y ago
    I love coding in C++. The feeling of being so close to the metal that your actions are directly controlling the machine is something that was lost immediately when I moved to Java. It even more of a disconnect in higher level languages.
    • twoodfin 13y ago
      I have sort of the opposite feeling: I love that in C++ I can create very nice abstractions while being fairly confident that the compiler will transform them into code with C-like performance. That is, as long as you know what to avoid (namely: heap allocations and unnecessary copying).
      • bjz_ 13y ago
        Exactly. That is what is lost in most of these debates. In order to move forward in the design of systems programming languages, we must first recognize what makes C++ great, in spite of its deep flaws.
      • 13y ago
• metaphorm 13y ago
  you should switch to Assembly then. you can get even better performance than C++, and hey, if you don't mind sacrificing your own time to make the program run faster, it seems like the right thing to do.
  • alanctgardner2 13y ago
    I'm going to fall for this trolling: It's a trade-off. Assembly is an order of magnitude less productive, and it doesn't offer significant benefits. Outside of your critical path, you might actually hurt your runtime performance unless you really, really know your instruction set. When people say 'C trades speed for ease', they don't mean they want to design an ASIC to make their operation blazing fast. They mean C is at a sweet spot of developer productivity and execution time, for their specific application.
    • metaphorm 13y ago
      I was being snarky, but not trolling. I was very much trying to get at the same point you're getting at. There is a trade-off between developer productivity and runtime performance. The author said that Go is appealing to people coming from a Python or Ruby background, which is a strong indicator that Go has fundamentally gotten the developer productivity side of the equation right. So we should try and think about how the equation balances here. Is Go an order of magnitude slower than C++? Don't know. I think its not, though. My impression (which might be wrong, so please correct me if necessary) is that Go programs run approximately as fast as C++ programs that are written using C++ automatic memory features like smart pointers. Is Go an order of magnitude faster to develop than C++? Again, I'm not sure, but my perception is that it probably is. Python devs wouldn't be interested in it otherwise.
      • waps 13y ago
        Not at all. Go gives (a lot of) the advantages of python and not many of the costs. I would say that Go dominates python, giving the advantages of that language with few of the costs. Anything you can do in python can relatively easily be done in Go. Replacing dynamic typing with reflection seems to work pretty well. It does not similarly dominate C++. C/C++ cannot be replaced by something like go for the very simple reason that it wouldn't work. Go itself depends on a C runtime and a C compiler written in C, even ignoring the operating system it has to run on (which also cannot run without a C/C++/assembly core). The same goes for languages like Java, Erlang, Haskell, ... (Java is particularly bad, since it has a huge complicated runtime which is almost completely C++) After all, who will garbage-collect the garbage collectors ? (this is a simplification, the garbage collector is a major problem, but not the only one. There's dozens)
• JulianMorrison 13y ago
  the implication performance ⇒ C++ is correct but the commonly assumed implication C++ ⇒ performance is not. Idiomatic Go can be faster than a mess of C++.
  • ramchip 13y ago
    Someone mentioned a while ago how a common pattern of comments on programming forums is to take the most literal and uncharitable interpretation of a post, and reply to explain how this extreme view is mistaken. I've never seen anyone defend the idea that writing something in C++ will necessarily make it high-performance and I would be very, very surprised if that's what the OP meant.
    • diydsp 13y ago
      what a coincidence- I was thinking about this this A.M. I was conceptualizing a flowchart. Something like: 1. Observation 2. Massive overgeneralization of observation and posting to Internet. 3. Refutation of massive overgeneralization. 4. Insistence on narrow range of circumstances in which observation is true. 5. Announcement of extraordinary exceptions. 6. Anecdote in which even that exception was inadequate. 7. Call for advanced structural frameworks to encompass vastly differing perspectives. 8. Recollection of failed attempt at structure in 1976 (Optional: suggestion to live in geodesic homes). 9. Platitudes about how the details don't matter anyway. 10. Violent exasperation that details won't matter, including extreme hypothetical circumstances. 11. Shifting of blame to political figures and/or youth and their gadgets.
  • luikore 13y ago
    Yeah, idiomatic any language can be faster than a mess of Go.
    • zanny 13y ago
      Well written code in any language will almost always outperform poorly written code in another language. Python being 50x slower than C++ doesn't matter if you are using an exponential imlpementation of a linear problem.
• devx 13y ago
  Sounds like Rust will be a better solution for those types of problems.
  • krmboya 13y ago
    Exactly.. I was thinking of Rust as a compromise between performance and safety/productivity.
• VanillaCafe 13y ago
  > I find it amusing that there isn't a single word about runtime performance in the whole essay. It most certainly is. In fact, it's the answer to the opening question, "Why does Go, a language designed from the ground up for what what C++ is used for, not attract more C++ programmers?" You might not have noticed it because he only refers to the performance issue as a "Zero (CPU) cost" mentality. > C++ is about having it all there at your fingertips. I found this quote on a C++11 FAQ: > > The range of abstractions that C++ can express elegantly, flexibly, and at zero costs compared to hand-crafted specialized code has greatly increased. > > That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration.
• deleted 13y ago
  [deleted]
• popee 13y ago
  Just an opinion and maybe even wrong. If you really care about performance you (must) care about control and you, in most extreme way, want C not C++.
• jjindev 13y ago
  To restate, C++ programmers are doing C++ because they are trapped in a corner world where they must suffer for speed. Go's architects think they've got a band of problems where ... you just don't have to suffer so much. "no, me, I still need to suffer?"
• petegrif 13y ago
  I strongly suspect that Rob Pike understands the importance of performance. a) he is old enough to respect resources b) Google programs need performance
• bluecalm 13y ago
  There is a lot of crap in C++ which doesn't help with performance at all: class hierarchy with all the inheritance/friends/virtual/constructors/destructors, godawful syntax, template model, exception handling, 101 ways to do the same thing, lack of package/module handling etc. Rob Pike addresses those in the article. Yes, Go is slower but it's not slower because of fixing those errors, it's slower because it introduces different features suitable for its niche (GC, reflection etc) Rust takes similar approach to avoid C++ design mistakes and doesn't sacrifice performance in doing so. Those mistakes (mainly the whole "object model" thing) is what he is saying in the article. Pointing out performance of Go isn't really an argument against his point.
  • RogerL 13y ago
    Templates do help with performance. Look up the performance characteristics of qsort (C) vs std::sort (templatized C++ sort).
    • bluecalm 13y ago
      I tested both extensively lately and the performance was exactly the same (under Intel Compiler and Visual Studio) so probably those compilers found a way to optimize it. They both are much slower than hand coded version anyway so it doesn't really matter (link to implementation which beats standard qsort/std::sort performance by 2x/3x times (at least on my data): http://www.ucw.cz/libucw/doc/sort.html http://www.ucw.cz/libucw/doc/sort.html).
• SeanDav 13y ago
  If your only, or even main criteria was performance you would write in assembly language. The fact that you don't, means that Rob probably nails it with this comment: "C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way."
  • deafbybeheading 13y ago
    That's absurd. The law of diminishing returns comes into play, and for most cases, assembly is just not worth it (whereas C or C++ is). Rust seems like another interesting take at that sweet spot, but it seems like in Go this was an afterthought (though to be fair, the performance benefits of C / C++ are often cargo-culted even when that kind of performance is completely irrelevant, so Pike still has some valid points).