Stereo Tool

I don't think so, i have many many schematics where hardware RDS and stereo decoders are completly independent, maybe in Germany was something different... I don't know... In Poland it's doesn't matter 90 or 0, some, station has 0 some 90. Specification allows RDS subcarrier 0/180 and +/-90 to 3rd harmonic of pilot tone, +/-90 is better.

@Brian: I have checked all the vectorization reports of performance sensitive functions, and for nearly all of them I either made them vectorize or I understand why they aren't.

I'm trying to squeeze the last bit of optimization out of a program using Intel C++ 10.1 (because with later versions I'm getting slower code - I'll look into that later).

When looking at the vectorization reports, I noticed 2 things I hadn't expected, and I wonder if they can be solved (without rewriting lots of code - total code base is over 2 MB and I'm working on it alone). I've tried to google them but didn't find any useful answers.

This one seems to be the most important:

fft_abs_sse2[2*cc] = max(fft_abs_sse2[2*cc], strength * m);

.\Clip1Ch.cpp(1999): (col. 13) remark: vector dependence: proven ANTI dependence between fft_abs_sse2 line 1999, and fft_abs_sse2 line 1999.
.\Clip1Ch.cpp(1999): (col. 13) remark: vector dependence: proven ANTI dependence between fft_abs_sse2 line 1999, and fft_abs_sse2 line 1999.
.\Clip1Ch.cpp(1999): (col. 13) remark: vector dependence: proven FLOW dependence between fft_abs_sse2 line 1999, and fft_abs_sse2 line 1999.
.\Clip1Ch.cpp(1999): (col. 13) remark: vector dependence: proven FLOW dependence between fft_abs_sse2 line 1999, and fft_abs_sse2 line 1999.
.\Clip1Ch.cpp(1999): (col. 13) remark: vector dependence: proven ANTI dependence between fft_abs_sse2 line 1999, and fft_abs_sse2 line 1999.
...

While I know that there's an _mm_max_ SIMD instruction. Problem might be the definition of max, I'm using:
#define max(a,b) (((a)>(b)) ? (a) : (b))
The compiler might see this as an if instruction if it's unable to optimize everything out. Is there a better definition for max that doesn't cause the compiler to see dependencies where there are none?

Another situation that occurs very frequently in my code is this:

for (int c=0; c<f1; c++)
{
temp[2*c] *= one_DIV_bass_static_clip_level_dynamic;
temp[2*c+1] *= one_DIV_bass_static_clip_level_dynamic;
}

Clearly, there are no dependencies between temp[2*c] and temp[2*c+1], but the compiler thinks otherwise:

.\Clip1Ch.cpp(797): (col. 9) remark: loop was not vectorized: existence of vector dependence.
.\Clip1Ch.cpp(800): (col. 13) remark: vector dependence: proven FLOW dependence between temp line 800, and temp line 799.
.\Clip1Ch.cpp(800): (col. 13) remark: vector dependence: proven ANTI dependence between temp line 800, and temp line 799.
.\Clip1Ch.cpp(800): (col. 13) remark: vector dependence: proven OUTPUT dependence between temp line 800, and temp line 799.

I think if these two situations are solved at least 50% of the loops that currently don't get vectorized will be. Your help is greatly appreciated

The changes I made today should give a reduction of about 4% in the total CPU load (on the most active CPU core; reduction should be bigger on a single core system).

So, you now have the explanation for this and understand why it happens????

It's also why I've mentioned the MOVNTPS instruction. MOVNTPS helps minimize cache pollution, which would be beneficial to all systems, if you can use it, which you may or may not be able to.

No, I worked around it.

I almost never write data to memory that I don't need very quickly afterwards. So I don't expect much from this (I have used it at work in the past, so yes, I know what it does. But it's mainly useful if you're working on large amounts of data, not for short blocks of audio data.)

Edit: Just to make sure: This 3-5% is what you get when you divide the old CPU load by the new one? Absolute numbers don't mean much, I'm of course talking about relative changes.

Task Manager is often accurate, but sometimes it's not at all, and I really don't know when to trust it and when not.

By the way, 45% of the CPU cycles are now spent in an external Intel library that I have no influence on (except calling it less often of course), so improving things is getting increasingly harder.

Might be time to revisit the 13 vs. 10.1 compiler situation. I mean for future enhancements, not for this release. Then with that, I also don't mean 5-10 releases down the road, but stopping after this release and trying to figure out that issue.

Another performance improvement (probably about 9% compared to previous beta!)
Stand alone: http://www.stereotool.com/download/ster ... 04-053.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 04-053.exe
VST: http://www.stereotool.com/download/vst_ ... 04-053.dll