5 ms·

Why C++ is not my favourite language

17 points by alaricsp 17y ago

eplawless 17y ago
That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually faster, with some properly done benchmarks or some valid technical examples.
- eru 17y ago
  Common Lisp is already quite fast and dynamic. And for the same number of hacker-hours spend in optimizing, you probably get a larger speedup. Also Python+C can be quite a fast combo. Fast to develop and fast to execute. Forth is also quite fast and dynamic, if you grok it. A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages. If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++. For benchmarks see: http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/
  - jcl 17y ago
    I can't help feeling that Common Lisp should be doing better, considering that it's a language where you can effectively tell the compiler "It's OK to store this variable in a register". It's currently doing about the same as Mono, which IIRC doesn't JIT, and worse than Java. The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.
    - eru 17y ago
      The quality of the individual programs plays a large role. E.g. GHC (Haskell) has made huge strides in the past thanks to better libraries and implementations for the benchmark, despite nearly the same compiler. On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.
      - igouy 17y ago
        > despite nearly the same compiler As you don't say how far "in the past" maybe that's nonsense or maybe that's true. > a lot of the benchmarks had to be reformulated after lazy languages got fast That's nonsense. Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated - http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=clean&id=1#about http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
        jcl 17y ago
        I love the shootout, by the way. Thanks for maintaining it.
        igouy 17y ago
        Thanks to those who contribute programs. Every week there are new programs, often from people who haven't contributed a program before. One of these days someone will find a way to make effective use of all the cores for n-body, maybe.
        eru 17y ago
        Thanks for clearing that up. I wrote from my unreliable memory.
  - UncleOxidant 17y ago
    OCaml does quite well against C++ in the shootout. OCaml's Functors and type inferrence are a big win over C++ templates. Yeah, the syntax takes some getting-used-to, but all in all the language seems to hang together much better than C++ (perhaps not saying much)
    - eru 17y ago
      I agree. I like Haskell's syntax better. But their syntaxen are nearly isomorphic for the most common stuff.
      - UncleOxidant 17y ago
        I'm finding OCaml's approach to be a bit more practical even if it isn't as pure as Haskell. Once in a while it's nice to be able to drop into an imperative style or even do some OO and OCaml lets you do all of that.
        eru 17y ago
        Yes. Though Haskell allows imperative style (via Monads), too.
  - dtf 17y ago
    I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.
- magv 17y ago
  More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC. I do not know why this fact remains so little-known. [1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd839daf http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
  - psranga 17y ago
    Note the comparison is to C, not C++. The runtime improvement came from aggressive inlining. I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same. Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc. The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass. In these days of 16G developer desktops, is this an unreasonable demand? :)
    - gchpaco 17y ago
      In fact C++ is usually slower than C because parsing and comprehending it is so damned hard that compiler writers are satisfied when they can get that far.
- alaricsp 17y ago
  That day may not be too far off... I hope ;-)
