Stereo Tool

Probably best to state some hardware requirements ?
Seems allmost impossible to suit the needs of all users, so if some kind of HW REQ is stated, all is clear.

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

As for this, yes, the latency being lowered does reduce the demand, and thus the CPU load. However, my system behaves differently than yours. At 512, even with a whole lot of stuff enabled, I can get loads from 0-10%, not including declipper and the new multiband.

That's why I keep "preaching" at you about having appropriate test platforms. If you can't afford or find an older platform, then I really see only three options:

1) Rely on what people with the older platforms are telling you and see if you can find other users with similar platforms to corroborate. The idea I presented you about using the CPUID feature flag information can give you an idea about what platforms are out there and how many of each.

2) Allow someone on an older platform to assist with profiling. I've made this offer, and it is genuine. There is no underlying desire to hijack your code.

3) Drop support for older platforms.

The problem with this is if you approach it strictly from this perspective, this means you can write hideously sloppy and bad performing code and then use a faster hardware requirement to cover up your sins.

I don't mean to be harsh, but I can't help but find it interesting that in this predominantly European-inhabited forum there exists this underlying idea that people should just buy new hardware rather than look at efficiency on existing hardware. This is interesting because of me being American, and my country routinely getting criticized for its' "bad" carbon footprint by those in Europe.

Don't get me wrong, but hans has a goal, and for this goal i can imagine some serioes mathematics and CPU flops are still to come.
All i am saying is his goal can not be hindered by CPU's who can not keep up with the mathematics.

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

It is entirely possible to write code so badly performing that it could heavily strain even newer processors.

For example, it is known that there are times when loops are executed more times than is truly required to get the required value for the next processing step. These extra times don't make the values any "better", so the extra iterations are technically a wasteful use of resources. Those resources, if freed up, could be used to instead perform useful tasks.

Like I said, faster hardware allows inefficient code to be covered up. Demanding that people shell out additional money that they may not have so that the inefficient code is covered up instead of removing the wastefulness in the existing code is not good stewardship.

If we were talking about the speed of a motor vehicle being insufficient, and I, as an American, made the suggestion for you to install a bigger engine with more horsepower, I'm fairly sure you'd have a problem with that suggestion. That's the part that I find ironic. The non-American / world opinion would be to improve the efficiency of the existing engine and/or lighten the weight of the vehicle because the larger engine would mean a larger carbon footprint.

Inefficient code generates a larger carbon footprint, even on current processors, because more wattage is required from the power supply.

Like I said, it's all very ironic how the perspective shifts when talking about software. I suppose it's because software is nebulous, and that people give developers the benefit of the doubt, unless the developer works for Microsoft, then it's all bloatware.

Ah, sorry, I thought your system had 2 cores - if it has 1 the multicore option will automatically be ignored (I guess I should disable it in the GUI...)
About hyperthreading: It's actually best to turn that off completely (unless you have a single core system). Since with HT, low priority tasks can use up resources that should be used by a high priority task that's scheduled on the same core.

What are those numbers that you're posting? As I said earlier, Task Manager is *very* unreliable for measurements of real-time tasks (and the fact that you report '0' in several cases confirms that - you don't REALLY believe that the CPU load is 0, do you?)

Brian,

I agree on what you are saying, code must be as efficient as possible.
But what if the mathematics is just to much (even if code is efficent) for some processors ? Should the support of these processor come over the quality of the software ?

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

The answer is truly "it depends". What is needed to be known are the percentage breakdowns of the processors in use.

Let's say that it is determined that approximately 30% of installations happen on systems older than Core2, then that is a fairly substantial segment of users. If, however, it is only 10%, then it might be appropriate to start thinking about whether you want to support those systems or not.

In my opinion, assuming there are enough installations, my "minimum" would probably be:

Intel Pentium Dual-Core and AMD K8-based systems (Athlon64 and Athlon64 X2, and the corresponding Opteron systems). Pentium 4 and Pentium D would be dropped. K8 is substantially stronger than P4 ("Netburst"), so much so that it can be relatively close to or marginally outperform the initial Intel Core systems (the low end Core stuff).

Nope. I wish I had the money to afford replacing my 3700+ with an Opteron 175 (basically a 2-core version of the 3700+), but I'm so poor I can't afford a free lunch...
The entire Core i-series has Hyperthreading. It was reintroduced sometime along the way. The Pentium 4 "Netburst" Hyperthreading was inefficient, but I guess something with the newer architecture made it efficient. That's why I keep talking about differences between platforms. Just because your platform is OK with something doesn't mean it goes well for all processors.

Some of these differences are very deep - down at the assembly level. For example, my system doesn't support CX16 (CMPXCHG16B instruction). Yours does. I'm not sure what would happen if your hand-written assembly tried to do an unsupported function. Would it crash, or would it use something similar that was supported, like CX8 for CX16, similar to how my processor does 128-bit SSE by chopping it in half and processing 2 64-bit chunks? Does your assembly attempt to use MOVNTPS or MOVNTDQ? I believe those are supported, but how about MONITOR or MWAIT? Those are not supported by my processor.
Like I said, they're values shown by either Task Manager or Process Explorer. I put the zero in quotes because an actual zero is not plausible. As for the accuracy of using Task Manager, yes, it does have a dependency on the timer resolution. I think, however, that the inaccuracy related to that is less than the inaccuracy introduced by involving disk writes. I don't know if what you're doing involves disk writes though.

Just rebooted using this version and the registration info did stay there. Thanks!