5 ms·

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads

by adwn 12y ago

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unbeaten: scientific computing libraries. If you want/need maximum performance, then right now, there's no other language that has no overhead and zero-cost abstractions (to the degree that C++, especially C++11, has them). Hopefully Rust will get there eventually, but as of today, you have three choices: Fortran, C, and C++ – and neither C nor Fortran offer any abstractions worth mentioning.

Touche 12y ago
I don't understand your complaint, isn't "scientific computing libraries" a niche?
- adwn 12y ago
  > isn't "scientific computing libraries" a niche In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one. Sorry, I should have been clearer on that. [1] If you're not convinced, I can give you a lot more examples.
fulafel 12y ago
Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. Then again I haven't heard the term used outside C++ circles and its meaning is nebulous, so maybe it's just a name for C++'s tradeoffs?)
- edgarbob 12y ago
  Hopefully Rust's approach to zero-overhead abstractions will alleviate a lot of the problems you run into in C++.
- markrages 12y ago
  For embedded DSP, the preferred language is C (no ++). The extra complexity the ++ adds is of little or no value in small embedded systems.
- adwn 12y ago
  > Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I agree with you. But as with most prices, sometimes they are worth it. There are a lot of practical cases where you really want the performance (even outside scientific computing, which in itself is a pretty widely applied field). > I'm sure there are some fields of academia where this is a reasonable tradeoff I'm not sure where you got "academia" from; scientific computing is in no way restricted to research. Weather predictions, genome processing, and oil reserves exploration are just three of many examples for the commercial application of scientific computing. > (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) DSP applications are ubiquitous today; you'll find them, e.g., in your phone, or in your car. > but your generic number crunching job rarely calls for it. You're very wrong. Number crunching is the example for which you want lots of performance. > As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. I didn't say they are. I said that no other language offers them to the degree that C++ does. > so maybe it's just a name for C++'s tradeoffs? No. It means abstractions which do not cause runtime overheads because the compiler can optimize them away.
seanmcdirmid 12y ago
You forgot to mention CUDA, which is trouncing Fortran, C, and C++ in performance and being adopted at a fast rate. Now, one could argue that CUDA is a dialect of C++, but it is much more than that.
- adwn 12y ago
  CUDA is a special purpose language, the same way that, e.g., VHDL or Verilog are special purpose languages.
  - seanmcdirmid 12y ago
    Those doing real HPC work really don't have a choice these days (they will be out competed otherwise), unless of course the problem isn't GPU friendly.
deleted 12y ago
[deleted]
onalark 12y ago
If you want/need maximum performance, why are you programming in a "high-level language"? Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. The vast majority of scientific programmers don't need to write at this level. I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to MATLAB, Python/Cython, and Julia through their interface to the assembly-optimized OpenBLAS library: http://julialang.org/ http://julialang.org/ Note that C, Fortran, and Julia are all using OpenBLAS in the rand_mat_mul benchmark, and OpenBLAS is written in C (with assembly).
- adwn 12y ago
  > If you want/need maximum performance, why are you programming in a "high-level language"? Because going to assembly offers so little benefit (if at all), that it doesn't justify the huge increase in effort and susceptibility to bugs in most cases (and even then, inline assembly is usually sufficient). > Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. I don't think this is true, at least not for non-inline assembly. Sure, OpenBlAS contains a lot of assembly, but many scientific computing algorithms are more complex than the BLAS routines. > I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to [...] Where in my post did I give you the idea that I don't like code reuse and instead reinvent the wheel every time?
  - onalark 12y ago
    edit: Jack Poulson's Elemental, and Andreas Waechter's IPOPT are also written in C++, and are both very important libraries within scientific computing and optimization, to add a few more examples of the usefulness of C++. I'm trying to make the point that C++ occupies a weird place in the abstraction-vs-performance tradeoff. For high abstraction and friendliness, C++ doesn't do nearly as nice of a job as MATLAB or Python in exposing high-level scientific computing operations. For performance, C++ does have some really nice high-performance libraries (Eigen comes to mind), but for the majority of use cases, you either need to write inline assembly to get the best possible speed, or you're already reusing a fast numerical kernel from another library, and you may be better off in a higher-level language. This is a very subjective discussion, and there are many interesting, fast, C++ libraries that do important work for science. But your claim that C++ is the best language for such work would be highly contested by many high performance computing specialists. As it is, I believe there's a pretty rough split between C, C++, and Fortran supporters, with Python continuing to gain traction. Here's another counter-argument. MPI is used in 99% of all scientific high performance computing codes. The latest version of MPI, MPI-3, drops explicit support for C++ bindings. If C++ was so dominant, why would explicit bindings be dropped?
rdtsc 12y ago
C++ has been pushed into performance niches. Those are big niches though. Games, real-time programming, high performance networking. But it is not used _as_ much as in the past for core business logic. There are legacy system that will run for many years. A lot of web backends are not not in C++ when in the past they were. It was the language to rule them all, but now in some areas others have taken over.
- adwn 12y ago
  I agree 100% with what you said. I would never advocate C++ for business logic. In fact, I wouldn't use it for anything which doesn't really need the most performance available (and even there I would try to restrict its usage to the actual performance bottleneck).

