FORUMS: list search recent posts

FCP X hardware performance

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Oliver Peters
FCP X hardware performance
on Jun 2, 2012 at 2:04:45 pm

There have been some posts about hardware optimization and X. Here's a little comparison I just ran.

:65 ProRes 1920x1080p/23.98 media clip. Same timeline. I applied a MB Looks "blockbuster" preset. This internally uses diffusion+vignette+4 color correction filters. This was left unrendered and then exported, so rendering occurred on export. Exported (Share - Media Export) as current setting.

1. 2009 MacPro 8-core (2.26GHz), 16GB RAM, ATI 5870 (1GB VRAM) GPU, 2 internal RAID-0 media drives.
8 min. export

2. 2011 MacPro 12-core (2.93GHz), 12GB RAM, ATI 5870 (1GB VRAM) GPU, Fibre Channel SAN media drives.
6 min. export

3. 2012 iMac 4-core i7 (3.4GHz), 16GB RAM, HD 6970M (2GB VRAM) GPU, internal SSD, Thunderbolt Promise media drives.
4 min. export

Also unrendered playback was reasonably close to real-time (or at worst it looked like around about 15fps) on the iMac, yet rather "stuttery" on the two MacPros.

Clearly it looks like: a) X is optimized for the i7 processor, b) actual processor speed is more important than the number of cores, c) the more VRAM the better.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

olof ekbergh
Re: FCP X hardware performance
on Jun 2, 2012 at 2:18:45 pm

This is very similar to my findings.

FCPX seems to really depend on new hardware to work well. I was really disappointed with how FCPX ran on my 2009 8core, this station runs FCP7 and M100 very well. But really stutters playback and has frequent beach balls from Hell when running FCPX.

Using the new iMac i7 maxed out with a TB RAID, it works very well using Matrox MX02. It helped make me start to use FCPX instead of just "testing" it.

Olof Ekbergh


Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 2:41:44 pm

[olof ekbergh] "FCPX seems to really depend on new hardware to work well. I was really disappointed with how FCPX ran on my 2009 8core,"

Fortunately, I really haven't hit many "beach balling" issues on the Mac Pros. Maybe just lucky. The main thing I see is that once you move away from the built-in and Motion-template-based effects, performance is really challenged on the Mac Pros. In general, I find unrendered performance to be tolerable with the built-ins, Tonalizer, the DH filters and most of the FxF filters. Playback isn't always smooth, but you can work with it and not lose the creative flow.

I think it also depends on the complexity of the filter itself. For example, a filter that does one simple task (like the color board or a single vignette) is pretty light on the gear. A filter like MB Looks, DFT Film Stocks or even DV Shade Easy Looks is really applying the equivalent of 5-10 filters all as part of one plug-in. Therefore the "pipes" get clogged.

Hence the importance of a fast machine (regardless of number of cores) and VRAM. Note the card in the tested iMac has double the VRAM of the ATI 5870.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Jeremy Garchow
Re: FCP X hardware performance
on Jun 2, 2012 at 3:10:58 pm

Nice one, Oliver.

It is certainly apparent that whatever NLE is next, we are going to need some new hardware.

I guess the plan is working? ;)


Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 3:54:27 pm

[Jeremy Garchow] "It is certainly apparent that whatever NLE is next, we are going to need some new hardware.

I guess the plan is working? ;)"


Although some would disagree with me (us?) FCPX is designed to sell hardware. It eats resources . . . probably another reason why I believe Apple will replace the MacPro with powerful computer.



Return to posts index

Bill Davis
Re: FCP X hardware performance
on Jun 3, 2012 at 1:01:39 am

I'm dangerously out of my technical chops depth in this, but a few weeks ago, I had a closing sequence in X that started with a white base clip - then had five text elements and three TIFF logos composited into a simple closing slate.

I had applied standard dissolves to the beginning and ends of all the elements wishing to simply dissolve up and down the entire static slate as a single element.

When I set it to render and went to get a drink, I got caught in a conversation and when I got back 30 minutes later, the title stack had progressed a whopping 2 percent!

If I'd been sitting trying to work live - I probably would have thought X had hung up - when in fact it was just taking forever to do it's calculations.

I moved my cursor to the middle of the title, Exported the composite to a flat file, swapped it out in the timeline and got the exact same screen representation rendered out in under 7 seconds!

In trying to understand why, the only thing I can think of is that by stacking all those layers of titles, each needing to calculate a lot of pixel values - I sent the metadata calculation engine in X into a tizzy. I imagined the program calculating the pixel values of the first two layers, then adding another layer, and re-calculating the composite of the original mixed with that - followed by another layer and compositing THAT against the previous result... kinda ad nauseum.

Bottom line is that I'm now trying to keep this kind of "stacked composite" to a minimum when I can.

Again, I could be TOTALLY misunderstanding what's going on under the X hood - but I do think there might be some issues when it comes to expressing everything as discrete metadata states and trying to keep not only the processing, but multiple levels of "undo" in the X metadata system.

Maybe somebody here knows more about how X generates it's composites and why I saw such ridiculously long renders in something that once appeared so simple in Legacy. I know the quality of the resulting graphics appears to me to be much better than I was accustomed to seeing out of Legacy - but this still seems weird to me.

Just thought I'd mention it in case someone else runs into the same kind of massive slowdown.

FWIW.

"Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions."-Justice O'Connor


Return to posts index


Oliver Peters
Re: FCP X hardware performance
on Jun 3, 2012 at 1:49:03 am

[Bill Davis] "In trying to understand why, the only thing I can think of is that by stacking all those layers of titles, each needing to calculate a lot of pixel values - I sent the metadata calculation engine in X into a tizzy. I imagined the program calculating the pixel values of the first two layers, then adding another layer, and re-calculating the composite of the original mixed with that - followed by another layer and compositing THAT against the previous result... kinda ad nauseum."

I don't think this has anything to do with metadata. Text elements in FCP X are Motion projects. Even when nothing moves, the composite is just as complex from one frame to the next as if there were a lot of movement, so rendering takes a long time. If you have several layers of text elements overlapping each other, it's the same as stacking several Motion projects on top of each other. The app gets very sluggish at this point and renders are excruciating. It sounds like you simply had to render 1 frame and then bring that back in as an element, so no more Motion complexity after that initial 1 frame hit. That's why your solution was such an incredible time saver.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Bill Davis
Re: FCP X hardware performance
on Jun 3, 2012 at 2:02:22 am

Makes sense, Oliver.

