Richard sent me a question last week asking me to compare the speed of complex projects in Apple Motion when running on Apple Silicon vs. Intel.
Easy, I thought. Except these results were NOT what I expected!
EXECUTIVE SUMMARY
I created two 4K projects containing 3D shapes, 4K media, cameras, lights and filters. I exported each project twice and timed the duration of each export.
In every test, the 2017 27″ iMac was significantly faster than a 2021 16″ MacBook Pro!
Wow!
THE SYSTEMS
These are the specs for the 2017 iMac: Intel-based, latest version of macOS.
These are the specs for the 2021 16″ MacBook Pro: Apple Silicon, latest version of macOS. This uses the M1 Pro CPU. Based on data provided by Activity Monitor, I would not expect much difference if this computer used the M1 Max CPU instead.
MOTION PROJECTS
Both projects were set to UHD (4K) 60 fps with 20 second duration. I exported and timed each project twice, just in case there was a significant speed difference due to cacheing.
There wasn’t.
The first project took a 3D object, applied rotation in 3D space, added custom lights and colors, plus a moving camera shooting with depth of field enabled.
Though this project was designed to run at 60 fps neither system achieved that speed:
No external media was used for this project, just library elements.
In this test, the Intel iMac was 48% faster than the M1 MacBook Pro! (Though both exported the project slightly faster the second time through.)
The second project was more complex:
Though this project was designed to run at 60 fps neither system achieved that speed:
Yup, the older Intel-based iMac was about 4 times faster during playback than the newer M1 MacBook Pro!!
NOTE: I purposefully did not render either project, as I wanted to see what the native playback speed would be.
That speed differential also applied to exports – the Intel iMac was faster by 176%!
NOTE: I discovered, as I was writing this article, that the first time I ran these performance tests, the MacBook Pro was running on battery. So I ran them again with the laptop plugged in and discovered that Motion was about 20% faster on the MacBook Pro when running on battery!
CPUS ARE NOT WORKING VERY HARD
When I looked at Activity Monitor for the MacBook Pro, it quickly became apparent that the CPUs and GPUs were not running anywhere close to maximum speed. In fact, most of the project was running on the slower performance Efficiency CPUs. None of the high-performance cores were working very hard and the last two were not used at all.
As well, the GPUs were not maxed out. This is why I would expect these speeds to be essentially the same whether running on an M1 Pro or M1 Max.
SUMMARY
Though all these results are surprising, I was really struck by the extremely slow playback speed of the M1 MacBook Pro for the complex Motion project.
I don’t have an explanation for this speed difference, but I do have a thought. While the raw performance numbers of the new Silicon Macs are stunning, applications need to be optimized to take full advantage of this speed potential.
Apple has spent time optimizing at least some of Final Cut Pro. But they have not yet had time to optimize Motion. Yes, Motion runs on the new chips, but nowhere near as fast as it did when running on Intel.
Clearly, it is impossible to design a single test, or even a test suite, that fully measures performance in an application as flexible and complex as Motion. But these tests offer a caution that simply supporting Apple Silicon is not a guarantee of blazing speed.
For those interested, you can download (5KB) my first Motion project – which doesn’t require any external media – and run some tests yourself. As always, I’m interested in your comments.
36 Responses to Apple Motion Speed Test – Intel vs. Apple Silicon
Newer Comments →-
Bengt Olofsson says:
January 3, 2022 at 4:14 am
-
Larry says:
January 3, 2022 at 7:13 am
-
Dave Brennan says:
January 3, 2022 at 5:37 am
-
Larry says:
January 3, 2022 at 7:13 am
-
Philip Snyder says:
January 3, 2022 at 7:09 am
-
Larry says:
January 3, 2022 at 7:11 am
-
Fra says:
January 3, 2022 at 7:41 am
-
Larry says:
January 3, 2022 at 7:55 am
-
Connie Simmons says:
January 3, 2022 at 8:27 am
-
Larry says:
January 3, 2022 at 8:28 am
-
Paul van Wel says:
January 3, 2022 at 8:43 am
-
Wallis Alviar says:
January 3, 2022 at 5:46 pm
-
Larry says:
January 3, 2022 at 6:07 pm
-
Manuel says:
January 4, 2022 at 5:31 am
-
Larry says:
January 4, 2022 at 12:12 pm
-
Alex ‘4D’ Gollner says:
January 6, 2022 at 7:52 am
-
Larry says:
January 6, 2022 at 8:06 am
-
Robin S. Kurz says:
January 13, 2022 at 6:59 am
-
Larry says:
January 13, 2022 at 7:21 am
-
Robin S. Kurz says:
January 13, 2022 at 7:49 am
-
Robin S. Kurz says:
January 13, 2022 at 6:42 am
-
Larry says:
January 13, 2022 at 6:52 am
-
R says:
January 13, 2022 at 7:24 am
-
Larry says:
January 13, 2022 at 7:36 am
-
Kurt Friis Hansen says:
November 9, 2022 at 6:48 am
-
Larry says:
November 9, 2022 at 6:58 am
-
Kurt Friis Hansen says:
November 9, 2022 at 9:11 am
-
Kurt Friis Hansen says:
November 10, 2022 at 1:47 am
Newer Comments →Hello Larry,
I downloaded your Motion-project and did a test on my Imac. It took 20 sec to render.
I have an Imac 21,5 inch 2019, 3 GHz 6-core Intel Core i5 with 16 GB DDR4 memory. Destination disc was an 1 TB SSD-drive.
thank you for an interesting newsletter.
a Good 2022 to you
Bengt
Sweden
Bengt:
Thanks for running the test and posting the results. And a very happy and successful New Year to you, as well.
Larry
Larry,
I tried the first export on a 2018 iMac Pro, 10 core, 64GB RAM, Radeon Pro VEGA 64X
12 seconds
I then tried it on a new 16″ MacBook pro 64G RAM, MAX processor – 34 seconds
Broadly seems in line with your experience. Perhaps there’s life in the old iMac yet
Dave:
Thanks for posting this. It is good to see this speed differential exists on other systems so that it is a broader problem than just my gear.
Clearly, there is value in hanging on to older computers – but I never would have thought the speed difference would be this big.
Larry
Larry,
I ran the test on my 27″ 2019 iMac with 3.1 GHz 6-Core Intel Core i5 & 32 GB RAM
Radeon Pro 575X 4GB : 18 seconds.
Philip
Philip:
Clearly, Apple has some significant optimization to do on Motion. A programmer friend told me last night that Intel chips have a render engine in their CPU that Motion may be using to speed things up.
It will be interesting to see what Apple does.
Larry
Hi Larry,
Really interesting article.
I have a 16″ MacBook pro 64G RAM, MAX processor, and I did the same test 4 different times and it took an average of 31 seconds.
But the difference from your test is that the playback inside motion was perfect.
Fra.
Fra:
Good to know. The fastest I could get my MacBook Pro to run the first project was 59 fps. The other project, which the MacBook ran at 9 FPS included 4K media which I don’t have rights to distribute. Based on what I’m reading in the comments, Apple has some work to do on Motion.
Larry
HI, Larry – I have a Mac mini M1 2020, 16GB Memory running Big Sur, and the average export time was 22-25 seconds.
Happy New Year to everyone!
Connie:
Thanks for sharing your results. Happy New Year to you as well!
Larry
I did the test on a Mac Mini M1, 16 GB Ram. Running Monterey 12.1
Playback, even without rendering was excellent.
After that rendering only took a few seconds.
The duration of the export was 35 seconds.
First test:
MacBook Pro 15″ 2018
Processor: 2.9 GHz 6-core Intel Core i9
Memory: 32 GB 2400 MHz DDR4
Graphics: Radeon Pro 560x 4 GB Intel UHD Graphics 630 1536 MB
Playback: Excellent
Export: 20 seconds
Second Test:
MacBook Pro 14″ 2021
Chip: Apple M1Max
Memory 64 GB
Playback: Excellent
Export: 34 seconds
Wallis:
Thanks.
Larry
Hi Larry, happy new year!
I downloaded and tested the export on my “vintage” 2015 iMac 27″ 4 GHz Intel Core i7 quad-core, 24 GB 1867 MHz DDR3, AMD Radeon R9 M395 2 GB, 500GB internal SSD, running Big Sur. Well, it took approx 60 sec. to render.
Playback in Motion: a couple of transient low points @ 30 fps otherwise 59…
Greetings from Switzerland.
mg
MG:
Thanks for posting your results.
Larry
On my 16GB 2016 MacBook Pro with a 4GB Radeon Pro…
…the first test took 29 seconds to render.
Alex:
Good to hear from you again! Thanks for posting your results.
Larry
BTW, for the sake of clarity and consistency, it would be helpful to know exactly AS WHAT you exported everything, Larry. 442? 4444? H.264? HEVC? Surely not the last two, but I suspect those are actually the ones where the M1s would blow away the Intels.
Still waiting on my Max (it’s been *two months* now!) so I can’t test myself just yet. ?
Robin:
Motion does all its work internally in an uncompressed 10-bit form. So, I exported the default setting of Apple ProRes 4444 with an alpha channel, similar to what I would do if I were creating projects for Final Cut or Premiere. And the M1 uses hardware acceleration for ProRes, H.264 AND HEVC, so I wouldn’t expect significant differences there.
Larry
There is most definitely a difference between exporting to 422 as opposed to 4444, not only because you’re writing a minimum of twice the amount of data to disk, depending on the image. Even more of a difference with 264 and 5. But sure, it won’t be a *massive* difference.
And Motion uses mostly 8-bit-per-channel (so 24bit) images in its pipeline. But there are some places where more precision is needed in which case it uses 16- and 32-bit-per-channel floating-point formats, which differs from GPU to GPU. But then that’s not ultimately relevant in this case anyway.
That’s weird. Mine only took 22 secs and I know we both have the same machine. ?
Robin:
The fact there are speed differences doesn’t surprise me. We probably have vastly different background processes running on our systems, which would also make a difference. The key is the difference in speed between the two processors.
Larry
Actually, I happen to know that Alex and I have identical machines.
I get very strange differences in times btw. It has ranged from up to *over 1 min.* in 4444 to under 21 secs in 422. Other times around 30 in 422. And I restart Motion every time. Very odd. Will have to report.
Robin:
Thanks for the update. I’m interested in learning what you discover.
Larry
I decided to try a quick and dirty test on a recent Motion project, and ended up with these values:
Project sestup: 25fps 4k ProRes 4444 (with Alpha) Video+Sound PCM
Quick and dirty test on material containing lots of movement, lighting etc.
Motion export: 3m48s (228s) 592 MB / 630 Mb/s (7s13f)
Through compressor: 10s 625 MB / 655 Mb/s (7s16f)
Machine: MacBook Pro M1 Pro 16G/1TB 10CPU/16GPU
MacOS: 12.6.1
Motion: 5.6.3
Compressor: 4.6.3
I was both shocked and extremely pleased, that I had the tools to deliver a usable solution to the conundrum. Wasn’t prepared for this kind of difference in rendering results. This may not be representative for other projects, but I think it is indicative.
No visible difference.
I assume, that Motion chugs along on CPU’s, while Compressor relegates the work to the GPU’s. I wasn’t prepared for this huge speed difference (but will now move a couple of setups through Compressor in the future).
Maybe it’s worth a try, if you have Compressor lying around in your system.
Regards
Kurt Friis Hansen
Kurt:
This is VERY interesting! For those that don’t know, explain how you moved a Motion project into Compressor without first compressing it.
Larry
Used this way manually:
1. Click Share
2. In Export Movie Settings
1. Required settings
2. In Actions select Open With Compressor
3. Sélect Next
4. Select target directory
5. Click Save (not really affected) I assume the motn file gets saved here. You may be asked to replace existing file
6. Compressor opens the batch screen
7. Add Setting Apple ProRes 4444 with Alpha Further options can be added the usual way
8. Execute and answer any questions.
9. Look in the Completed tab In this case file is placed in the default target (recommended) Status: Successful Elapsed Time: 0:00:10
10. Select looking glass, to display file positions
As it looks to me (in default mode), the motn file is moved to the workspace, where also the target file is delivered. If you select delivery to another folder, the looking glass option does not work.
I’ll report any automatons, that I manage to create. Right now I can live with a completely manual approach, that is badly integrated. It works. 10 seconds with a bit of fiddling is easily accepted instead of 228 seconds in this specific case.
Now, I have work to do. Fooling around – and by accident discovering the manual approach – does not my edits produce in the main FCPX project, 50 times the size of this little snippet.
I stated earlier, that Compresssor used the built-in GPU’s. That was an assumption done without thought. Maybe the built in ProRES support in the M1 Pro chip bears the main responsibility for the speed gains. I haven’t had the time to check right now, and who cares, if things turns out surprisingly well in real life.
Would love to get feed back, of any modifications in approach, or pointers to effective automation setup.
There is an Apple article on this subject (I just skimmed it), that I cannot find right this moment. When found, I’ll report back.
Regards
Sorry, error on my part.
The approach described turned up to rely on an oddity in the Motion delivery mechanism.
The effect experienced is caused by a previous Motion render to let’s say “4444Alpa.mov”.
If the same Motion share includes the Action “Open with Compressor” is immediately repeated, no actual render takes place, only the Compressor part is turning up. And that part is manually kicked into action performing a bit of overhead and in effect “transcoding” 4444Alpa.mov into a version in the same format in 10 or less seconds (not really that useful, just extra work).
There is transcoding involved in both (“all”) cases. In the “quick repeat” case, Motion does not create the initial “source” mov-file (it seems), since a valid version exists already, which leads to the wrong conclusion. Whether that is actually a bug or an intended optimization is – of course – unknown. I tend to view it as bug.
That’s how it looks today, after a good nights sleep, and that’s how it behaves in my setup in further, detailed and targeted tests today.
The Add Destination inside Motion for Compressor Settings does the “Full Monty”, and no time is saved, unless the Compressor setup performs additional processing.
Today it took 03m58s to render the project via Action Compressor (which only has real value, if more than target 4444+Alpha is involved in one go). With “Save Only” immediately after the 4444+Alpha is delivered in 03m40s for the identical project (slightly modified since yesterday).
Sorry for the hoopla 😉
Motion IS – as far as I can see – still extremely slow in creating ProRes 4444 files with Alpha.
I will still hunt for a possible solution though.