Apple M1 Pro Beats M3 Pro with Ableton, Logic and Pro Tools
gearnews.com
gearnews.com
Apple seems to have realized that people with only CPU heavy workloads won't buy the Max variant, so it seems to me they've weakened the Pro line on the M3 to push more people toward the Max.
At best, none of these conclusions would apply to the 16" MacBook Pro, and would be the wrong comparisons to make for the 14".
Might keep my M1 until the M4 or M5 Pro.
Why do people keep saying the M1 Pro is 3 years old? It came out in October 2021 - it's barely over 2...
"(Ableton) Live supports up to 64 cores for audio processing on Mac and Windows. Likewise, Live supports up to 64 processing threads for audio calculation." https://help.ableton.com/hc/en-us/articles/209067649-Multi-c...
I think that's only true when comparing M3 Pro vs M1 Pro (rather than the base M chips that each have 4 efficiency cores), and only when running threads with a background-priority QoS setting. Testing like [1] has shown that macOS runs background threads on M1 Pro/Max efficiency cores at higher clock speeds to compensate for only having two of those efficiency cores compared to 4-6 for all the other chips. But when normal-priority threads spill onto efficiency cores because the performance cores are full, the efficiency cores run at full speed on all chips.
[1] https://eclecticlight.co/2023/11/27/evaluating-m3-pro-cpu-co...
I didn't get an answer to the main question I had (sounds like they don't have one yet): is this because the DAW software has been optimized for M1 but not M3, and once they update it these scores will change?
For example he mentions FL Studio can handle 70 tracks of Nolly. The latest FL Studio version's tutorial project has 98 tracks and can run on an HDD if your CPU is fast enough. The effects being used are lighter than the Nolly guitar amp effect. But they're still more cpu heavy than I/O heavy.
The SSD matters for picking the sounds, in my experience. So you're going through listening to a bunch of drum hits, for example. If the drive is slow, this stalls.
Plus, isn't he simultaneously playing 70+ tracks with a CPU-intensive filter on each one? That's not a realistic workload.
I linked this in another comment, but here's a real video of a Skrillex single and it has 180 tracks loaded with plugins.
He mostly uses virtual synthesizers, but you'll notice the track is mostly composed of audio clips and not MIDI running a real synthesizer. Because he does the synthesis in a different project and renders the audio out. Because it would be impossible for a project like this to run in realtime with the synthesizers being calculated.
Yes, there is something to be learned by his results but it has a the very least 50% to do with DAW internals and CPU vs the CPUs themselves.
He used large numbers of tracks to test which isn't a valid measure of CPU optimization across different DAW platforms. There is widely varying CPU overhead issues among the different DAWs. Running 300 tracks in Ableton is going to cause a bunch of different bottlenecks and inefficiencies to be pushed... not just CPU.
Clickbait. I'm not saying that the M3Pro is better or worse or trying to defend Apple, I'm just pointing out as someone with a lot of experience in DAW-land that this testing methology is bunk as a CPU test and as a DAW performance test.
Showing that the efficiency cores aren't fully utilized by the DAWs is appropriate for the audience. It shows to less specialized users that they'll need to examine their tools and their use of efficiency cores to determine if an upgrade is worthwhile
Most of the time, that is probably the wrong approach for an app to take, but maybe DAWs have latency requirements that can't be met when E cores are in the mix. But that's something the DAW vendors should have to document and justify, because it's just as likely that they're making assumptions about E cores that don't hold up over time across the full range of chips.
The graphs in the source video[0] display 0% utilization on E-cores for some apps.
Given that it only occurs for some DAWs, it's very likely the wrong approach (given that 2/3 of the apps using E-cores have better performance characteristics than the others)
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.
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.