They’re the same workload in that they are both IO bound vs CPU bound.
-E
So why is it that we don’t see any noticeable performance impact when working in a DAW?
It’s not the same workload. Please post a link to prove your claim?
I’m the source of the claim. The final capacity of both systems is limited by IO. We don’t see any performance impact in our DAWs because we’re not at the IO limit. Database servers only exhibit pre/post patch performance differences when driven at their peak IO. A database server that barely performs any IO will show no difference.
-E
Well, there you go. You said it yourself. DAW usage are not affected because no one gets no where near the IO limits.
Database usage will have a much higher IO usage from potentially thousands of users surfing a large forum at the same time needing to access the database and in addition create network IO workload as well (Just an example)
A DAW will need to access mostly well below 150 files at the same time if it’s a very large project and have no network IO.
Thus working in a DAW will see NO NOTICEABLE PERFORMANCE IMPACT, which is also confirmed by various users here in these forums.
In the first message of mine that you replied to, I clearly said that DAW users would not notice an impact. Database impact, as well, is entirely dependent on utilization. A barely-utilized database system will see no impact. I guess my use of “workload” was confusing. I was referring to the final limiting utilization factor for both is disk IO, not CPU. That’s a fairly unusual workload.
-E
You just need to keep in mind that severs are not only about disk IO but also network IO and will thus create a lot more IO than DAW usage. Not saying they will hit the limit but you cannot compare servers to DAW usage because it is far from the same workload.
With that said, all the big players like Google, Microsoft, Amazon and so on all claims they didn’t see any noticeable performance impact as well.
Of which the TL;DR is CPU-driven processes are nearly unaffected, but DAW users who are near their disk IO limits may see issues. Sounds vaguely familiar…
-E
Anything that’s near any limit will of course have a problem, but those benchmarks are based on hundreds of Kontakt voices … how many real-life projects would have, say, 1000 simultaneous Kontakt voices? They indicate approx. 3%-7% of a hit in those extreme cases and for the none at all for many use cases. In the database world, people are seeing anything up to 40% of a hit, which is disasterous, simply no comparision, and the reason is that the disk I/O is of a completely different character (random access read/write with simultaneous high network loads) compared to a DAW (sequential read access with comparatively little or no network activity).
The problem isn’t Kontakt voices, it’s disk IO. In the article you cited, the problem with Kontakt instruments is with voices that use “disk streaming”. In this whole discussions, I’ve been asked repeatedly why “we” aren’t seeing any DAW problems. Well, it’s because the “we” who are here in the forums have track counts that top out at 150 (number coming from previous poster disagreeing with me). When you’re doing film scoring, however, you’re using thousands of tracks (as reported by multiple posters in the main Cubase forum). If you’ve got thousands of tracks, you’ve got serious disk IO going on.
Random versus sequential IO depends entirely on where the block is located on disk. Do a punch? No longer sequential. I mean, do you really record all the tracks at once? No aspect of the recording process is nonlinear?
Network throughput is way faster than disk throughput. Disk IO has forever been the slowest aspect of computing until the SSD era, which is recent.
In the database world, no one has seen a real-world “40%” hit. The 30% number that has been bandied about was a very early test of “select 1” under PostgreSQL on Linux, which creates a worse-than-worst-case load.
DAW and dedicated database servers are ultimately disk IO limited, and in either scenario, if you’re at the upper range of utilization you’ll feel the impact of the Intel mitigation. AKA the long-winded version of my original post.
-E
The word “voice” is probably used because that’s what the user cares about, not disk I/o (even if it would happen to be the actual culprit).
Now as for whether or not the problem really is I/o I think the question is how we know this. You assume it’s disk I/o presumably simply because it seems reasonable. However, if disk I/o was the bottleneck for how many voices a given system can play back the wouldn’t that bottleneck remain when switching CPUs? If you look at their other charts, like this one, we see large variation on the very same platform(s) with different CPUs. I mean, it’s not subtle. On the x299 platform we see a 50+% increase in voices, and same on the x399.
(and it’s curious that both the Threadrippers and the i9 CPUs show the same performance increase AND the same core count increase))
Why would a given disk subsystem limit one CPU to 3500 and another to 5460? Wouldn’t it be more reasonable to guess that it’s the CPUs capacity that’s the bottleneck?
But isn’t that inadvertently pointing out the problem being the CPU though? Because to me “upper range of utilization” requires an “upper range” system, i.e. not an i5 CPU but maybe a 7920 or higher.
In other words: If the m.2 drive is capable of a whopping 5460 voices on the x299 platform, wouldn’t it have waaaaay more headroom than needed on an i5? The i5 only providing about a fifth of that amount of voices tells me it isn’t about the drive i/o it’s about the CPU. If the drive is good enough for five times the i/o on an unpatched x299 system why would we see a difference due to bug fixes on the i5? Surely the tiny drop in performance would be far less than the headroom…???
Sorry to say but you fail to really understand the issue here. You keep assuming it’s about specific disk IO when it’s not, it’s about CPU IO which can be calls to both disk and network and others as well. DAW and server load are far from the same workload as several users in this thread has already told you, which some of them actually work with this stuff daily.
I don’t know why you keep going about this when the bottom line is that DAW users are not really affected, well yes they could be by a few percents but that’s not something you will notice. Also notice that test from the link above shows biggest impact on low ASIO buffer settings and the higher the buffer the less the impact. Why would this change with buffer settings if this is all about specific disk IO? Well that’s because it is not.
Also most users will only run those low buffer settings while tracking and then switch to a more safe lets say 2048 buffer while mixing and producing.
You are running 1000 tracks, well I doubt it but even if you do they are not all playing at the same time and they are not all audio.
You can’t know this. Not all knowledge is publicly available on the internet.
The reason I keep coming back to it is due to statements like your first sentence. I have a thorough understanding of the issue. The performance impact is caused when an application has to perform a OS syscall. Prior to the patch, the OS always presented the same page table during syscalls. Now it has to swap back and forth between two page tables.
I work with this stuff daily. I’m sure you’re familiar with at least one of the companies I work with - Office Depot, Lilly pharmaceuticals, Toyota, Nine West, TJX, Aldi, and a half dozen others that I’m forgetting. Heck, if you’ve ever used PHP under Oracle to retrieve a “long” column type, you’ve actually used code that I’ve written.
Again, go back to my first message. I clearly said that DAW users would not be affected. Why did you even argue with me then?
-E
Can’t you just explain how swapping out one CPU for another on the same platform increases the amount of voices when you say it’s bound by disk I/O?
The reference to “voices” came from the article that MrSoundman linked to. It’s that article that links Kontakt’s voice count to disk IO, not me. It wasn’t in all cases, either, you’d have to read the article. It’s very good.
-E
I know where it came from, and I did read the article.
You seem to make a difference between CPU work and “disk IO”. Clearly streaming samples off of a drive involves using the CPU to some extent. This is why we can see that the same drive on the same system can yield different amounts of voices… when we swap out the CPU.
If you agree with that then this difference we see in your writing isn’t there and we’re all saying the same thing.
I don’t really have anything else productive to offer this thread. At this point I’d just be repeating myself.
-E
I’m just asking for a clear answer. You could point to the specific sentences you wrote earlier if that’s explanation enough. But it’s set of pretty simple questions I’ve asked.
I keep arguing because in every other post you are saying that DAW users will be affected and the others you say they don’t. You also keep saying that DAW workload is the same as servers which is just false information because it is not. You also keep talking about disk IO while it is CPU IO that matters for this.