'Kernel memory leaking' Intel processor -- a serious cpu bug!?!

[donkey tugger]

You mean the problem you invented yourself and have absolutely no proof for?

Solution:

• Back up your system and bench-mark
• Apply the patch and bench-mark

You don't have time? Then shut up, stop worrying about nonsense that doesn't even exist and get back to work.

If you want to rely on information provided to you by others: there is a 0% measured difference in processing efficiency.

The differences don't apply to computation, they apply to task-switching for processes like virtualization or servers. Even in those cases changes have already been made to minimize the issues, which are so far outside the scope in which you use the hardware that it's like worrying about what temperature a Chinese steel mill is operating at when you're serving hotdogs at a baseball game.

Why are you so angry at inquiries on this subject?

Have you been on this, 'internet', thing before?

[aciddose]

The tone of voice I used for that post was actually a cold, hard Dr.McCoy.

[metamorphosis]

The differences apply to IO, mainly.

[aciddose]

Not just any type of "I/O", specifically to changing in and out of kernel scope.

For example a host that is reading audio tracks 1-sample at a time will be incredibly inefficient and this issue might make it take twice or more as much time.

A properly designed host however will read large chunks of audio into a shared/cyclical/multi-process buffer and only switch context very rarely. Since 99% of the time is spent doing useful work (actually moving data) and only a tiny amount of time goes to overhead, the difference will be at worst something like 1% slower.

So streaming 40 audio tracks (20 stereo?) might have used 5% of your CPU resources before: now it may require 5% + (1%*5%) or 5.05%.

Big-ass whoop.

That said, does anyone have any bench-mark projects set up and have they made reliable measurements of the difference?

In engineering we refer to such differences as practically zero/infinitesimal: in other words so small they might as well be zero because they're less than it is even possible to reliably measure. (In other words, so small they can't be measured.)

Such issues are of genuine concern for people writing hosts that stream 1000s of audio channels off multiple disks or disk arrays, networks and other IPC channels; or related systems like databases or distributed computing projects that use services like amazon's AWS and similar.

These aren't issues for users.

[Jace-BeOS]

Interesting info, thanks. If you find any benchmarks, please do share here

[Guenon]

Such issues are of genuine concern for people writing hosts that stream 1000s of audio channels off multiple disks or disk arrays, networks and other IPC channels

What's the consensus on heavy Kontakt use, as the stream count can be of that magnitude there? Will the buffering used in Kontakt mitigate this in such a way it's likely nothing to be worried about?

[aciddose]

The authors of Kontakt need to deal with this: if it was an issue to begin with.

Most likely they use efficient buffering already to reduce CPU use, so the effect is minimal if even measurable.

"The null hypothesis": until someone provides some measurements that prove there is an effect, you must assume there is none.

[aciddose]

WE'RE ALL BOILING ALIVE! THE SUN IS EXPLODING!!!

... but my thermometer says it is 10c.



WE'RE ALL BOILING ALIVE! DID YOU HEAR ME!?!?

[Guenon]

Most likely they use efficient buffering already to reduce CPU use, so the effect is minimal if even measurable.

