CPU hardly being used?

My renders (Background and sharing) are very slow, but when I check the CPU, it's hardly being troubled at all (~6%). Anything I can do to force FCPX to use all available power.

There doesn't seem to be many preference to tinker with?

Thanks

Hi Dave, welcome to the forum.

It would help a lot if we knew something more about your system:

Computer type, year, processor
Graphics card
Amount of RAM

Thank you

- Ronny

oneilld wrote: My renders (Background and sharing) are very slow, but when I check the CPU, it's hardly being troubled at all (~6%). Anything I can do to force FCPX to use all available power....

There are several things that might cause this. Your system is probably running normally. Re background rendering you can often leave this off with no ill effects -- it is a personal preference.

Many tasks cannot be totally CPU-bound since they do I/O, access the GPU or use other resources. Threads must also coordinate their work which can lead to waiting on synchronization objects like semaphores, spinlocks, etc. This is unavoidable in some algorithms and is described by Amdahl's Law.

Even with perfectly parallel code, if the program must do I/O or GPU it must often wait on those. If you are exporting to a slow USB 2.0 portable drive or a slow network drive, that could slow the entire process down, causing lower CPU utilization.

If you are looking at total CPU in Activity Monitor and have an i7 CPU, this could be reading artificially low because of how it displays hyperthreaded CPU activity.

On an i7 CPU the OS X scheduler will sometimes only use every other core to avoid "cache thrashing". You can see this when observing per-core activity in a tool like iStat Menus. So four of the cores are intentionally idle. Activity Monitor combines this to a single composite number which is artificially skewed low by the intentionally idle cores.

On my 2015 iMac 27 when exporting H264 1080p to local SSD, every other core is at about 40-50% CPU. However the OS X Activity Monitor shows very low activity, around 5-7%.

Encoding H264 is often CPU-intensive, when measured by accurate tools. This is because the compression keeps I/O rate pretty low and GPU cannot accelerate this. H264 encoding is inherently sequential but each GOP (Group Of Pictures) can be handled independently by a separate thread.

When exporting to lower-compression codecs like ProRes it is more common that CPU is lower since you become backlogged on I/O. A chain is only as strong as the weakest link.

Apologies for my lack of info...

It's this mac..
www.everymac.com/systems/apple/mac_pro/s...-westmere-specs.html

2 x 2.4Ghz processor
28gb RAM
Yosemite
ATI Radeon HD 5770 1024mb Graphics

Hope that helps a bit, and thanks Joema for your thoughts.
Dave.

oneilld wrote: ...2 x 2.4Ghz processor....

That is a Mac Pro with two "Westmere" six-core Xeon CPUs, for a total of 12 cores. They are hyperthreaded so it has 24 logical cores.

It is possibly the situation I previously described -- Activity Monitor is indicating artificially low CPU utilization since it "rolls up" all logical cores to a single number. The OS X thread dispatcher may be using every other logical core to avoid cache thrashing, which makes Activity Monitor's combined output look low.

In fact FCPX is probably using all available CPU horsepower that can be leveraged on the problem. It is sometimes more convenient to use iStat Menus for things like this: bjango.com/mac/istatmenus/

This is one area where Windows is significantly superior to OS X -- Perfmon has much more detail available and can be recorded, played back, graphs shown full screen, etc.

You could probably significantly upgrade some aspects of your performance with a better video card. That HD 5770 is much slower than the "mobile" GPU used in the current iMac 27, and even slower than the old GTX-660 in my Windows machine: www.videocardbenchmark.net/compare.php?c...%5D=2152&cmp%5B%5D=6

However GPUs cannot accelerate H264 encode/decode, so it won't help there. It would probably help on some effects.

Another problem is despite having 12 cores, the CPU generation is Westmere (essentially the same as Nehalem). This is several generations old which means performance per clock is about 2x slower than current chips and it does not have Quick Sync (actually almost no Xeon has this, even today) which means it does not have hardware-accelerated H264 encode/decode. A 2015 iMac 27 could probably export to H264 10x faster. I'm not suggesting replacing your machine, just letting you know the situation.

The current iMac line will probably be refreshed late this year, possibly including new GPUs from either AMD or nVIdia using 14/16 nanometer fabrication which promise to be over 200% faster at the same power consumption. In general if someone was contemplating a purchase I'd suggest waiting until then. The Mac Pro will also be updated sometime fairly soon, if not this calendar year then certainly 1H 2017.