Declicking

[ColinP]

Once the processors started doing on-the-fly optimizations, sometime around the x686, as I recall, any calculations you could do for clock cycles and latency went out the window, because you had no idea of what the CPU was going to do to your finely-crafted assembly code.

Very true. Long gone are the days when you could calculate execution time by hand. Even profiling is of little use unless you have a wide range of CPUs to run tests on.

And things are going to get ever more disconnected as CPUs deploy more pipelines and start running with deeper speculative execution rather than "mere" branch prediction.

It obviously used to be the case that an addition was always cheaper than a multiplication or that 32 bits was cheaper than 64 but steadily everything is moving to a uniform do arithmetic as fast as is theoretically possible state of affairs. So I now code on the assumption that every operation has the same cost except for memory access. Hence what I said about look-up tables. Older CPU will still take longer to do a double precision floating point op than a single precision op but I think it's not really worth worrying about this because in just a few years time things will have moved on.

Something I've been thinking about recently is how the Java Virtual Machine might increasingly be able to automatically adapt to varying CPUs. Hotspot is over a million lines of C++ so I wouldn't want to hazard a guess at how rapidly it will improve but in principle a JIT compiler ought to be able to optimize to whatever the host CPU is. This gives Java (and JVM languages like Kotlin etc) a potentially huge advanatage over native languages like C++ as native language optimization is frozen in time at the point the compiler runs on the developer's machine so can't adapt to improvements in user's machines.

[ColinP]

On that cubic function I looked up my code to check and I use...

y = x * x * ( 3 - x - x )

By the way I write polynomials in ordered fashion. So -2x^3 + 3x^2 rather than 3x^2 - 2x^3 even though I think mathematicians prefer the minimal form.

The reason is that I visualize all single variable polynomials as tuples. So this particular one is (-2,3,0,0).

[UrbanCyborg]

Speaking as a soi disant mathematician, in other circumstances, say in dealing with systems of polynomials, or something like polynomial rings, I'd likely order them the same as you. I just chose the way that made for the simplest arrangement of plus and minus operators in the code. As you noted, your's is just as likely to be the fastest version as mine. I did do a romp through a bunch of other sigmoids, but the bulk of them involve either transcendentals functions or messy divisions. I strongly suspect that anything that's likely to be handled in microcode in the silicon (transcendentals are usually microcode Taylor series out to a limited number of terms) is still an expensive operation, so I quickly ruled most of them out, and just went with the one you suggested. The linear ramp I started with worked, too, but not quite as well. I finally settled on a ramp time of 16 ms; anything less and I could still hear noticeable thumps. It also helped with debugging, because I could easily see what result I was getting on a scope at that length.

Reid

[poetix]

Thanks, nicking that (it's got to be way faster than Math.cos...)

[poetix]

If I hook up a simple knob to an input as a volume controller -

Code: Select all

double inputValue = input.GetValue();
double knobValue = knob.GetValue(); // range 0.0 - 1.0
output.SetValue(inputValue * knobValue);

I get clicking as I turn the knob. If I hook up a square-wave LFO to it, it sounds dreadful.

I've used a simple smoothing function to reduce clicks:

Code: Select all

double inputValue = input.GetValue();
double targetDrive = knob.GetValue(); // range 0.0 - 1.0
currentDrive = (currentDrive * 0.99) + (targetDrive * 0.01);
output.SetValue(inputValue * currentDrive);

If the new value is a long way away from the current value, it still sets off fairly fast. It sort of Zeno's-paradox's its way towards the target value, the difference eventually getting lost in a rounding error. The results sound decent to me, but are there good cheaply-computable alternatives which smooth both the takeoff and the landing and get us from current to target value (assuming the latter is stationary) in a finite number of samples?

[UrbanCyborg]

You can generally avoid glitches due to knob movement by running all your knobs through an insulating layer of SmoothValue objects. That's really the way you want to code for VM, anyway. That way, any changes you make to the knob are fed through the SmoothValue object for that knob, and whenever anything needs the knob value, it reads from the SmoothValue object, rather than directly from the knob. The docs, such as they are, for the SmoothValue object are in one of the drop-down menus in VMD.

Reid