interesting (for me) find in a cpu consumption test ens

MvKeinen · 2023-04-13T13:50:42+00:00

There was an error rendering this rich post.

wanted to get some feedback about a test ens. My personal preference with building in core is to use as few "code" as possible. It enhances the readability a lot for me. But of course routing and latching helps a lot with reducing the number of computations. The question when to use routing can't be answered easily, that much I know. But a recent find confirmed my gut feeling in the following cases: (test ens attached below)

there are 100 voices, output is always zero because the array is empty. CPU consumers are the counter who has a router inside to reset to zero at max, the addition before the index, the read and the multiply. Everything happens at any audio clock.

CPU: 28% (i7 2700k from 2011)

Now lets say we dont always need the multiplication, only 200 times out of 1000.

CPU: 21.6%

That's great! I added the 2nd router to show the following:

CPU: 21.4%

not better! The code looks as if there are less computations but there is no gain.

So here is what I believe: The computations done at the index and the compare module are only performed when there is an event present at the following read or router module. Could this be the case or is there a flaw?

Any flaws in my test ens? Any ideas to show these things in a better way? You own findings?

Thanks in advance

cputest1.ens

Find more posts tagged with

Reaktor Building

Comments

colB

https://community.native-instruments.com/discussion/12229/interesting-for-me-find-in-a-cpu-consumption-test-ens

That seem highly likely. It's an optimising compiler. It wouldn't make sense to calculate an index when there won't be an associated read event.

Any flaws in my test ens? Any ideas to show these things in a better way? You own findings?

In general, I don't think it is useful to to performance tests in such an unrealistic context.

CPUs do a lot of work to try and predict what's coming next, they have long instruction pipelines. If your test code is always predictable, then at times branches (routers) are literally free. On the other hand, if the code is not predictable - maybe using noise as an input, then maybe half the time a branch will be free, and the other half it will be extremely expensive, because the whole instruction pipeline will be wrong and need to be refilled.

(I'm likely seriously oversimplifying this... I imagine there will be multiple pipelines and various other mitigations on modern CPUs that I know nothing about)

In real world situations, you also have to balance speed of code with code size - too big, and you will start flushing the cache which is even more expensive...

The only way to know for sure is to do testing in a real world situation, or write test frameworks that properly simulate a real world situation for that code.

Here's something from the old forum:

https://web.archive.org/web/20220826035037/https://www.native-instruments.com/forum/threads/rounding-decimals.190461/page-3#post-1168416

MvKeinen

thanks @colB the funny thing is that I'm that guy from the DRF herw is referring to all those years ago in your link. to that specific issue I have a solution now which works for me. The question was how to describe a value range between two float values with integers. Now I just use the digits from $min and $max and add another value describing the place of the decimal point.

$min: 0

$max: 100

decimal point: 2

would be 0.00 to 1.00 in steps of 0.01

$min: - 960

$max: 60

decimal point = 1

would be - 96.0 to + 6.0 in steps of 0.1

the structure is something like this ($ui is the value set by the user and stored in the snap value array. positive only integer).

inside the structure its still easy to have the 0...1 range because $min and $max are available. But for the interface and the numerical readout its great to have those different ranges.

I was forced to find a standard because in my project all those calculations happen at only one place using a subroutine like structure. So a dataset has to be provided for different value ranges and (later) mouse settings. This dataset should be integer only. Seems awfully complicated but I needed this one fits all standard. And those calculations only happen at user input. Smoothing happens further down the stream.

To the issue in the OP:

the test ens might be unrealistic, but it helped me answer the question if unneeded calculations should always be avoided. Answer seems to be: not necessarily.

MvKeinen

the 0...1 range is part of the code as can be seen here:

Quick links

Unanswered questions