cbeust 17y ago
I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.
- gruseom 17y ago
  one of the requirements for this kind of speed is for a language to be statically typed No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
  - cbeust 17y ago
    You need to make languages fast on both dimensions, static and dynamic. A dynamically typed language can only be optimized in one dimension, which is why they usually trail behind statically typed languages in performances (since those are optimized along both axes).
    - alaricsp 17y ago
      I've not seen anything like the dynamic-dispatch optimisations the Self team came up with in the 1990s done in C++, nor problem-domain optimisations expressed as macros as is often done in Lisps, nor the aggressive constant-propagation of closures and their eventual inlining that Factor does. Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...
      - eru 17y ago
        Do you know Synthesis OS (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4871 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...). The author made the OS specialize (and thus optimize) system calls during runtime (or something like that, it's been a while since I read the paper). The techniques might me applicable in higher-level languages than the assembler used there.
dtf 17y ago
I guess he's not a systems programmer. What language did Slava Pestov turn to when he recently re-wrote Factor's VM? C++ programmers: we do the dirty work so you don't have to.
- Legion 17y ago
  Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
  - acg 17y ago
    Hardly, I know many people who spent years learning C++ in the 90's only to avoid it now. The reason is they had no love for the language. The C++ language design has serious flaws that whenever someone brings them up there's the usual, rolling of the eyes and the "yeah we know" sort of look. The if you criticise you must be a dumb attitude is encouraged by the C++ community too, and that was not borrowed from the C community: where the emphasis was beautiful tight code (like the K&R manual itself). Lets face it C++ is something like 30 years old this year. For a 30 year language to have so many flaws, and for newer languages to make a better job of integrating OO while still keeping the power: you have to ask whether the C++ community really knows all about technology and nothing about design. The whole project has been mislead from start to finish. It strikes me it had to take a couple of ada programmers to write the STL.
    - dtf 17y ago
      C++ hits a certain sweet spot. In some cases - whether you like it or not - it's just the right tool for the job. Two examples I can think of are: * VM implementations (I mentioned Factor, but also HotSpot, Microsoft's CLR, SquirrelFish, TraceMonkey, V8 and Opera's Carakan are all high-performance VMs written in C++ (x). Note also that all major layout engines are written in C++. Complex but fast and highly-tuned beasts) * Production rendering. PRMan, MentalRay and pretty much every other renderer in day-to-day use on film and video post-production are written in C++. People who write these systems care deeply about performance. They'll dip into assembly when they have to. While fast, C won't cut it because in these cases, it doesn't give you enough abstraction to avoid making your code a mess (strong typing, operator overloading and templates in particular, but also virtual method dispatch)*. I'm sure if you ask them, they'd tell you that they'd love to use something nicer and more modern. But it doesn't yet exist. This is not to say that C++ is the right tool for writing web applications, or even the average desktop application, or even - increasingly these days - games. But somebody needs to write the stack underneath, and that stack needs to be fast. (x) note Mono as an example of a VM that sticks with C. But it contains a lot of object-oriented shennanigans that probably could be better expressed in C++, and the core developers came from a strong C culture.
barrkel 17y ago
The canonical anti-C++ link for me has to be http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/ - pretty thorough and reasonably well argued.
- alaricsp 17y ago
  That is indeed a most potent collection of detailed arguments! Now, let's just wait for my colleague to start ribbing me for keeping our project written in C again... ;-)
psranga 17y ago
From my perspective, most of the stuff about C++ complexity rings untrue. Most people I know seem to know enough about C++ that they can produce pretty good code. Yes, there's a lot of depth to C++ but you derive a lot of benefit from other's wizardry even if you're not a magician yourself. Maybe this guy didn't invest as much time on C++ as he did on his other languages.
- acg 17y ago
  Perhaps, or perhaps C++ programmers who defend the language haven't spent enough time in other languages. If you are just plugging components together I can think of better languages. In my experience C++ demands more time that most languages to master. Which is a far longer time than, say, C.
- ajross 17y ago
  I think that's not the right criteria though. Are most of the people you know capable maintaining other people's C++ code? The idea that you can write (!) sane code in C++ by using a simple/sane subset is of course true. But the problem is that in a language of this complexity no two people are going to be able to agree on what that sane subset is. One person may love auto_ptr and use it everywhere, confusing her coworkers who don't get reference counting idioms, but love the STL... By the time you manage to get your project's coding standards hammered out and enforced, and get it rigged up so it can talk to your external libraries that don't adhere to those standards, you might as well have given up and used C to begin with.
  - eru 17y ago
    I agree. (Might I add that reference counting is evil (and slower than true garbage collection).)
- alaricsp 17y ago
  FWIW, I'm working in C for my day job (and resisting calls to move up to C++), as my day job involves shuffling bytes around rather than particularly complex code; it's ~20KLOC. Then we build the tools to manage it in Python with a bit of shell scripting here and there. However, I code Scheme in my spare time, and would do the lot in that if I didn't then have to justify training new developers in Scheme! C's the right tradeoff for commercially developing a high-performance database kernel, IMHO. I've done plenty of C++ in past jobs... which is why my day job is in C :-)

17 points by alaricsp 17y ago

That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually faster, with some properly done benchmarks or some valid technical examples.

eru 17y ago
Common Lisp is already quite fast and dynamic. And for the same number of hacker-hours spend in optimizing, you probably get a larger speedup. Also Python+C can be quite a fast combo. Fast to develop and fast to execute. Forth is also quite fast and dynamic, if you grok it. A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages. If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++. For benchmarks see: http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/
- jcl 17y ago
  I can't help feeling that Common Lisp should be doing better, considering that it's a language where you can effectively tell the compiler "It's OK to store this variable in a register". It's currently doing about the same as Mono, which IIRC doesn't JIT, and worse than Java. The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.
  - eru 17y ago
    The quality of the individual programs plays a large role. E.g. GHC (Haskell) has made huge strides in the past thanks to better libraries and implementations for the benchmark, despite nearly the same compiler. On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.
    - igouy 17y ago
      > despite nearly the same compiler As you don't say how far "in the past" maybe that's nonsense or maybe that's true. > a lot of the benchmarks had to be reformulated after lazy languages got fast That's nonsense. Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated - http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=clean&id=1#about http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
      - jcl 17y ago
        I love the shootout, by the way. Thanks for maintaining it.
        igouy 17y ago
        Thanks to those who contribute programs. Every week there are new programs, often from people who haven't contributed a program before. One of these days someone will find a way to make effective use of all the cores for n-body, maybe.
      - eru 17y ago
        Thanks for clearing that up. I wrote from my unreliable memory.
- UncleOxidant 17y ago
  OCaml does quite well against C++ in the shootout. OCaml's Functors and type inferrence are a big win over C++ templates. Yeah, the syntax takes some getting-used-to, but all in all the language seems to hang together much better than C++ (perhaps not saying much)
  - eru 17y ago
    I agree. I like Haskell's syntax better. But their syntaxen are nearly isomorphic for the most common stuff.
    - UncleOxidant 17y ago
      I'm finding OCaml's approach to be a bit more practical even if it isn't as pure as Haskell. Once in a while it's nice to be able to drop into an imperative style or even do some OO and OCaml lets you do all of that.
      - eru 17y ago
        Yes. Though Haskell allows imperative style (via Monads), too.
- dtf 17y ago
  I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.
magv 17y ago
More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC. I do not know why this fact remains so little-known. [1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd839daf http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
- psranga 17y ago
  Note the comparison is to C, not C++. The runtime improvement came from aggressive inlining. I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same. Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc. The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass. In these days of 16G developer desktops, is this an unreasonable demand? :)
  - gchpaco 17y ago
    In fact C++ is usually slower than C because parsing and comprehending it is so damned hard that compiler writers are satisfied when they can get that far.
alaricsp 17y ago
That day may not be too far off... I hope ;-)

