The multicore option should have logic in it to bypass / ignore the setting if the current system tests as a single-core system. The only tricky case would be Pentium 4 processors that have Hyper-Threading.

At any rate, on my single-core system:

CPU load with multicore disabled on a "generic"-style preset @ 1024 @ 100 quality with declipper ~= 20
Same @ 2048 ~= 10

CPU load with multicore enabled using same preset @ 1024 ~= 20
Same @ 2048 ~=10

Tests at 512 were ~= 38.

As you can see, everything is identical, with or without multicore, which is how it should be on a single-core, non-HTT system. Your processor has Hyper-Threading, so even if you only use a single physical core, the OS can address it as two logical cores.

Don't know why you have differing results, but here's some speculation:

The values I'm giving you are obtained by observing Task Manager or Process Explorer. I'm not sure how reliable your "time to process" testing methodology is. If it relies on data being written to disk, then you're adding in another component, and you'd have interfering metrics such as rotational speed, cache, access times, fragmentation, buffered (cached) writes vs. unbuffered, etc...

But... Then I would expect the CPU load to drop a lot if you lower the latency. At a latency of 512, the memory usage would - for most things, agreed, not for everything - be 1/8th of the memory usage at 4096! (The memory is still allocated because in a real-time program you don't want to dynamically allocate and free memory, but most of it just won't be used - hence also not be cached).

Now it could be that it does drop - to test that disable 'multicore' as I've seen earlier today that it has less effect at lower latency settings. Also, please disable the Advanced Clipper since it behaves differently at different latency settings - most other filters don't.

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.

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.

All i am saying is his goal can not be hindered by CPU's who can not keep up with the mathematics.

The multicore option should have logic in it to bypass / ignore the setting if the current system tests as a single-core system. The only tricky case would be Pentium 4 processors that have Hyper-Threading.

At any rate, on my single-core system:

CPU load with multicore disabled on a "generic"-style preset @ 1024 @ 100 quality with declipper ~= 20
Same @ 2048 ~= 10

CPU load with multicore enabled using same preset @ 1024 ~= 20
Same @ 2048 ~=10

Tests at 512 were ~= 38.

Edit: Without declipper, load at 512 is "0", and at 1024 it is also "0". 2048 pushes it up to 8.

As you can see, everything is identical, with or without multicore, which is how it should be on a single-core, non-HTT system. Your processor has Hyper-Threading, so even if you only use a single physical core, the OS can address it as two logical cores.

Don't know why you have differing results, but here's some speculation:

The values I'm giving you are obtained by observing Task Manager or Process Explorer. I'm not sure how reliable your "time to process" testing methodology is. If it relies on data being written to disk, then you're adding in another component, and you'd have interfering metrics such as rotational speed, cache, access times, fragmentation, buffered (cached) writes vs. unbuffered, etc...

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.

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 ?

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?)

Just added a stand alone build to the post above. It's slightly different from the other 2 (registering issue should be fixed and the Limit slider responds 100 times faster to mouse wheel/drag/keyboard input).