I keep forgetting that the entire titling suite in X is just a subset of the Motion code - so it makes perfect sense.

Thanks for the clarification.

"Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions."-Justice O'Connor


Return to posts index

Michael Hadley
Re: FCP X hardware performance
on Jun 4, 2012 at 1:20:05 pm

I've got journeyman chops but one thing I have learned is to avoid TIFFs (and jpegs where possible). I always convert to PNG files. Smaller and preserves transparency. I know that was very helpful in FCP7. And it has been my experience in X so far as well.

Actual mileage may vary, but I would avoid TIFFs if possible.


Return to posts index


Chris Harlan
Re: FCP X hardware performance
on Jun 4, 2012 at 3:42:35 pm

[Michael Hadley] "I've got journeyman chops but one thing I have learned is to avoid TIFFs (and jpegs where possible)."

JPEGS, yes, but I use TIFFs all the time. Its a venerable format that allows for layers and transparencies. I'm not sure what your problem has been with it, but I've been using it for years without issue.


Return to posts index

Elias Huch
Re: FCP X hardware performance
on Jun 28, 2012 at 2:20:18 pm

In my experience with X over the last year I've found that the trick is to use Motion for this type of compositing. It appears that X is not really happy, as was stated above, with having to render multiple frames with several stacked layers (Tiff or not). However, when using a motion Generator my rendering is easy and quick like the simple Generators in X. I have always been an AE guy for graphics, but I've found that the "sort of" round tripping with X and Motion is actually pretty seamless. There are some challenges like publishing parameters in the right order, but if you publish the image to be changeable in motion and then duplicate it several times, you can do all of the compositing back in X with no trouble. It's all a bit cumbersome, but the ability to not have to fully re-render is worth the trouble.

Elias Huch
Motion Graphics Designer
Reelvizion Productions


Return to posts index

Timothy Palmer-Benson
Re: FCP X hardware performance
on Jun 4, 2012 at 12:51:44 pm

This exactly what I have found. Playback on a MacPro 3.33GHz, 6 Core 2010 Macpro and 24 GB shows the CPU idling at almost 80% when playing back a three camera angle Pro Rez 1920 x 1080 multi cam clip. Playback constantly drops frames and is even worse when an LHI AJA Kona card is brought into the mix. I remember this became much worse when FCPX 1.03 and 1.04 were released. By contrast a 2.93 GHz 7iCore IMac with only an 800 Firewire and 12 GB of RAM plays back the same clips without any problems


Return to posts index


Mathieu Ghekiere
Re: FCP X hardware performance
on Jun 2, 2012 at 3:30:47 pm

I'm surprised the MB looks filter still needs approximately 4 times real-time export even on your fastest machine. I haven't run the numbers, but I'm wondering if Red Giant can optimize their Magic Bullet Suite more to speed up the render times.
I have the suite in its newest version, bought it for compatibility for FCP X, but I was a *bit* disappointed with the exporting speed. Maybe I was expecting too much, with all the talk of the 64-bit FCP X support.

I do love the quality of the Magic Bullet filters though. I find they give very nice results quickly (sometimes with a bit of fiddling, and their newer UI in comparison with their first ones, is much better and user-friendly for changing presets) and although it can dramatically change the colors in your video, I find it still keeps a lot of detail in the image.


Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 3:58:15 pm

[Mathieu Ghekiere] "I'm wondering if Red Giant can optimize their Magic Bullet Suite more to speed up the render times."

Saphire Edge also needs a lot. If you really want to push things try using the Neat Video noise reduction filter. This on my 2008 Dual Quad MacPro. Things seems much more zippy on my 2011 15" MBP. The desire for a MacPro replacement is palpable. FCPX, once you start heavy lifting with some filter, really demands it.



Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 4:19:21 pm

[Mathieu Ghekiere] "I'm surprised the MB looks filter still needs approximately 4 times real-time export even on your fastest machine. I haven't run the numbers, but I'm wondering if Red Giant can optimize their Magic Bullet Suite more to speed up the render times."

Playback performance IS better with PProCS6, but I haven't yet done a direct export or render comparison. Maybe tonight. In the past when I did direct render comparisons on the MP between the various NLEs, X was always the slowest.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 4:25:05 pm

Dates of the models?
2011 MacPro? 2012 iMac? I assume you mean 2010 MacPro and 2011 iMac. This based on when released.



Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 5:35:46 pm

[Craig Seeman] "Dates of the models?"

These aren't my machines, so I was going by when they were purchased from Apple by the owners.

Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 6:05:14 pm

[Oliver Peters] "These aren't my machines, so I was going by when they were purchased from Apple by the owners."

Although it's easy to determine the actual model year from the specs. Based on date of purchase it might be confusing to call a MacPro purchased currently as "2012"



Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 6:11:48 pm

[Oliver Peters] "Clearly it looks like: a) X is optimized for the i7 processor, b) actual processor speed is more important than the number of cores, c) the more VRAM the better."

I'm not so sure about processor "speed" so much as the capability of the processor at the time they were designed.

How would a 2010 (not 2011) quad i7 BTO iMac compare to a 2010 MacPro 12 core. If it's truly i7 optimization, you'd still see the iMac and MacPro of the same year, leading. Or, to be more accurate, compare i7 and Xeon of the same number of cores and same Ghz with 1GB VRAM to see the role the CPU is playing.



Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 8:04:29 pm

[Craig Seeman] "I'm not so sure about processor "speed" so much as the capability of the processor at the time they were designed."

While in general I would agree, I do have to say that Apple has never taken good advantage of multiple cores (as in hyper-threading, multi-threading, etc.) for most of the apps, especially editing. In most benchmarks, a faster speed quad will outperform a slower 8-core of the same vintage processor. At least in the Mac Pros, which is the only place in an Apple product where this comparison exists.

Basically, Apple argued for years with the PowerPC (G5) that pure processor speed didn't matter. In fact, most objective tests proved this to be flat out marketing BS. Speed does matter and it's true with Xeons as it was with PowerPC chips.

If performance is more important than elegance, you WON'T go with an Apple computing product. Want to get the most out of 3D apps or After Effects? Run it on an HP under Win 7 64. But, for editing, Apple makes machines that are powerful enough for most of our needs.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 8:16:35 pm

FWIW - I was just able to run a test with the same clip and filter in PProCS6 on the 12-core Mac Pro. Export/render using the AME function. Took approx. 2:30, which is under half the time that the equivalent function took in FCP X using the exact same machine.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

