3 ms·
testing how a DAW handles 300 identical low-CPU consumptive tracks is not at all appropriate for a music CPU workload assessment. No one except Charlie Clauser
by n9 3y ago
testing how a DAW handles 300 identical low-CPU consumptive tracks is not at all appropriate for a music CPU workload assessment. No one except Charlie Clauser or Hollywood cinema post production uses projects with 300+ tracks -- it is a really idiosyncratic test that exposes the optimization liabilities of the DAW vs the CPU.
A Better test would be to set up an intensive real world 20 track project, assess utilization and overhead, and then find a real-world way to increment that stress upward to the breaking point.
Most computer music forum wonks use some kind of test based on softsynths or reverbs or a combination and stack them high on a smaller number of tracks.
I mean... 300 tracks? You're basically testing the DAW's thread management at that point, not the CPU as it would be used.
- deleted 3y ago[deleted]
- squeaky-clean 3y ago300 tracks is more realistic than 20, at least for electronic music. Here is a Skrillex single with 180 tracks. https://youtu.be/2dYFJdQf7rs?si=rsBc8gCtz5DQYGI9 https://youtu.be/2dYFJdQf7rs?si=rsBc8gCtz5DQYGI9
- wtallis 3y ago> I mean... 300 tracks? You're basically testing the DAW's thread management at that point, not the CPU as it would be used. Any realistic test is going to have more tracks than there are CPU cores, so thread management would seem to be an unavoidable aspect of the test. The test results were in the 60–100 track range, not 300, so not really as excessive as you are claiming. And while testing with too many tracks could certainly be problematic for introducing excessive context switching overhead, the problematic behavior that was actually revealed is much more serious and less subtle and applies to any scenario with more than 5–8 threads.