[music-dsp] C++ performance

[Alan Wolfe]

you may already know this, and this may be in MG's programming tips
but one of the most common mistakes less experienced programmers make
is premature optimization.

That is, optimizing before there is a problem, or without
understanding what exactly the problem is.

Another mistake that less experienced programmers make is too much
focus on micro optimizations such as changing multiplies to bit shifts
and things like that, without first trying macro optimizations such as
changes in the algorithms.  Macro optimizations often win you far more
than micro optimizations.

Basically, write your program as best you can, then profile it to see
where the slowdown happens.  Address the slowdown and then run the
program again.  If it's still too slow, go back to the profiling step
and repeat until your program is fast enough.

On Wed, Oct 27, 2010 at 7:03 AM, Michael Gogins
<michael.gogins at gmail.com> wrote:
> You may be interested in my advice on programming, most of which is
> based on experience with music programming:
>
> http://michael-gogins.com/?p=299
>
> Regards,
> Mike Gogins
>
> On Wed, Oct 27, 2010 at 7:59 AM, Thomas Strathmann <thomas at pdp7.org> wrote:
>> On 10/27/10 13:16 , Andre Michelle wrote:
>>>>
>>>> Not sure exactly what you're asking. Simple inlined classes can get
>>>> pretty lightweight, but it really depends what you do inside them.
>>>> Again, if you can read assembly code, this can be output and it will
>>>> tell you what you want to know about what is happening with your code.
>>>
>>> The idea is to tell the compiler, that he should embed everything from the
>>> class for every instance I create in my implementation. This way I get rid
>>> of scope changes. Maybe this is not a good idea at all. Obviously I cannot
>>> read assembly nor do I have the tools to output them. Anything you can
>>> recommend (best case for xCode) is much appreciated.
>>
>> Some generic advice first:
>>
>> 1. Get to know your compiler and library and write "common sense" code
>>   that the compiler knows how to deal with in an (near to) optimal way.
>> 2. Use a profiler (gprof, Instruments.app, etc.) to identify those
>>   parts of the code that are performance critical and could be
>>   improved.
>> 3. Don't optimize until you have concrete evidence that something
>>   should be optimized (i.e. don't play the "let's see what compiler
>>   switch I do not use already" game).
>> 4. To reiterate: Don't think your cleverer than the people who wrote
>>   the compiler and the runtime and don't try to port idioms from
>>   other languages in the hope of making your code run faster.
>>
>> As for assembler: If you really care about performance there's no way around
>> learning to read the compiler's output. This is the only valid way of
>> removing doubt about whether the compiler actually does the optimization you
>> had in mind. To look at assembler code (assuming you use gcc) use "gcc -S
>> foo.c". It takes some getting used to, but it's well worth it. Sometimes
>> you'll be able to just get the info you want by doing A-B comparisons of the
>> generated assembler code.
>>
>>        Thomas
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book reviews, dsp
>> links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>