Stereo Tool

@Brian: Link is fixed.

N means *Intel* Pentium 4. W means Pentium 4. So I think W is the best one.

The N version is up and running. Performance is definitely not any worse from a subjective standpoint. I'll try the WAV conversion in a little bit. From what I'm reading, everyone is saying W, but something is sticking in my brain about the N option with respect to SETI...

Same track (Timbaland - Carry Out)

B127 with W flag - 2m 29s
N flag test version - 2m 28s

Statistically a tie. Whatever I'm remembering about the N flag and SETI (or some other BOINC project), it doesn't seem to make a difference here.

Per an AMD document, located here: http://support.amd.com/us/Processor_TechDocs/32035.pdf

...they suggest, for Intel 32-bit compiles on Windows:

3.11.2 Generic Performance Switches
Use of the -QxW -Qipo -O3 switches are recommended for Intel compiler version 10.0.
The -QxW switch instructs the compiler to optimize for Pentium 4 processor (including SSE2
instructions).
The -Qipo switch enables interprocedural (across multiple source files) analysis.
The -O3 optimizes for speed and includes several aggressive optimizations.

...because further on, they state that -QxN is "unsafe" and could lead to unexpected crashes.

O3 has a disclaimer in the Intel documentation ( http://cache-www.intel.com/cd/00/00/34/ ... 347599.pdf ) that it may not be better than O2 (the default) in some instances, and in some instances could be slower.

O3
Enables O2 optimizations plus more aggressive optimizations, such as prefetching, scalar replacement, and loop and memory access transformations. Enables optimizations for maximum speed, such as:
• Loop unrolling, including instruction scheduling
• Code replication to eliminate branches
• Padding the size of certain power-of-two arrays to allow more efficient cache use.

On Windows systems, the O3 option sets the /GF (/Qvc7 and above), /Gf (/Qvc6 and below), and /Ob2 option.
On Linux and Mac OS systems, the O3 option sets option -fomit-frame-pointer.
On systems using IA-32 and Intel® 64 architecture, when O3 is used with options -ax or -x (Linux) or with options /Qax or /Qx (Windows), the compiler performs more aggressive data dependency analysis than for O2, which may result in longer compilation times. On systems using IA-64 architecture, the O3 option enables optimizations for technical computing applications (loop-intensive code): loop optimizations and data prefetch.

The O3 optimizations may not cause higher performance unless loop and memory access transformations take place. The optimizations may slow down code in some cases compared to O2 optimizations. The O3 option is recommended for applications that have loops that heavily use floating-point calculations and process large data sets.

So, now we've come...to the end of the road...

Loop unrolling can also be much slower, if the cache isn't big enough to hold the unrolled loop. Keeping the same code looped but in cache is usually much faster. Something to think about.

Well, there are at least 10 more options that improve the performance. Took me quite a while to figure them all out, so I'm not going to post all of them here, but each of those options improves the performance by a few %.

I'm actually using /Ox (stronger than /O3), with function inlining disabled (unless I explicitly enable it for a function), to reduce code size. I can do a check what happens if I disable loop unrolling as well - I would hope that the compiler analyses whether unrolling makes things better or worse but it will probably only check for local effects, and of cause it causes the total code size to increase.

Ow, and -fomit-frame-pointer - already using that one, but I don't see any significant difference when enabling/disabling it.

Looking through the difference between O3 and Ox, the only possible options I would think that might make a difference is the stack checking (Gs) and flush to zero (ftz) that gets enabled with O3, but not with Ox.

I'd also agree with JesseG about the unroll in cache-limited situations, so maybe that would help on the lower end. If that does make a difference though, it would mean you'd have to decide whether or not it was worth the extra time / effort to produce and support another set of compilations. One idea for addressing that is to maybe have the installer be like a web installer. You'd provide the standard compile (unrolling enabled) in the main download, but the installer does a query on the amount of cache and if it is < 2MB per core, it downloads the unrolling disabled version... This way you don't have to have the end-user get confused with the array of choices and it gets handled for them...

If you want to try any of these things, I'll gladly test them...

There's already a check for SSE2 in the installer, both versions are included in the download (otherwise the installer executable would be only about 500 kB!).

I'll run a build with loop unrolling disabled for testing. Will restore the W (instead of N) option.

--> flush denormals to zero is also enabled in my build.

OK, so you could add a check for the amount of cache in the installer too. I have both an AMD system and a Northwood, non-HT core P4, so I can test the unroll-disabled version on 512K and 1MB cache...

@ Hans
Can also be saved display setting in declipper ?

Yes... Good one, forgot about that.


I'm looking at the Presets section, and there are really a lot of good new presets available. In my current interface I don't have much room, so what I'll do now is remove the 'Volume Compression' and 'Stereo Effects' presets. That should create a lot of room.