[music-dsp] C++ performance
richarddobson at blueyonder.co.uk
Fri Oct 29 05:31:55 EDT 2010
But the discussion is on processing speed = power, not on
semantic/structural expressivity = power. It is always tempting to
equate the two, but I do not think that is safe. Given the same
template code in C++, we would still be interested in which ~compiler~
translates it into the fastest machine code, where both cpu speed and
ram are somewhat constrained (ARM on iPhone) compared to the luxury of
3GHZ multi-core cpus with 8GB of fast RAM to play in. And then, in
whether it is faster than what hand-rolled C can produce. FFTW remains
written in C - I am sure that if it led to a significant speed increase,
given their interest in benchmarks, they would have moved it all to C++
by now. Many large systems clearly benefit from the language facilities
of C++, to the extent that they might not be able to be written in C in
a reasonable timescale, but this does not mean a priori that ~all~
possible algorithms (especially thosw with loads as extremely variable
as must msuic apps) on all possible platforms will benefit similarly.
For a lot of heavy HPC computation, Fortran is still in very widespread
use, as it is still regarded as achieving the fastest raw performance.
And I doubt if even the new parallel stuff in the planned new C++ can
really address the massively-parallel processing tasks that need the
power of Cuda/OpenCL etc. I get the impression that while the
architectural level of an app may be written in C++, the critical dsp
code may even today be implemented in assembler (or hand-optimised C).
No need for templates if you know everything is always going to be in
On 29/10/2010 01:21, Michael Gogins wrote:
> I think your take on C++ is rather skewed, First, consider what
> languages actually are used to write critical software. Avionics,
> scientific data processing, performance-critical consumer software,
> are mostly (and increasingly) written in C++ not C.
More information about the music-dsp