FCP 6 & 7 use only two cores for RT and Render, Right?

[Dave Jenkins]

Below is some info from the Apple ProRes White Paper July 2009, Page 17. My take on what this say is that FCP 7 should be Multiprocessor aware using ProRes and Snow Leopard.

Today’s Mac notebook and desktop machines rely on multicore processing, and so
the speed of a fast editing decoder must scale up—meaning that decoding time per
frame should decrease—as the number of processing cores increases. Many industry
codec implementations “hit the wall” and do not realize further performance gains as
more processors are added, but Apple ProRes codecs continue to get faster as more
cores are added, as the following chart shows.
Multiprocessor Scaling – Apple ProRes 422 (HQ) at 1920 x 1080

Testing conducted by Apple in April 2009 using prerelease Mac OS X v10.6 Snow Leopard, a prerelease version
of Final Cut Pro 7.0, and shipping Mac Pro 8-core 2.26 GHz units.

Dajen Productions, Santa Barbara, CA
MacPro Two 2.8GHz Quad Core – AJA Kona LHe
FCP 6.0.4 OS X 10.5.5 QT 7.5.5

[Erik Lindahl]

The codec is multi-core “aware” and very scalable, that doesn’t mean the host-application is. I think about 5 people have quoted the ProRes spec in regards to FCP.

Erik Lindahl
Freecloud Communication
————————

[Dave Jenkins]

While we are all guessing at this point but how can they test multi-core “aware” in FCP 7 if it’s not multi-core “aware”?

Testing conducted by Apple in April 2009 using prerelease Mac OS X v10.6 Snow Leopard, a prerelease version of Final Cut Pro 7.0, and shipping Mac Pro 8-core 2.26 GHz units.

Dajen Productions, Santa Barbara, CA
MacPro Two 2.8GHz Quad Core – AJA Kona LHe
FCP 6.0.4 OS X 10.5.5 QT 7.5.5

[Erik Lindahl]

Just cause function A used multi-core function B does not. It’s been a source of performance issues for quite some time in a lot of applications. Say FCP might be able use say 8 cores when it plays back 20 streams of ProRes media. That doesn’t mean rendering a 3-way Color Correction on 1 clip will utilize the machine to the same extent.

After Effects has solved this problem with multiple instances of it’s self in the last two versions. This is similar to how Compressor solves it this way also. This is general gives a solid speed increase but not always.

Erik Lindahl
Freecloud Communication
————————

[Chris Davis]

[Dave Jenkins]

“…Testing conducted by Apple in April 2009 using prerelease Mac OS X v10.6 Snow Leopard, a prerelease version of Final Cut Pro 7.0, and shipping Mac Pro 8-core 2.26 GHz units.”

Thanks. I should have specified that I meant using Leopard, as Snow Leopard is not officially out yet.

[Mark Hollis]

Snow Leopard does offer something new, and that is a kind of cleainghouse for multi-threaded applications. In other words, if the application is multi-processor aware, the OS will step in and become a “scheduler,” so that multi-thread processes scale up much better. I would note Microsoft has nothing like this in Vista or Windows 7.

But!

Lots of what you do in Final Cut is added in. There are keyers, effects and many other tools you can use to create special effects. I recall that I was using a version of “Toon It!” (a filter that makes video look like it’s a cartoon) and it was completely multiprocessor unaware. I was on a new Intel-based 8-core Mac and some renders took overnight.

My deadline was in September and I heard that a new (MP-aware version) was due in late October).

So, for your workflow, look at your added-on keyers, effects and filters from third parties as well. Apple’s Final Cut Pro may well take full advantage of the newest, hottest Nehelem systems with Snow Leopard (a really inexpensive upgrade) but your plugins may well lag behind.

What if there were no hypothetical questions?

[Chris Davis]

[Mark Hollis]
“Snow Leopard does offer something new, and that is a kind of cleainghouse for multi-threaded applications. In other words, if the application is multi-processor aware, the OS will step in and become a “scheduler,” so that multi-thread processes scale up much better. I would note Microsoft has nothing like this in Vista or Windows 7…”

Mark,
Many thanks for the reply. I’m still following this thread. If you have time, could you please say more about this?

Would this mean that Snow Leopard could make a 32-bit app like FCP 7 as fast for RT and rendering within FCP as a 64-bit app like PPro CS4 (on Windows 64)? (Apparently PPro uses all cores for this in Windows 64. Anyway, Just another hypothetical question 😉

Also, does anyone have a link for the ProRes white papers mentioned above? Couldn’t find them, called FCP tech support, and they didn’t know about them and offered no guidance on how to find them (do the guys at tech support always get pissy when you ask them a question they don’t know?)

Thanks,
Chris

[Erik Lindahl]

A native 64-bit app doesn’t necessarily have to be better written for multiple CPU’s than a 32-bit app. It will however on the x86 architecture most likely be slightly faster but primarily it can address tons of memory. This is return is something you want for multi-core since each core can essentially “eat” more RAM for it’s jobb.

The ProRes White Paper can be found here:
https://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf

If Snow Leopard gives general applications a boost on a multi-core system that would be terrific but I think you as an app-developer will very much have to write your apps with this in mind. Snow Leopard just gives you some help on the way.

Erik Lindahl
Freecloud Communication
————————

[Chris Davis]

Erik,
Thanks for the info and the link.
-Chris

[Mark Hollis]

Apple’s information on Snow Leopard is here:

https://www.apple.com/macosx/refinements/

The “clearinghouse” function in Snow Leopard is called “Grand Central Dispatch” which is covered here: https://www.apple.com/macosx/technology/#grandcentral

Quicktime will be 64-bit and my Windows-using friends are all hoping Apple releases Quicktime X for Windows as well.

I would imagine that Apple’s Final Cut Studio will be 64-bit in the next revision (8) but 7 was tested under Snow Leopard with some interesting results.

Now, Apple is pretty specific:

“GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between.”

This means one has to program for Grand Central Dispatch and one imagines that the operating system will want to prevent applications from gobbling up cores and not working them very hard, so this adds to the permissions complexity when you are writing the code. Anything not written in XCode will suffer greatly, which means plugins that work with Final Cut and Premiere and Media Composer (which may not be written in XCode) will suffer as a result.

So this is why I’m offering a strong caveat here. Lots of people I know use lots of plugins to get their work done effeciently and effectively — from green screen work to effects and transitions. Your mileage will certainly vary, depending on how the particular plugin is written. And I would suggest that, if plugin makers are forced to rewrite everything specific to Final Cut in XCode (while writing for everything else in the tried-and-true methods used previously), the cost of plugins and the cost of their upgrades may increase substantially.

What if there were no hypothetical questions?