4 ms·

The question isn't "Can C++ work?" or "Will C++ be faster?" because we all know it can work and that it will be faster. The question is "At what point does the

by SamAtt 17y ago

The question isn't "Can C++ work?" or "Will C++ be faster?" because we all know it can work and that it will be faster. The question is "At what point does the extra development time become more expensive than just adding another server to my Ruby/Python/C#/Whatever App" For me, someone who learned C++ in school but has been in managed enviornments ever since, I'd be too scared to use C++. I'm not ashamed to admit I get a lot of help from the Internet when I'm stuck on a problem and that help is available because everyone else is using the same tools I am. Using C++ to code web apps puts you out in the wilderness as far as I'm concerned and I just don't think I could do it.

techiferous 17y ago
"because we all know it can work and that it will be faster" Speed of execution depends more on the programmer's expertise than the language used.
- jrockway 17y ago
  Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.
  - dualogy 17y ago
    So maybe he meant "on the expertise of the programmer" -- of the language/compiler...
  - fhars 17y ago
    But then your expertise is not that different from your expertise. Your perl will probably still be faster overall than a beginner's haskell, not for the same algorithm, but for solutions to the same problem. Knowing which algorithms perform well for a given problem solved in perl is the most relevant part of expertise.
  - anonjon 17y ago
    Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Perl, will I ever reach the efficient algorithm? I might call it quits when I finally get something to compile and not segfault. (Of course even this is kind of a strawman, because the perl guy can just reimplement in C++ when he figures out that he wants more speed out of his good algorithm).
    - fauigerzigerk 17y ago
      "Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
      - jrockway 17y ago
        I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affects. If you have a job to do that wants to use 8 cores, split the job up into 8 parts and invoke your program 8 times. There's your 8x speedup.)
        ramchip 17y ago
        > 2x faster at best That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the compression time. Using a thread pool was the solution, not because of an actual increase in speed, but because from the loop's POV the write went from blocking to non-blocking so the CPU stopped wasting time waiting for the disk. We also wanted shared memory since there can be a lot of image data which is shared between the image compression & saving, display, and possibly statistics or filtering modules.
spamizbad 17y ago
And it's not just the dev time: with C++ (and C, and any notorious unsafe language..) you've got to be extra diligent about security, which uses even more time, and requires expertise not just in C++ but also how to write secure software in low level languages... a skill many C/C++ devs lack, unfortunately.

by SamAtt 17y ago

techiferous 17y ago

"because we all know it can work and that it will be faster" Speed of execution depends more on the programmer's expertise than the language used.

jrockway 17y ago
Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.
- dualogy 17y ago
  So maybe he meant "on the expertise of the programmer" -- of the language/compiler...
- fhars 17y ago
  But then your expertise is not that different from your expertise. Your perl will probably still be faster overall than a beginner's haskell, not for the same algorithm, but for solutions to the same problem. Knowing which algorithms perform well for a given problem solved in perl is the most relevant part of expertise.
- anonjon 17y ago
  Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Perl, will I ever reach the efficient algorithm? I might call it quits when I finally get something to compile and not segfault. (Of course even this is kind of a strawman, because the perl guy can just reimplement in C++ when he figures out that he wants more speed out of his good algorithm).
  - fauigerzigerk 17y ago
    "Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
    - jrockway 17y ago
      I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affects. If you have a job to do that wants to use 8 cores, split the job up into 8 parts and invoke your program 8 times. There's your 8x speedup.)
      - ramchip 17y ago
        > 2x faster at best That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the compression time. Using a thread pool was the solution, not because of an actual increase in speed, but because from the loop's POV the write went from blocking to non-blocking so the CPU stopped wasting time waiting for the disk. We also wanted shared memory since there can be a lot of image data which is shared between the image compression & saving, display, and possibly statistics or filtering modules.

spamizbad 17y ago

And it's not just the dev time: with C++ (and C, and any notorious unsafe language..) you've got to be extra diligent about security, which uses even more time, and requires expertise not just in C++ but also how to write secure software in low level languages... a skill many C/C++ devs lack, unfortunately.