by adwn 12y ago

Touche 12y ago

I don't understand your complaint, isn't "scientific computing libraries" a niche?

adwn 12y ago
> isn't "scientific computing libraries" a niche In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one. Sorry, I should have been clearer on that. [1] If you're not convinced, I can give you a lot more examples.

fulafel 12y ago

Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. Then again I haven't heard the term used outside C++ circles and its meaning is nebulous, so maybe it's just a name for C++'s tradeoffs?)

edgarbob 12y ago
Hopefully Rust's approach to zero-overhead abstractions will alleviate a lot of the problems you run into in C++.
markrages 12y ago
For embedded DSP, the preferred language is C (no ++). The extra complexity the ++ adds is of little or no value in small embedded systems.
adwn 12y ago
> Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I agree with you. But as with most prices, sometimes they are worth it. There are a lot of practical cases where you really want the performance (even outside scientific computing, which in itself is a pretty widely applied field). > I'm sure there are some fields of academia where this is a reasonable tradeoff I'm not sure where you got "academia" from; scientific computing is in no way restricted to research. Weather predictions, genome processing, and oil reserves exploration are just three of many examples for the commercial application of scientific computing. > (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) DSP applications are ubiquitous today; you'll find them, e.g., in your phone, or in your car. > but your generic number crunching job rarely calls for it. You're very wrong. Number crunching is the example for which you want lots of performance. > As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. I didn't say they are. I said that no other language offers them to the degree that C++ does. > so maybe it's just a name for C++'s tradeoffs? No. It means abstractions which do not cause runtime overheads because the compiler can optimize them away.

seanmcdirmid 12y ago

You forgot to mention CUDA, which is trouncing Fortran, C, and C++ in performance and being adopted at a fast rate. Now, one could argue that CUDA is a dialect of C++, but it is much more than that.

adwn 12y ago
CUDA is a special purpose language, the same way that, e.g., VHDL or Verilog are special purpose languages.
- seanmcdirmid 12y ago
  Those doing real HPC work really don't have a choice these days (they will be out competed otherwise), unless of course the problem isn't GPU friendly.

deleted 12y ago

[deleted]

onalark 12y ago

If you want/need maximum performance, why are you programming in a "high-level language"? Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. The vast majority of scientific programmers don't need to write at this level. I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to MATLAB, Python/Cython, and Julia through their interface to the assembly-optimized OpenBLAS library: http://julialang.org/ http://julialang.org/ Note that C, Fortran, and Julia are all using OpenBLAS in the rand_mat_mul benchmark, and OpenBLAS is written in C (with assembly).

adwn 12y ago
> If you want/need maximum performance, why are you programming in a "high-level language"? Because going to assembly offers so little benefit (if at all), that it doesn't justify the huge increase in effort and susceptibility to bugs in most cases (and even then, inline assembly is usually sufficient). > Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. I don't think this is true, at least not for non-inline assembly. Sure, OpenBlAS contains a lot of assembly, but many scientific computing algorithms are more complex than the BLAS routines. > I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to [...] Where in my post did I give you the idea that I don't like code reuse and instead reinvent the wheel every time?
- onalark 12y ago
  edit: Jack Poulson's Elemental, and Andreas Waechter's IPOPT are also written in C++, and are both very important libraries within scientific computing and optimization, to add a few more examples of the usefulness of C++. I'm trying to make the point that C++ occupies a weird place in the abstraction-vs-performance tradeoff. For high abstraction and friendliness, C++ doesn't do nearly as nice of a job as MATLAB or Python in exposing high-level scientific computing operations. For performance, C++ does have some really nice high-performance libraries (Eigen comes to mind), but for the majority of use cases, you either need to write inline assembly to get the best possible speed, or you're already reusing a fast numerical kernel from another library, and you may be better off in a higher-level language. This is a very subjective discussion, and there are many interesting, fast, C++ libraries that do important work for science. But your claim that C++ is the best language for such work would be highly contested by many high performance computing specialists. As it is, I believe there's a pretty rough split between C, C++, and Fortran supporters, with Python continuing to gain traction. Here's another counter-argument. MPI is used in 99% of all scientific high performance computing codes. The latest version of MPI, MPI-3, drops explicit support for C++ bindings. If C++ was so dominant, why would explicit bindings be dropped?

rdtsc 12y ago

C++ has been pushed into performance niches. Those are big niches though. Games, real-time programming, high performance networking. But it is not used _as_ much as in the past for core business logic. There are legacy system that will run for many years. A lot of web backends are not not in C++ when in the past they were. It was the language to rule them all, but now in some areas others have taken over.

adwn 12y ago
I agree 100% with what you said. I would never advocate C++ for business logic. In fact, I wouldn't use it for anything which doesn't really need the most performance available (and even there I would try to restrict its usage to the actual performance bottleneck).