6 ms·

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 f

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)
  - Shamanmuni 13y ago
    I agree with you, and some actual facts can be provided. Just look at the benchmark game between Go and C++ in quad-core x64: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=gpp&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... In average, C++ is three times faster than Go in all the tests. These benchmarks aren't definitive but you can assume that in general the difference in performance is much less than an order of magnitude. Now, look at the same comparison between Go and Python3: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=go&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Python3 is in average 20 times slower than Go. And I love Python but Go isn't that much harder to use. It's quite a nice language, actually. So, the exodus from Python to Go is very understandable, you gain a lot of performance without sacrificing much. And I think there's room for performance improvements in Go, perhaps in a couple of years C++ developers will make the transition. But I think that the real C++ killer is Rust. Time will tell.
- kbenson 13y ago
  As much as the original statement was hyperbole, it's often overlooked by people that the arguments they make to explain their choices often lead to different results than they expect if actually followed. If your work consists of writing extremely demanding code WRT performance, then it probably is useful to stop and think for certain projects, or portions of projects, whether it's worth going to assembly. Similarly, if you find any utility in going lower in the language stack, it might be worth going higher for some projects or portions of projects. Whether you actually use anything else is up to you, but blind adherence to a specific language is limiting, and may well be detrimental to the work you are trying to accomplish. (you in this context is general, not applied to the parent specifically)
dilap 13y ago
Just depends on the problem -- people do use assembly all over the place when the performance speedup is warranted, for example video encoding (e.g. x264). Even Go uses assembly in places -- for example, bytes.IndexByte. The point is that C++ still has real performance benefits over Go, and it's not just used out of cussedness or backwards-thinking. (Though Go can be pretty close. I think it's a shame that didn't go w/ a simple-refcounter + weak references approach to GC.)
deleted 13y ago
[deleted]
logicchains 13y ago
That simply isn't the case any more. The GCC and the LLVM can, for the majority of cases, write far faster assembly than the average assembly programmer. Naive C or C++ is faster than naive Go, but naive assembly is probable slower than even naive Go (the Go compiler produces optimised assembly, just not as well optimised as the assembly produced by C compilers).
bodyfour 13y ago
Two points: * I read a lot of compiler-produced assembly -- these days it's often surprisingly clever. I don't think most developers could beat them with hand-coding even if they were willing to spend 10x-100x the time in development and debugging. * As other people on the thread have mentioned: it's all about the memory. In a world where a cache miss is going to cost ~100 cycles the actual instruction stream isn't even your biggest concern -- programming for performance increasingly means counting cache lines. I can do that just as well with C++ code as I could with assembly, at least as long as the compiler provides things like prefetch primitives, etc. There are still some super fast-path areas where expert assembly can beat a compiler (crypto algorithms, ...) but it just isn't attractive for most projects no matter how much developer time you're willing to spend.

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)
- Shamanmuni 13y ago
  I agree with you, and some actual facts can be provided. Just look at the benchmark game between Go and C++ in quad-core x64: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=gpp&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... In average, C++ is three times faster than Go in all the tests. These benchmarks aren't definitive but you can assume that in general the difference in performance is much less than an order of magnitude. Now, look at the same comparison between Go and Python3: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=go&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Python3 is in average 20 times slower than Go. And I love Python but Go isn't that much harder to use. It's quite a nice language, actually. So, the exodus from Python to Go is very understandable, you gain a lot of performance without sacrificing much. And I think there's room for performance improvements in Go, perhaps in a couple of years C++ developers will make the transition. But I think that the real C++ killer is Rust. Time will tell.
kbenson 13y ago
As much as the original statement was hyperbole, it's often overlooked by people that the arguments they make to explain their choices often lead to different results than they expect if actually followed. If your work consists of writing extremely demanding code WRT performance, then it probably is useful to stop and think for certain projects, or portions of projects, whether it's worth going to assembly. Similarly, if you find any utility in going lower in the language stack, it might be worth going higher for some projects or portions of projects. Whether you actually use anything else is up to you, but blind adherence to a specific language is limiting, and may well be detrimental to the work you are trying to accomplish. (you in this context is general, not applied to the parent specifically)

dilap 13y ago

Just depends on the problem -- people do use assembly all over the place when the performance speedup is warranted, for example video encoding (e.g. x264). Even Go uses assembly in places -- for example, bytes.IndexByte. The point is that C++ still has real performance benefits over Go, and it's not just used out of cussedness or backwards-thinking. (Though Go can be pretty close. I think it's a shame that didn't go w/ a simple-refcounter + weak references approach to GC.)

deleted 13y ago

[deleted]

logicchains 13y ago

That simply isn't the case any more. The GCC and the LLVM can, for the majority of cases, write far faster assembly than the average assembly programmer. Naive C or C++ is faster than naive Go, but naive assembly is probable slower than even naive Go (the Go compiler produces optimised assembly, just not as well optimised as the assembly produced by C compilers).

bodyfour 13y ago

Two points: * I read a lot of compiler-produced assembly -- these days it's often surprisingly clever. I don't think most developers could beat them with hand-coding even if they were willing to spend 10x-100x the time in development and debugging. * As other people on the thread have mentioned: it's all about the memory. In a world where a cache miss is going to cost ~100 cycles the actual instruction stream isn't even your biggest concern -- programming for performance increasingly means counting cache lines. I can do that just as well with C++ code as I could with assembly, at least as long as the compiler provides things like prefetch primitives, etc. There are still some super fast-path areas where expert assembly can beat a compiler (crypto algorithms, ...) but it just isn't attractive for most projects no matter how much developer time you're willing to spend.