Writing low level DSP code in C++ in lieu of C

Hello, in my experience I've mostly used the C programming language in
programming DSP's. I only have experience with Analog DSPs. I was
wondering if most people use  the C language rather than C++. I found
an article at embedded.com that you might find interesting:
http://www.embedded.com/212101526?printable=true

Are many DSP programmers switching to C++?

Thanks,
joe

On 24 Mrz., 22:14, "jjlind...@hotmail.com" <jjlind...@hotmail.com>
wrote:
> Hello, in my experience I've mostly used the C programming language in
> programming DSP's. I only have experience with Analog DSPs. I was
> wondering if most people use &#4294967295;the C language rather than C++. I found
> an article at embedded.com that you might find interesting:
> http://www.embedded.com/212101526?printable=true

I'm not exactly a "DSP programmer" or someone who tries to run code on
embedded platforms.  But I'd like to quote a paragraph of the article
and comment on it:

  "My experience is that, with modern C++ compilers, introducing
   such abstractions  rarely has any  runtime cost.  On the rare
   occasion that it does have a cost,  you can always strip away
   the abstraction and use C++ as if it were C."

This comes after some basic class/member function example.  It's
perfectly true.  I would even go further and say that this kind of
"abstraction" doesn't have ANY extra runtime costs EVER.  Why should
it?

C++ being less efficient than C is kind of a myth.  Debunking this
myth was the main motivation for the authors of the following
technical report:

   "Technical Report on C++ Performance"
   http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf


Cheers!
SG

On 24 Mar, 23:08, SG <s.gesem...@gmail.com> wrote:
> &#4294967295;I would even go further and say that this kind of
> "abstraction" doesn't have ANY extra runtime costs EVER. &#4294967295;Why should
> it?

Well, one example is virtual functions. Virtual functions
can not be inlined, which would be a performance cost
compared to inlined code. Virtual functions also have to
be dereferenced through a function table, which also is
a performance cost.

> C++ being less efficient than C is kind of a myth.

It is certainly possible to write very efficient C++ code,
but you'll have to know exactly what you are doing.

Rune

On Mar 24, 6:33&#4294967295;pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 24 Mar, 23:08, SG <s.gesem...@gmail.com> wrote:
>
> > C++ being less efficient than C is kind of a myth.
>
> It is certainly possible to write very efficient C++ code,
> but you'll have to know exactly what you are doing.
>

Rune is quite correct.

i dunno specifically what the OP or others do with processing samples
in C++, but you wouldn't want the sorta recursive invoking of
inherited functions (or "methods", is that the right word?).  things
like connecting inputs and outputs of processing objects or connecting
parameters, that can be done nicely and elegantly in C++, but the
sampling processing should be done like it is in asm or C where the
oopsey features of C++ are of no help.  i also think that samples
should be processed in blocks of multiple samples for efficiency.

but if you're processing one sample at a time (with each object in the
overall algorithm structure) and calling parent methods which
themselves call their parent methods, i kinda think that would be
dreadfully slow or inefficient.

r b-j

On Tue, 24 Mar 2009 14:14:41 -0700, jjlindula@hotmail.com wrote:

> Hello, in my experience I've mostly used the C programming language in
> programming DSP's. I only have experience with Analog DSPs. I was
> wondering if most people use  the C language rather than C++. I found an
> article at embedded.com that you might find interesting:
> http://www.embedded.com/212101526?printable=true
> 
> Are many DSP programmers switching to C++?
> 
> Thanks,
> joe

In my experience with DSP applications, perhaps 0.1% of the code consumes 
80% of the processor time.  The rest of the code consumes, well -- the 
rest.

That 0.1% gets written in assembly, the rest gets written in C++.

-- 
http://www.wescottdesign.com

On 24 Mrz., 23:33, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 24 Mar, 23:08, SG <s.gesem...@gmail.com> wrote:
>
> > &#4294967295;I would even go further and say that this kind of
> > "abstraction" doesn't have ANY extra runtime costs EVER. &#4294967295;Why should
> > it?
>
> Well, one example is virtual functions. Virtual functions
> can not be inlined, which would be a performance cost
> compared to inlined code. Virtual functions also have to
> be dereferenced through a function table, which also is
> a performance cost.

1. I was referring to the example in the article which doesn't contain
virtual functions
2. You would not use virtual functions for no reason. An emulation in
C via function pointers is not more efficient.

Cheers!
SG

Rune Allnor wrote:

> On 24 Mar, 23:08, SG <s.gesem...@gmail.com> wrote:
>> I would even go further and say that this kind of
>> "abstraction" doesn't have ANY extra runtime costs EVER. &#4294967295;Why should
>> it?
> 
> Well, one example is virtual functions. Virtual functions
> can not be inlined, which would be a performance cost
> compared to inlined code. Virtual functions also have to
> be dereferenced through a function table, which also is
> a performance cost.