cbeust 17y ago

I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.

gruseom 17y ago
one of the requirements for this kind of speed is for a language to be statically typed No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
- cbeust 17y ago
  You need to make languages fast on both dimensions, static and dynamic. A dynamically typed language can only be optimized in one dimension, which is why they usually trail behind statically typed languages in performances (since those are optimized along both axes).
  - alaricsp 17y ago
    I've not seen anything like the dynamic-dispatch optimisations the Self team came up with in the 1990s done in C++, nor problem-domain optimisations expressed as macros as is often done in Lisps, nor the aggressive constant-propagation of closures and their eventual inlining that Factor does. Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...
    - eru 17y ago
      Do you know Synthesis OS (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4871 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...). The author made the OS specialize (and thus optimize) system calls during runtime (or something like that, it's been a while since I read the paper). The techniques might me applicable in higher-level languages than the assembler used there.

dtf 17y ago

I guess he's not a systems programmer. What language did Slava Pestov turn to when he recently re-wrote Factor's VM? C++ programmers: we do the dirty work so you don't have to.

Legion 17y ago
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
- acg 17y ago
  Hardly, I know many people who spent years learning C++ in the 90's only to avoid it now. The reason is they had no love for the language. The C++ language design has serious flaws that whenever someone brings them up there's the usual, rolling of the eyes and the "yeah we know" sort of look. The if you criticise you must be a dumb attitude is encouraged by the C++ community too, and that was not borrowed from the C community: where the emphasis was beautiful tight code (like the K&R manual itself). Lets face it C++ is something like 30 years old this year. For a 30 year language to have so many flaws, and for newer languages to make a better job of integrating OO while still keeping the power: you have to ask whether the C++ community really knows all about technology and nothing about design. The whole project has been mislead from start to finish. It strikes me it had to take a couple of ada programmers to write the STL.
  - dtf 17y ago
    C++ hits a certain sweet spot. In some cases - whether you like it or not - it's just the right tool for the job. Two examples I can think of are: * VM implementations (I mentioned Factor, but also HotSpot, Microsoft's CLR, SquirrelFish, TraceMonkey, V8 and Opera's Carakan are all high-performance VMs written in C++ (x). Note also that all major layout engines are written in C++. Complex but fast and highly-tuned beasts) * Production rendering. PRMan, MentalRay and pretty much every other renderer in day-to-day use on film and video post-production are written in C++. People who write these systems care deeply about performance. They'll dip into assembly when they have to. While fast, C won't cut it because in these cases, it doesn't give you enough abstraction to avoid making your code a mess (strong typing, operator overloading and templates in particular, but also virtual method dispatch)*. I'm sure if you ask them, they'd tell you that they'd love to use something nicer and more modern. But it doesn't yet exist. This is not to say that C++ is the right tool for writing web applications, or even the average desktop application, or even - increasingly these days - games. But somebody needs to write the stack underneath, and that stack needs to be fast. (x) note Mono as an example of a VM that sticks with C. But it contains a lot of object-oriented shennanigans that probably could be better expressed in C++, and the core developers came from a strong C culture.

barrkel 17y ago

The canonical anti-C++ link for me has to be http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/ - pretty thorough and reasonably well argued.

alaricsp 17y ago
That is indeed a most potent collection of detailed arguments! Now, let's just wait for my colleague to start ribbing me for keeping our project written in C again... ;-)

psranga 17y ago

From my perspective, most of the stuff about C++ complexity rings untrue. Most people I know seem to know enough about C++ that they can produce pretty good code. Yes, there's a lot of depth to C++ but you derive a lot of benefit from other's wizardry even if you're not a magician yourself. Maybe this guy didn't invest as much time on C++ as he did on his other languages.

acg 17y ago
Perhaps, or perhaps C++ programmers who defend the language haven't spent enough time in other languages. If you are just plugging components together I can think of better languages. In my experience C++ demands more time that most languages to master. Which is a far longer time than, say, C.
ajross 17y ago
I think that's not the right criteria though. Are most of the people you know capable maintaining other people's C++ code? The idea that you can write (!) sane code in C++ by using a simple/sane subset is of course true. But the problem is that in a language of this complexity no two people are going to be able to agree on what that sane subset is. One person may love auto_ptr and use it everywhere, confusing her coworkers who don't get reference counting idioms, but love the STL... By the time you manage to get your project's coding standards hammered out and enforced, and get it rigged up so it can talk to your external libraries that don't adhere to those standards, you might as well have given up and used C to begin with.
- eru 17y ago
  I agree. (Might I add that reference counting is evil (and slower than true garbage collection).)
alaricsp 17y ago
FWIW, I'm working in C for my day job (and resisting calls to move up to C++), as my day job involves shuffling bytes around rather than particularly complex code; it's ~20KLOC. Then we build the tools to manage it in Python with a bit of shell scripting here and there. However, I code Scheme in my spare time, and would do the lot in that if I didn't then have to justify training new developers in Scheme! C's the right tradeoff for commercially developing a high-performance database kernel, IMHO. I've done plenty of C++ in past jobs... which is why my day job is in C :-)