This is what I figured, being consistent with your previous post that touched on buffering, yes. (Don't know if that picture post was a direct reaction to my Kontakt question , hah.)

[aciddose]

I bet you might find information posted by Native Instruments about their own plug-ins on their own forum, or you might have gotten an email (updated version?) about it if it was important.

Ultimately it doesn't make a lot of sense for a user to try to do anything about an issue without first having evidence that it is an issue at all. Really a user can't actually do anything

I suspect that when these patches were published last month we would have been hearing something about them. I've seen reports that you get 15% performance loss in specific render farms (new 2018 movies); in many cases it was possible for that software to be patched already to reduce the performance hit to less than 1%.

This is like replacing the muffler on your truck: you might have either gained or lost a tiny bit of peak torque and likewise (likely improved) fuel efficiency, but it's such a small difference that it really doesn't have a significant impact on anything at all.

... or you can be one of those guys who drives around an old beater with a rusted out muffler.

[Guenon]

I understand the point you have reiterated here multiple times already , I just happened to browse this thread and wanted to ask you whether you think it's likely Kontakt streaming will be affected, as you said "such issues are of genuine concern for people writing hosts that stream 1000s of audio channels off multiple disks or disk arrays", but true indeed -- Google to the rescue -- as appeared likely, it doesn't seem to be that big of a deal. Checked the Scan Pro Audio Kontakt benchmarks they did before and after OS and BIOS patches, and the decrease in voice counts is very marginal.

[aciddose]

Well, if you're dealing in 100 voices and you end with 99, that's a 1% decrease.

For posterity: http://www.scanproaudio.info/2018/01/12 ... kstations/

The testing outlined here today is based on current hardware and Windows 10. Specifically, the board is an Asus Z370 Prime A, running on a Samsung PM961 M.2. drive, with a secondary small PNY SSD attached. The CPU is an i5 8600 and the is 16GB of memory in the system.

It's important that they tested an (older: version released q4 2017, not a new design though, only incremental) i5.

In one screenshot (it's difficult to tell exactly what they tested and how: the article isn't great) they show 1220 voices reduced to 1180 after patch. This is 59/61 or 96.7% = 3.3%.

That is certainly far more significant than expected and I would wonder (if this is the case) whether they can make improvements to the plug-ins themselves to improve the situation.

It's likely very difficult though.

The important thing is to remember we're discussing such topics on a public forum that may be viewed tens of thousands of times over the next decade. So I'm not just replying to you Guenon, but actually "the whole internet". I very often see misleading comments posted everywhere about a multitude of different technical subjects. It's just frustrating to be looking for technical information and find the internet is polluted with poor quality information instead. That makes it very difficult to track down valid information.

It would be great if anyone did have reliable bench-mark results; noting of course that this is so subjective that it almost defeats the purpose when the results are within 1% anyway, which tends to be below the error bounds and makes the measurements useless. So I have sincere doubts we'll see any such measurements as I would expect things to only improve (better patches, better hardware) in the future.

[Guenon]

Well, if you're dealing in 100 voices and you end with 99, that's a 1% decrease.

For posterity: http://www.scanproaudio.info/2018/01/12 ... kstations/

The testing outlined here today is based on current hardware and Windows 10. Specifically, the board is an Asus Z370 Prime A, running on a Samsung PM961 M.2. drive, with a secondary small PNY SSD attached. The CPU is an i5 8600 and the is 16GB of memory in the system.

It's important that they tested an (older: version released q4 2017, not a new design though, only incremental) i5.

In one screenshot (it's difficult to tell exactly what they tested and how: the article isn't great) they show 1220 voices reduced to 1180 after patch. This is 59/61 or 96.7% = 3.3%.

That is certainly far more significant than expected and I would wonder (if this is the case) whether they can make improvements to the plug-ins themselves to improve the situation.

Heh, even before your edit above, I was rather certain you already googled it . I was about to say, indeed, in their benchmark it's more like 3-9%, depending on the buffer.

[Guenon]

More about the specific Kontakt testing methodology here (they inform in the article the scores are based on DAWBench VI) https://www.dawbench.com/win7-v-osx-6.htm

[aciddose]

The problem with the % voices "loss" they report of course is we may be seeing something that only affects the audio driver, not the plug-in.

So it's very hard to say. A DAW has many different components interacting together, and an audio-driver update or a different audio device might eliminate this entirely. The audio driver is very likely switching context and the % loss we're seeing might be entirely due to the buffer swap taking an extra ~1 ms.

Very difficult to measure such stuff because the technical expertise required is so huge it essentially means nobody in the whole audio software world is genuinely qualified!

Some hosts provide a "null" output device. I believe Reaper does for example. This would allow testing to eliminate the audio driver from the equation and provide more accurate results.

The choice of a particular plug-in like kontakt is also arbitrary: while it seems a "rational" choice based upon intuition, there are so many parts at play that it is hard to say whether (for example:) the copy protection might throw off the results.