David Cherniack
Re: FCP X hardware performance
on Jun 2, 2012 at 8:26:09 pm

[Oliver Peters] "I was just able to run a test with the same clip and filter in PProCS6 on the 12-core Mac Pro. Export/render using the AME function. Took approx. 2:30, which is under half the time that the equivalent function took in FCP X using the exact same machine."

Champagne for the house! Put it on Dennis' tab.

David
AllinOneFilms.com


Return to posts index

Lance Bachelder
Re: FCP X hardware performance
on Jun 4, 2012 at 2:16:19 am

Did you have Premiere set to use highest bit depth (32 bit)? I've found renders out of X to be super clean - colors come out exactly like you create them and Blu-rays look better than anything I've rendered out of any NLE. I don't mind waiting a little longer if the quality is as good as it gets.

Lance Bachelder
Writer, Editor, Director
Irvine, California



Return to posts index

Walter Soyka
Re: FCP X hardware performance
on Jun 4, 2012 at 11:16:59 pm

[Lance Bachelder] "Did you have Premiere set to use highest bit depth (32 bit)? I've found renders out of X to be super clean - colors come out exactly like you create them and Blu-rays look better than anything I've rendered out of any NLE. I don't mind waiting a little longer if the quality is as good as it gets."

Floating-point (32-bit) processing is great. It has three big advantages for visuals:
  • Large dynamic range (the difference between black and white)
  • Values above and below clipping (values brighter than white and darker than black, very useful when chaining effects)
  • Very high precision (leading to reduced quantization or rounding errors, also useful when chaining effects)

With fixed point or integer math, the gap between any two adjacent values that the computer can represent is constant. With floating point, the gap between any two adjacent values is proportional to the number itself -- about ten million times smaller than the number. In other words, large values are spaced further apart, but small values are spaced closer together, giving you incredible precision (read: more detail) in manipulations in the lower/darker end of the range.

For many straight editorial cases, though, FP processing can be speed-sapping overkill. You start with 8-bit (and occasionally 10-bit) acquisition, and you deliver 8-bit video. For straight cuts and dissolves, floating point processing offers literally zero benefit for all the additional time and resources it requires. Once you start compositing, chaining effects, or doing colorspace conversions, though, you start seeing improved accuracy.

As for colors looking like they were intended -- that's how it's supposed to work! Previous versions of FCP (and QuickTime) had disastrous gamma and color management, not to mention somewhat byzantine split YUV (sic)/RGB processing pathways with questionable transforms. FCPX, its ColorSync support, AV Foundation, and fulltime RGB processing is a huge step forward here. (For the sake of completeness, I'll add that FP processing is a big benefit for accurate RGB/YCrCb transformations and superblack/overbright preservation)

I'd further note that accurate and predictable color are certainly doable with other NLEs as well, but I don't say this to take anything away from FCPX.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Lance Bachelder
Re: FCP X hardware performance
on Jun 6, 2012 at 12:13:12 am

Yes the 32 bit thing was just for Premiere since there is a checkbox to use highest bit depth. FCPX is using much more than just 32 bit float as you mentioned and the results are the best I've sen from an NLE. When I cut in Vegas I leave it in 8 bit mode for speed then switch to 32 bit float for color timing and final render - even if it's an 8 bit render such as DVD the results are better with the switch though the render times skyrocket.

Lance Bachelder
Writer, Editor, Director
Irvine, California



Return to posts index

David Cherniack
Re: FCP X hardware performance
on Jun 7, 2012 at 9:47:21 am

[Lance Bachelder] "FCPX is using much more than just 32 bit float as you mentioned"

He didn't mention. So where are you getting the idea that FCPX is using much more than 32 bit float? And if you can show some stills of rendered material that clearly demonstrates that FCPX output is better than any other NLE it would help. Otherwise we might think it's just Lance again, off on one of his enthusiastic, but somewhat delusional, benders :)

David
AllinOneFilms.com


Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 2, 2012 at 8:35:48 pm

[Oliver Peters] "While in general I would agree, I do have to say that Apple has never taken good advantage of multiple cores "

Agreed.
I am wondering how an i7 and Xeon of the same vintage compares though.
If each have same cores and speed, Xeon should still be faster in some functions. I'd love for someone(s) to do such testing.

My concern about tests of different models from different years are that it may well be that, for example, a 2011 Quad i7 iMac is faster in some functions than a 2008 Quad or maybe even Octo Xeon MacPro.

If Apple updates both the iMac and replaces the MacPro this year, I'm sure we'll see such tests.

Tangentially, on another forum someone was comparing FCP7 and FCPX export on a MBP 13" and, without going into all the details, FCP7 was faster. My own speculation is that FCP7 doesn't really care about the GPU whereas the more resource hungry FCPX isn't given much with the integrated GPU of the MBP 13". A claim that FCP7 is faster would have to be qualified to the system. Heck I bet FCP7 is much better on a Core2Duo than FCPX. Given how little RAM is used FCP7 might even appear faster on system with only 4GB RAM. FCPX would starve on such a system.

Basically my point is, when doing speed tests there's several things that need to be considered. I would be carefully saying FCPX is "optimized" for i7 unless it's compared to a like Xeon, not older ones.

For example, would expect an 8 Core 3GHz Xeon 2006 MacPro to be faster than a 4 Core 2.8GHz i7 2011 iMac since 2006 MacPro has higher GHz and more cores?

I might guess that the 2011 iMac would be faster (at least with regards to many FCPX functions) because of the improvements in the new i7 processors compared to 5 year old Xeons. I don't know this for a fact but that's why I bring up vintage as an important consideration when testing.



Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 9:39:24 pm

[Craig Seeman] "I am wondering how an i7 and Xeon of the same vintage compares though."

Well, if you look back at the tests I ran, The 12-core MP and the iMac are fairly close in vintage.

[Craig Seeman] "without going into all the details, FCP7 was faster"

I've done similar tests and seen similar results.

[Craig Seeman] "For example, would expect an 8 Core 3GHz Xeon 2006 MacPro to be faster than a 4 Core 2.8GHz i7 2011 iMac since 2006 MacPro has higher GHz and more cores? "

I think speed and cores per processor matter. In other words I have a sneaking feeling that you aren't getter double the bang just because you have two chips instead of one.

[Craig Seeman] "I might guess that the 2011 iMac would be faster (at least with regards to many FCPX functions) because of the improvements in the new i7 processors compared to 5 year old Xeons."

