[music-dsp] C++ performance

[Richard Dobson]

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 
doubles!


Richard Dobson


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.
>
...