This is true, but in C you must use function pointers or a 
switch statement to get the same functionality, and this
also costs performance. 

>> C++ being less efficient than C is kind of a myth.
> 
> It is certainly possible to write very efficient C++ code,
> but you'll have to know exactly what you are doing.

There are some features which should not be used
because they insert hidden code almost everywhere:
- exeptions
- RTTI

Otherwise all other advanced features in C++ do not
result in a performance penalty over C, you just have to
write much more code to get the same functionality,
and you have the big chance to forget to write some
of this code, resulting in a buggy program.

One big advantage in C++ in embedded software 
development is the use of template classes and policy
based design[1] such, that you write one implementation
for the real hardware and one implementation for the
software simulator and have only one place in the code
where you define which version is used (usually just  a
typedef). In C you would clutter your code with macros.

[1] as an example: device control via memory mapped IO

You write to a fixed address to do some change in the
hardware. This cannot work in the simulator where this 
hardware address does not exist. I wrote a template
class with two templates which implements a write() 
function to a hardware address:
- the 1st template parameter (AccessPolicy) specifies 
  how the write is actually done
- the 2nd template parameter (LogPolicy) specifies how 
  the write to this address is logged (for debugging and 
  test purposes)

There are two versions of AccessPolicy:
- one version writes to the specified address. It is used
  on the hardware.
- one version writes to a STL map which simulates the memory
  on the hardware. It  is used in the simulator.

There are also two versions of LogPolicy:
- one version does nothing. It is used on the hardware.
- one version writes the memory access data (address and
  value) into a STL vector. It  is used in the simulator. For
  the test of a given task you clear this vector, run the
  function to be tested and inspect the vector for the
  correct chain of write accesses. I use this for unit tests.

In code:
#ifdef SIMULATOR
typedef MemAccess<AccessPolicyMap, LogPolicyVector> MyMemAccess;
#else
typedef MemAccess<AccessPolicyPhysical, LogPolicyNone> MyMemAccess
#endif

MyMemAccess mem_access;

// switch output:
mem_access.write(output_address, value); // same as: *(volatile int*)output_address = value;

I verified that using this construction on the hardware
creates the same assembler code like a direct write to
an address, so there is no overhead.
  
bye
Andreas
-- 
Andreas H&#4294967295;nnebeck | email: acmh@gmx.de
----- privat ---- | www  : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc
PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc

jjlindula@hotmail.com wrote:

> Hello, in my experience I've mostly used the C programming language in
> programming DSP's. I only have experience with Analog DSPs.

I mostly use pen and paper for programming. For coding, I use whatever 
is appropriate: C, C++, assembler or anything else.

> I was
> wondering if most people use  the C language rather than C++.

C is the outdated dialect of C++ which is sometimes handy for the small 
programs and resource constrained systems.


> I found
> an article at embedded.com that you might find interesting:
>http://www.embedded.com/212101526?printable=true

Ah, Dan Saks... Trivial and boring.
Jack Gansle is the one worth reading in that magazine.

> Are many DSP programmers switching to C++?

Think about the process. Coding it is the minor technical problem.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

jjlindula@hotmail.com wrote:

> Hello, in my experience I've mostly used the C programming language in
> programming DSP's. I only have experience with Analog DSPs.

I mostly use pen and paper for programming. For coding, I use whatever 
is appropriate: C, C++, assembler or anything else.

> I was
> wondering if most people use  the C language rather than C++.

C is the outdated dialect of C++ which is sometimes handy for the small 
programs and resource constrained systems.


> I found
> an article at embedded.com that you might find interesting:
>http://www.embedded.com/212101526?printable=true

Ah, Dan Saks... Trivial and boring.
Jack Gansle is the one worth reading in that magazine.

> Are many DSP programmers switching to C++?

Think about the process. Coding it is the minor technical problem.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

jjlindula@hotmail.com wrote:

> Hello, in my experience I've mostly used the C programming language in
> programming DSP's. I only have experience with Analog DSPs.

I mostly use pen and paper for programming. For coding, I use whatever 
is appropriate: C, C++, assembler or anything else.

> I was
> wondering if most people use  the C language rather than C++.

C is the outdated dialect of C++ which is sometimes handy for the small 
programs and resource constrained systems.


> I found
> an article at embedded.com that you might find interesting:
>http://www.embedded.com/212101526?printable=true

Ah, Dan Saks... Trivial and boring.
Jack Gansle is the one worth reading in that magazine.

> Are many DSP programmers switching to C++?

Think about the process. Coding it is the minor technical problem.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com