I would agree. I think in the case of FCP X specifically, the GPU is a huge factor.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Bret Williams
Re: FCP X hardware performance
on Jun 2, 2012 at 11:27:14 pm

I believe playback AND rendering is being handed off th the GPU as in CS6. The real reason the iMac is winning. Put something better in your 12 core than a 6970 and it should win.

FCP 7 only utilized 4gigs of RAM and 1 processor. Didnt utilize GPU. The best machine would be 6 core 3.66 Mac pro for it. Motion, shake and compressor however utilize all cores and Motion also utilizes the GPU I think.

Many tests show X also to render slower than 7, but they're usually comparing it to an 8 bit render. I think the renderer and RT in X is of a higher caliber and 10bit. Or something to do with core foundation...


Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 11:50:31 pm

[Bret Williams] "Put something better in your 12 core than a 6970 and it should win"

I'm afraid you confused the two cards. This 6970M IS the card in the iMac. It's a 2GB VRAM card. The 12-core has a 5870 card (1GB VRAM). This is the top-of-the-line Apple-approved card. You would have to get a higher-end NVIDIA and throw out the card bought from Apple.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 2, 2012 at 11:52:40 pm

[Bret Williams] "but they're usually comparing it to an 8 bit render. I think the renderer and RT in X is of a higher caliber and 10bit. Or something to do with core foundation..."

Actually, no. That's based on codec and effect. MB Looks rendering ProResHQ in and out is 10-bit. No difference between 7 and X in that regard.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 3, 2012 at 12:44:32 am

[Bret Williams] "FCP 7 only utilized 4gigs of RAM and 1 processor. Didnt utilize GPU. The best machine would be 6 core 3.66 Mac pro for it. Motion, shake and compressor however utilize all cores and Motion also utilizes the GPU I think. "


I don't know where that myth comes from that FCP only uses on CPU. Totally untrue.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Bernard Newnham
Re: FCP X hardware performance
on Jun 3, 2012 at 9:29:33 am

"i7 and Xeon" comparison.

It seems, after a short ride on Google, that lots of people have done exactly this. Perhaps this -

http://www.cpubenchmark.net/high_end_cpus.html

- might be considered as fair as possible. The answer as ever seems to be you get what you pay for. Whether the extra speed vs the cost is worth it depends on the usage. Also, of course, in many applications, like PPro, the graphics card is important - and whether it's worth spending on a Quadro card over a GTXxxx is another discussion.

B


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 5:13:08 pm

[Oliver Peters] "Basically, Apple argued for years with the PowerPC (G5) that pure processor speed didn't matter. In fact, most objective tests proved this to be flat out marketing BS. Speed does matter and it's true with Xeons as it was with PowerPC chips.

If performance is more important than elegance, you WON'T go with an Apple computing product. Want to get the most out of 3D apps or After Effects? Run it on an HP under Win 7 64. But, for editing, Apple makes machines that are powerful enough for most of our needs."


And this has been the crux of the issue for years, and truly became apparent when Apple moved to intel and more direct comparisons could be made not too long ago.

Apple has always favored "system stability" over raw power. Windows seems to have caught up, I don't know, the windows machine here controls our SAN and that's all it has to do, but it was true not too long ago from my anecdotal connections with MacOS and Windows.

Windows machines using the same application where usually much faster, but crashed much more often.

So then the argument became that Macs had better "uptime" and the notion of speed then became about overall job speed instead of direct CPU speed. This is probably not true anymore.


Return to posts index

Walter Soyka
Re: FCP X hardware performance
on Jun 4, 2012 at 6:11:42 pm

[Jeremy Garchow] "Apple has always favored "system stability" over raw power."

I disagree with this statement for three reasons.

First, stability and power are not opposing sides of a tradeoff. Not only is it possible to engineer for both, it's almost always necessary -- what high-performance system can sacrifice stability?

Second, Apple does offer raw power. Apple has twice gotten earlier access to faster Xeon CPUs than was available to the competition (the 3.0 GHz quad-core Xeon Clovertown that powered that 2007 Mac Pro, and the Nehalem Xeon 35xx and 55xx series that powered the 2009 Mac Pro). Apple has also offered top-tier Xeon processors with each new generation of Mac Pro. Every Mac Pro has been very competitive, both in terms of absolute CPU power and cost, at the time of its launch.

