Watch for param value changes

Development
22

From VCV Rack API, it seems to be int64_t instead of uint64_t, unfortunately.

Perhaps Andrew will fix this in future Rack API release (signed value for DSP counter is useless, except if I’m wrong for unknown reason, obvisouly).

23 
    if (0 == ((args.frame + this->id) % CONTROL_INTERVAL)) {
        ...
    }

Module ids are guaranteed to be unique…

But - for better source code readability, I prefer:

    if (((args.frame + this->id) % CONTROL_INTERVAL) == 0) {

Despite the result is identical! :wink:

In my KlokSpid MkII module source code (published plugin v2.4.1), this instruction is placed before non-urgent tasks (and after urgent/realtime such control voltages), such lights, graphic parameters for GUI draws, touchscreen, encoder moves, button presses…

//////////////// FROM THIS POINT, DSP IS CONSIDERED EVERY 32 FRAMES ////////////////

if (((args.frame + this->id) % 32) != 0)
	return; // Exiting DSP frame process.
24

Of course most of this doesn’t matter much. A typical VCV plugin does a TON of stuff on every single clock cycle to process control voltages. Most plugins are many orders of magnitude away from being as efficient as they could be. Remember that we are talking about a couple of instructions, vs. the thousands that many plugins run every process call.

1 Like
25

Remember that we are talking about a couple of instructions, vs. the thousands that many plugins run every process call.

I totally agree, Squinky!

My initial reply above, was, in fact, a way to save the usage of two int variables, to do the same thing!

I cannot test on “slow” computer (my PC is a 4.5GHz Core i9 lol).

1 Like
26

if you cast it the compiler does the right thing. check the assembly in the godbolt link i shared.

1 Like
27

yeah i was more curious whether my habit of & 63 vs % 64 was a real difference of whether it was now useless optimizations due to apocryphal stories of bad compilers of yore, as so many 90s and 2000s eras c++ optimization habits are. Only way is to look at the assembly. And now I know! Sorry to take the thread waaaaay off topic.

2 Likes
28

Sorry to be that guy but wouldn’t

if (i == something) ... else i++

always be faster than &63 or %64 ?

29

First as squinky said, this probably doesn’t matter for most cases in rack.

And it would be different unless you reset i.

So the question is

if (i == 64)
{
  i = 0;
}
else
{
  ++i;
}

vs

if (!i) { };
i = (i+1) & 63;

you can see what gcc produces on those two forms. (I had to add the x++ inside to stop the entire if from being optimized away)

Comparing that assembly

  1. The second form has one less instruction. And
  2. The first form has two paths out of the function

My experience is ‘if’ and ‘branch prediction’ in tight loops on intel is not that great if you can avoid it.

So my guess is

  1. Neither of these are materially different if you put them in a rack process loop which is already a virtual function etc… but
  2. The second form would perform better on our cpus marginally and
  3. Unless you are actually running an actual profiler and looking at actual code, it’s all a bit academic and silly :slight_smile:
30

Oh!

void bestAndFor(uint64_t &p, int &x)
{
    if ((p = (p+1)&63) == 0)
    {
        x ++;
    }
}

seems even better.