Third, Apple has done some really interesting work in advanced computing, especially related to clustering (XGrid and QMaster) and symmetric multiprocessing (early multiprocessor PowerPC systems and today's Grand Central Dispatch).

I could certainly agree that Apple does not prioritize performance, as they consistently fall behind the competition on mid-architecture updates, as well as continuing to tolerate their often-noted GPU and PCIe deficiencies, but they do have a long history of (pardon the pun) power computing.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 6:39:48 pm

[Walter Soyka] "First, stability and power are not opposing sides of a tradeoff. Not only is it possible to engineer for both, it's almost always necessary -- what high-performance system can sacrifice stability?"

So why had it never happened?

[Walter Soyka] "Second, Apple does offer raw power. Apple has twice gotten earlier access to faster Xeon CPUs than was available to the competition (the 3.0 GHz quad-core Xeon Clovertown that powered that 2007 Mac Pro, and the Nehalem Xeon 35xx and 55xx series that powered the 2009 Mac Pro). Apple has also offered top-tier Xeon processors with each new generation of Mac Pro. Every Mac Pro has been very competitive, both in terms of absolute CPU power and cost, at the time of its launch."

But the OS isn't optimized for it, Walter. We have had this discussion sooo much. Instead of singling me out for it, reread what Oliver said, and have a look here: http://forums.creativecow.net/readpost/335/35669

Apple is not in the CPU race, my guess is from their standpoint, they don't have to be and take a different philosophy about what "speed" means.

[Walter Soyka] "Third, Apple has done some really interesting work in advanced computing, especially related to clustering (XGrid and QMaster) and symmetric multiprocessing (early multiprocessor PowerPC systems and today's Grand Central Dispatch)."

But does it really go faster? Sure, for some things I'm sure it does, but do you have tests on this sort of thing? What editor setup XGrid? QMaster is very hard to mange when using multiple machines. It does work well on single machines (virtual cluster), but it is for one application, Compressor. It used to be for Shake. FCP Legend doesn't use it, and X only uses it when using Compressor. How does it help me when I'm Ae or any other application that is relying mostly on CPU cycles?

Macs have always been slower even if they have the same parts. I'm sorry, it's true.

[Walter Soyka] "I could certainly agree that Apple does not prioritize performance, as they consistently fall behind the competition on mid-architecture updates, as well as continuing to tolerate their often-noted GPU and PCIe deficiencies, but they do have a long history of (pardon the pun) power computing."

You mean "power computing". Sure, they use the same parts, but the actual speed tests always tell the tale.


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 4, 2012 at 7:00:19 pm

[Jeremy Garchow] "But does it really go faster? Sure, for some things I'm sure it does, but do you have tests on this sort of thing? What editor setup XGrid? QMaster is very hard to mange when using multiple machines. It does work well on single machines (virtual cluster), but it is for one application, Compressor. It used to be for Shake. FCP Legend doesn't use it, and X only uses it when using Compressor. How does it help me when I'm Ae or any other application that is relying mostly on CPU cycles?"

Errr... you can use Qmaster to distribute render jobs for AE. Also for Nuke rendering. And it speeds things up significantly.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 7:36:23 pm

[Frank Gothmann] "Errr... you can use Qmaster to distribute render jobs for AE. Also for Nuke rendering. And it speeds things up significantly."

You mean through the multiple Ae instance thing? If you only have one computer, what's the point? Is it going to help? Are you saying that Macs are faster at distributed rendering than similarly specced Windows machines?

Distributed rendering is one thing, it is a way to split up a job to as many machines as you have. It would really depend on what kinds of renders you are doing. If they are short, less complicated renders, it can take just as long to copy all the necessary files to the clusters as it does to simply render the video.

It's all relative, and it still has nothing to do with how fast OSX runs over windows on the same hardware.

Jeremy


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 4, 2012 at 8:25:03 pm

[Jeremy Garchow] "You mean through the multiple Ae instance thing? If you only have one computer, what's the point? Is it going to help? Are you saying that Macs are faster at distributed rendering than similarly specced Windows machines?"

I was talking about using Qmaster for distributed rendering on a render farm, and that works not only for Compressor and Shake but also for AE, Nuke and others. If you only have one computer, no, it doesn't make sense. Only exception is Compressor which I'd never use in unclustered mode because it's slow.
And, of course, Macs aren't faster at distributed rendering at all. Not quite sure what your saying.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 8:58:29 pm

[Frank Gothmann] " Not quite sure what your saying."

That Macs aren't the fastest machines when all hardware is equal.

Windows is faster.

I am not talking about distributed rendering.

Oliver's original post: http://forums.creativecow.net/readpost/335/35887


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 4, 2012 at 9:24:06 pm

[Jeremy Garchow] "That Macs aren't the fastest machines when all hardware is equal.

Windows is faster.
"


Then we are on the same page, I totally agree that Windows (and Linux) is faster. However, I don't think thats because Apple favours stability over speed.
On the other hand, especially in our field, a lot of speed issues are not related to the OS but to codecs and video frameworks. Quicktime is notoriously slow on Windows, much slower than on the Mac. Some AVI codecs on the other hand totally blast QT and Prores even when compared with render times on a fast Mac (and with a lot less system load). So you may see an run into bottlenecks on both platforms.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 9:38:55 pm

[Frank Gothmann] "I don't think thats because Apple favours stability over speed. "

OK. So what is it? Just because?

[Frank Gothmann] "So you may see an run into bottlenecks on both platforms."

As I have mentioned on threads like this in the past, there are no hard and fast rules. It's true. Codecs are a big one, AVI vs QT is a great example.

I do think that a long time ago when windows was BSOD land, that Macs were more stable and Apple advertised this capability, they don't refresh computer lines right away when the fastest/newest processor comes out. They have not been in the CPU race, ever.

They have never been as fast as windows machines, all things being as equal as possible, for pure CPU revs.


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 4, 2012 at 10:13:47 pm

[Jeremy Garchow] "OK. So what is it? Just because?"

It's a number of things. Certain choices of architecture (Graphics rendering, memory management, the Darwin kernel is also known to be a slow dog, networking is slow an painful), on top of that animations left and right (which, I agree, probably is more the perceived feeling of slow) but most importantly it's the "innovation" instead of evolution. Few things in Apple land have time to grow and mature. By the time they have come out of puberty they are flushed down the toilet and things restart from 0. We've gone from OS9 to X, from PPC to Intel, apps get eoled internally shortly after having reached a point from where they could become truly great.
This is actually my biggest grief with Apple. Lots of stuff their stuff has tremendous potential but they loose interest after a while and things get left behind.
Windows, on the other hand, has matured with compatiblity in mind and it shows with certain under-the-hood technologies that are just damn solid (although some "surface" stuff could use more logic, I agree). The amount of times a software update from Apple has broken important things is insane compared with the Win side of things.

[Jeremy Garchow] "I do think that a long time ago when windows was BSOD land, that Macs were more stable and Apple advertised this capability, they don't refresh computer lines right away when the fastest/newest processor comes out. They have not been in the CPU race, ever.

They have never been as fast as windows machines, all things being as equal as possible, for pure CPU revs."


Yeah, but a lot was also marketing hype. I remember the OS9 days only too well. Not too stable to say the least. And the odd kernel panic on X is also just a few kernel extensions away.
I think you overestimate the crash potential of new hardware. Look at Linux. Runs rock solid on bleeding edge hardware, out-of-the-box kernel support for tons of raid cards, network cards, fibre etc. and no billion dollar giant making it all happen.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 4, 2012 at 10:56:24 pm

OK.

Then we can agree that Apple does not favor speed.

Although, system reinstalls/sharing, and diving in to Terminal are all part of it.

It is much easier on Mac to fix these things (boot a MacPro from a mini just for example).

I guess this is what I mean, in part, by stability.

FCPX is not a prime example of stable either, that's why I said that this is probably not true anymore.

This is an architecture choice, not a side effect.

I, too, remember os9. It was much more hard, but all computing was back then. What has happened with almost all computing is that things have gotten much more complex, yet "easier" to use for consumers.

Marketing hype, is part of it, certainly. They sure market hyped speed, but Windows sure seems to win speed tests consistently.

What do you I mean when you said I "overestimate crash potential on new hardware"?

I know what you mean about Linux, but what NLE are you using with which capture card?

And yes, Apple does move fast. Microsoft doesn't move that fast. Apple has now committed to an OS rev every year, it takes msoft three years.

I'm not saying either of these are right or wrong, better or worse, they have different needs as companies.

It will be interesting to see what happens with Montain Lion.

The upgrade to Lion has been a very easy one for me, but I know that I'm speaking for myself there.

Jeremy


Return to posts index

Steve Connor
Re: FCP X hardware performance
on Jun 4, 2012 at 11:05:47 pm

Sorry, but are we talking about render times or export times, because FCPX is blazing fast on exports for me even with MB Looks filters applied. I've found it quicker than PPro 6 in that respect.

Steve Connor
"The ripple command is just a workaround for not having a magnetic timelinel"
Adrenalin Television


Return to posts index

Frank Gothmann
Re: FCP X hardware performance
on Jun 4, 2012 at 11:16:52 pm

[Jeremy Garchow] "What do you I mean when you said I "overestimate crash potential on new hardware"?"

What I meant was that Apple isn't slow to implement new hardware because it migh impose stability issues. hence my remark about Linux.
They're slow to implement it because of internal politics (eg. esata, usb3).

[Jeremy Garchow] "I know what you mean about Linux, but what NLE are you using with which capture card?"

I am not running any NLE under Linux. I have a Linux partition in one of our HPs for film restoration software, using it with DPX only. Stuff comes in via BM Decklink card or, beyond 1080, from hard drives.

------
"You also agree that you will not use these products for... the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons."
iTunes End User Licence Agreement


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 5, 2012 at 12:52:13 am

[Frank Gothmann] "What I meant was that Apple isn't slow to implement new hardware because it migh impose stability issues. hence my remark about Linux."

Got ya. I didn't mean to imply that at all. I do not think that Apple waits for that reason.

They wait because they can and aren't in a CPU speed race on every new proc that comes out.

And since there's no Linux NLE that works with AJA cards, that pretty much rules it out.

DPX is not necessary for my workflows, but that's just me.


Return to posts index

Walter Soyka
Re: FCP X hardware performance
on Jun 4, 2012 at 11:08:34 pm

[Jeremy Garchow] "But the OS isn't optimized for it, Walter. We have had this discussion sooo much. Instead of singling me out for it, reread what Oliver said... Apple is not in the CPU race, my guess is from their standpoint, they don't have to be and take a different philosophy about what "speed" means."

Sorry, mate, I'm certainly not trying to single you out -- but you gave me the easy one-liner "Apple has always favored system stability over raw power" to riff on. I think that the way the statement above pits performance against stability is a false dichotomy, and I think it doesn't give Apple enough credit for how they have competed in performance computing.

In my previous post, I gave specific examples, both in hardware and software, that show that Apple goes beyond simply caring about computational performance -- they've actually driven it in some areas (though clearly not in all).

Saying the OS isn't optimized for performance is inaccurate. Look at current technologies like Grand Central Dispatch [link] and OpenCL [link] -- two technologies designed to allow developers to wring even more performance out of modern computers with both multiple homogenous processors and multiple heterogeneous processors. Look at the movement away from creaky old APIs like QuickTime toward newer APIs like AV Foundation. Look at the addition of high-performance APIs like CoreImage and CoreVideo.

To Oliver's point, some apps in the now-discontinued FCS weren't exactly modern applications, so the apps themselves performed relatively poorly on multicore systems because they had poor or non-existent multithreading support. That's got nothing to do with OS X's support for multithreading.

As for comparing the performance of cross-platform applications, I'd argue there are too many variables to say whether a specific performance difference have to do with the OS or the apps themselves. I've seen a report that Cinema 4D runs faster on the exact same dual-booting Windows/Hackintosh hardware when it's running OS X than when it's running Windows.

Further, I think that FCPX is actually a great example of a modern application that can wring phenomenal performance from a Mac by exploiting Apple's recent performance-oriented technologies, from AV Foundation up to GCD and OpenCL. As Lance pointed out, any dings against FCPX performance should take into account its floating point, color managed processing pipeline. What FCPX can do -- especially on "limited" hardware -- is impressive. I love Adobe, but can Premiere Pro CS6 match FCPX's render times on an iMac (or even a BootCamped iMac) when the sequence set to maximum bit depth?

All that said, I certainly agree that you have more performance options on Windows than you do on Mac -- that's why I've gone cross-platform. I'd also certainly agree that many cross-platform apps perform better on Windows.

I can agree with you that Macs are slower. I can't agree with you that this comes from a conscious tradeoff of speed for stability. If I understand correctly, you're saying that Apple is simply choosing not to compete on performance, and that they differentiate instead on stability. I'd argue that stability is a wash, and Apple tries to compete but just plain loses on performance.

(The most bizarre part about it is that Apple is doing some really hard stuff around performance computing -- like the initial development of OpenCL and all development of GCD -- but scrimping on the easy stuff like keeping current with Intel's reference designs while Intel does all the hard work on advancing the chipsets. Meanwhile, they are also doing the very hard work of designing their own SoCs like the A4 and A5X, getting phenomenal performance per watt in a different market segment. In light of this, I can certainly agree with you that their commitment to performance is highly disjointed.)

Finally, it may be unintended, but there's an implication in the statement "Apple has always favored system stability over raw power" -- and that's that the "raw power" platforms (Windows and Linux) favor raw power over system stability. This is simply not true. You can have your cake and eat it, too -- just not with Apple.

In other words, I agree with you that Windows is the better choice for performance, but I disagree that it has anything to do with a tradeoff for stability.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 5, 2012 at 12:16:49 am

[Walter Soyka] "In other words, I agree with you that Windows is the better choice for performance, but I disagree that it has anything to do with a tradeoff for stability."

Ok. Fair enough. As I said, Walter, this isn't true anymore. Windows has caught up in the stability department. That was my point earlier in this thread. It's there to reread.

While agree that Apple markets grand central dispatch, and the "Core" APIs, it seems all of that is built not for prpfessional use (although pro's can get a lot out of it, like fx factory) its really made so the whole OS can have animations like the "puff of smoke" when deleting something from the sidebar, or making all the app chiclets shake when rearranging app on a iPhone, or the way that everything slliiidddes around in the X timeline.

X's export is sometimes faster then Pr. Is the GPU export of X float RGB? How do we know? Rendering in X seems to be which is why it's so slow, but does the Share function share this function? If export is so fast and rendering so slow, why not make the rendering as fast as export? Isn't it kind of the same process, just different intermediate files? Something is amiss there, but I don't know enough about X and there's little "quality control" exposed to the user like there was in every sequence of Legend. It's not super cut and dry.

Also, I do not think that msoft favors speed over stability, that was not my argument. That's not what I said or implied, just so we can get that out of the way. Apple and msoft have differing needs. Msoft needs to run the worlds servers (along with Linux), Apple does not. They bowed out of that game.

In my mind, Apple has been developing for small machines to go as fast as possible, but not have the fastest machine. In that race, Apple has done a lot of work, as has intel, but OSX has a lot to do with that as well. It's efficient and portable.

As far as distributed computing, you're right Apple had done a bit of work there, but thats not "fast" CPU computing per se, it's actually spreading the load around to a bunch of smaller lower power machines to break up the work.

I will stop trying to compare Apple system stability vs msoft stability as that's not what I'm saying exactly.

Henceforth, I will say simply, Apple is not in the CPU speed race. They want small and fast, which by default doesn't mean the fastest available.


Return to posts index

Walter Soyka
Re: FCP X hardware performance
on Jun 5, 2012 at 5:39:10 am

Jeremy, you know all the criticisms -- some justified, some historical but now incorrect, and some totally unjustified -- that you get when you suggest that FCPX is a viable solution? That's what I'm seeing when I suggest that Windows as a viable solution.

Just like you, I'm trying to help the community here move past perceptions and stereotypes, and see that the situation has changed drastically while no one was looking.


[Jeremy Garchow] "As I said, Walter, this isn't true anymore. Windows has caught up in the stability department. That was my point earlier in this thread. It's there to reread. "

Yes, we are totally agreed on this. Windows used to be way, way behind on stability, but that is no longer the case.


[Jeremy Garchow] "Msoft needs to run the worlds servers (along with Linux), Apple does not. They bowed out of that game."

Microsoft's server OS is a bit different than their desktop OS, as is Apple's (and Microsoft doesn't design hardware whereas Apple does), so I'm not sure where this fits in.


[Jeremy Garchow] "I will stop trying to compare Apple system stability vs msoft stability as that's not what I'm saying exactly."

I guess I didn't make it clear enough in my post, but I do know from our previous conversations about this that this is not what you're saying, and I wasn't trying to put words in your mouth. I'm sorry if that didn't come across.

I did say "it may be unintended, but there's an implication..." but what I probably should have said is instead that it's easy for someone to incorrectly infer that if Apple prioritizes stability over performance, and if Windows is faster than OS X, then Microsoft must prioritize speed over stability.


[Jeremy Garchow] "Henceforth, I will say simply, Apple is not in the CPU speed race. They want small and fast, which by default doesn't mean the fastest available."

I can only half-agree with this. Apple is very inconstant in CPU speed race. Every Mac Pro is a speed demon at its launch, but after launch, competitors get updates with speed bumps while the Mac Pro stagnates. I see Apple's commitment to CPU speed as stop and go, and as a user who likes OS X and cares about performance, I've found it absolutely maddening. It would be easier for people like me if Macs were either always competitive or never competitive on speed, but while I agree that Apple fails to consistently offer the fastest CPUs, I don't see how you can deny that their workstations are competitive at their launches.

If Apple kills the Mac Pro, then small and fast will indeed be best description. If they release a dual E5 sizzle core beast Mac Pro next week, then the Mac Pro will again for a time be among the fastest systems available. Apple will be in the CPU speed race until Intel releases the next mid-architecture speed bump that Apple ignores and other manufacturers adopt, and this argument will continue another round.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Jeremy Garchow
Re: FCP X hardware performance
on Jun 5, 2012 at 4:11:34 pm

[Walter Soyka] "Jeremy, you know all the criticisms -- some justified, some historical but now incorrect, and some totally unjustified -- that you get when you suggest that FCPX is a viable solution? That's what I'm seeing when I suggest that Windows as a viable solution.

Just like you, I'm trying to help the community here move past perceptions and stereotypes, and see that the situation has changed drastically while no one was looking."


The funny thing is though, Walter is that I'm not saying Windows sucks like people say FCPX sucks, as a matter of fact, I have said that the two OSes are probably fairly even. My argument is that Mac's are slower and always have been, yet still I somehow feel that we are disagreeing and that I'm cathching sh*t for it! ;)

Macs are slower and have allowed significantly less simultaneous peripheral connections since I have been using Macs professionally for work. Mac used to advertise that speed was better, but rally what I found this to be was that Microsoft Windows needed more maintenance and needed to be reinstalled more than MacOSX (but don't let me fool you about stability, cause that's just ridiculous!). Once a Windows system was rebuilt, the speed returned.

[Walter Soyka] "Microsoft's server OS is a bit different than their desktop OS, as is Apple's (and Microsoft doesn't design hardware whereas Apple does), so I'm not sure where this fits in."

What I alluded to was that Microsoft has a completely different business model. Microsoft needs to support a wide variety of computer hardware (servers included). It is in their best interest to get as many copies of that software in to as many hands as possible through new computer/OEM sales, and through OS upgrades if the hardware can handle it.

Apple, on the other hand, has a very inexpensive OS, and once you purchase it, can pretty much be installed on any machine you own; totally opposite of Microsoft's model. Apple is trying to get their hardware in to as many hands as possible through various methods. You don't even need to own a Mac to have Apple hardware anymore, but I bet those little gadgets sell Macs.

[Walter Soyka] "I can only half-agree with this. Apple is very inconstant in CPU speed race. Every Mac Pro is a speed demon at its launch, but after launch, competitors get updates with speed bumps while the Mac Pro stagnates. I see Apple's commitment to CPU speed as stop and go, and as a user who likes OS X and cares about performance, I've found it absolutely maddening. It would be easier for people like me if Macs were either always competitive or never competitive on speed, but while I agree that Apple fails to consistently offer the fastest CPUs, I don't see how you can deny that their workstations are competitive at their launches. "

OK, I would see it as you whole agree, not half agree. Of course when Apple launches a new computer with brand new procs, it's going to sort of compete with a similar specced windows machine (although windows still seems to run video applications faster). Apple doesn't keep up with every single speed bump or proc refresh. That's not their game. They don't care about CPU speed enough to keep refreshing their line. See? We agree. Ha!

[Walter Soyka] "If they release a dual E5 sizzle core beast Mac Pro next week, then the Mac Pro will again for a time be among the fastest systems available. "

Yes, they will choose to use the newest processor as it probably has some architecture gains (perhaps Thunderbolt, perhaps USB3, and all the other upgrades that have been mentioned on the interwebs). But that's it. It will fit in to their system, and once it fits in to their system and you can connect the things they want you to connect (like their fancy thunderbolt monitor) then speed won't matter. They care more about the design, the architecture to support their "ecosystem", and then CPU speed is a result of the advanced technology.

I hope they do make a MacPro type thing that could be tested against the ProMAX One or HP zWhatever so we can have a good test. The current barefeats one is older generation Mac vs newer generation PC. It's not a "fair fight". The Mac gets trounced.

Jeremy


Return to posts index

Walter Soyka
Re: FCP X hardware performance
on Jun 5, 2012 at 5:56:29 pm

Jeremy, for a couple of people whose opinions are just a degree or two apart, you and I sure spend a lot of time arguing! A few details aside, I think we do agree on the big picture, here and in the other threads in which we've recently engaged.

I'm with you 100% if you say that Apple doesn't care enough about performance to keep their workstation line current like every other computer manufacturer does (even when Intel is the one doing all the work).

I'm not with you if you say that Apple never prioritizes performance. You used some black-and-white language, but it's an area where I see a couple shades of gray.

Yours sincerely, in PCs and PIOPs,

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Michael Garber
Re: FCP X hardware performance
on Jun 3, 2012 at 6:47:31 pm

Hey Oliver,

Funny, I did a similar test before reading your post just yesterday. I had a whopping 2 hr render with basic color correction and broadcast safe on 10 minutes of XDCAM footage. I compared render times between FCPX, 7, and Premiere CS6 on the same system.

Clip was a single 10-minute XDCAM EX 1920x1080i 29.97 clip.

In FCP7 and Premiere, I added a Broadcast Safe and Three-Way Color Correction (with a minor correction attached) filters. Here are my findings:

FCPX: 2 hrs
FCP7: 10 minutes (set timeline to render to Prores)
FCP7: 30 minutes (set timeline to render to XDCam)
Premiere: 20 minutes (set to render to I-Frame MPEG)
Premiere: 25 minutes (set to render to Prores)
Premiere: 25 minutes (set to render to XDCAM)

My system specs:
Mac Pro 3,1
16GB RAM
Radeon 5870
RocketRaid eSATA card
LaCie eSATA drive
Kona 3
Lion 10.7.4

Michael Garber
5th Wall - a post production company


Return to posts index

Steve Connor
Re: FCP X hardware performance
on Jun 3, 2012 at 6:58:36 pm

MB Looks is certainly very slow to render and export on my system as well, but I'm not getting any problems with any of the stock filters and corrections, even with CC, filters and cropping/resizing on shots I get better than realtime export of projects using XDCam, ProRes and AVCHD source material.

2x2.8 Quad core 2008 MacPro with 16GB RAM and Radeon 4870 card

Steve Connor
"The ripple command is just a workaround for not having a magnetic timelinel"
Adrenalin Television


Return to posts index

Michael Garber
Re: FCP X hardware performance
on Jun 3, 2012 at 7:02:30 pm

I get about 8-9 minute export time. What about your render time? My tests were on render times in the timeline.

Michael Garber
5th Wall - a post production company


Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 3, 2012 at 7:05:32 pm

[Michael Garber] "I get about 8-9 minute export time. What about your render time? My tests were on render times in the timeline."

FWIW - renders do not use the full resources of the machine. Exports do, hence faster processing and a reason to avoid renders if at all possible. Much like the Adobe approach.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Michael Garber
Re: FCP X hardware performance
on Jun 3, 2012 at 7:07:54 pm

Ah, great to know. Different way of thinking about it. Thanks for that.

Michael Garber
5th Wall - a post production company


Return to posts index

Michael Garber
Re: FCP X hardware performance
on Jun 3, 2012 at 7:31:44 pm

Thinking about this some more. I think with a faster system that can handle the effects in RT, then yes, this is a good thing. But what if you need to render something globally (in my case a simple broadcast safe) and you just want to play the timeline down without stuttering at full-res? In my case, I need to make sure all the interlacing is correct. I don't want to have to export for 10 minutes. re-import. Find an error. Re-export, etc...

Anyway, this wasn't meant to sound like an argument against your excellent advice. Just thinking out loud about why rendering is still good in a lot of cases.

Michael Garber
5th Wall - a post production company


Return to posts index

Mathieu Ghekiere
Re: FCP X hardware performance
on Jun 4, 2012 at 8:22:52 pm

You should mail that to Apple.
I've seen some similar results (I posted in a thread about an article of Apple about when to optimize Media, recently), and to be honest, it's awful.

Yes having so much real time effects and background rendering and importing is nice, but having export times that are FAR longer than the competition isn't up with their marketing of having a 64bit new code multicore future NLE. A lot of the culprit seems to be in working with XDCAM but If FCP7 could do it fast, FCPX should too.
Maybe the announced native MXF support later this year Will help.
But Olivers test proved that EVEN when working with Prores (THE code to get best performance in FCPX?) you often get slow exports in comparison with the competition.
And/or Red Giant has terrible implementation of their plugins for FCPX, also possible.
End result is the same though.


Return to posts index

Craig Seeman
Re: FCP X hardware performance
on Jun 4, 2012 at 8:31:54 pm

I tested on
On my Mac Pro 2008 8 Core GPU ATI 5770
13 minute XDCAM EX edit (no effects)
Exporting to ProRes (Current Settings) and then also testing exporting to XDCAM EX took about the same time. Around 8 minutes.

Now the interesting part
I took a 50 minute H.264 .mp4 edit (no effects). This was a Standard Def project
Exporting to ProRes (Current Settings) it also took about 8 minutes.
BLAZING FAST.
One wouldn't even dream of editing H.264 in FCP7.

So the source is having a major impact. It may seem that source codec is a major factor as 50 minutes of H.264 .mp4 exports as fast as 13 minutes of XDCAM EX going to ProRes 422HQ.



Return to posts index

Oliver Peters
Re: FCP X hardware performance
on Jun 9, 2012 at 2:01:34 pm

As a follow-up to this test, I've plugged a Quadro 4000 into my 8-core MP. When I did the tests in the original post, I was using the ATI 5870. The 4000 has twice as much VRAM. Render/export is similar to what I had been getting. About 7 1/2 min. for a :65 HD clip with MB Looks applied, versus 8+ with the ATI. However, playback performance in the FCP X UI with these effects applied, but unrendered, is a bit better. More fps (visually) and better skimming. Accessing the external interfaces for filters like Sapphire Edge and Tiffen DFX seems like there is better response with the presets inside those custom interfaces. Otherwise fine, though I did have a crash on close that seems to be related to accessing a CUDA library plug-ins. I believe that some of these third party filters use CUDA acceleration when available, which might cause some conflicts with X.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]