Puget Systems REALLY gets it when it comes to addressing the needs of our market. They have a model where they do a ton of research and provide excellent support for their tested, configured system designs. They share a lot of their data and findings on their website, which benefits the community as a whole. They are uniquely positioned to do this type of testing and I’m very thankful they share. For the vast majority of people who do NOT have interest in building their own systems, but nevertheless are realizing that a custom workstation is truly the best path forward for their needs, I can’t think of a better choice.Â
A - Building PC: I’m inclined towards PC building too, and have built many workstation machines. I built my first PC around 2001 mostly for gaming and offloaded encoding/rendering but I largely stuck with Mac for post production work until about 2012 when I made the complete jump to primary post production on Windows workstations. Teddy and I had a good chat on the phone back then just to gut check my system architecture before pulling the trigger on a $6k box build. I’ve built and rebuilt many since.Â
B-Performance: It used to be that synthetic benchmarks were quite useful in determining performance as it applied to video post work. You pretty much always needed the highest performance hardware you could get and there wasn’t a whole lot of differentiation about tasks, as it all sort of lifted with the general performance of the machine. You could look at relative performance and extrapolate your value or expected performance for the apps and work you did and make a decision about value for money/ROI/Cost-benefit with some simple math. Â
Those days are over. That won’t work anymore. The trend for nearly a decade is that PC performance gains have forked in multiple directions: CPUs have added cores, and clock speed increases have crept higher but very slowly. Due to thermals, you are often left with a choice of more cores vs more clock speed. GPUs have introduced massive parallelism tuned for specific compute loads but data has to be moved from memory/fast CPU access over the bus to the GPU and back so that is a factor in determining which types of “loads” are best suited to GPU compute. The problem is that synthetic benchmarks can be designed to torture test a specific type of computing load that shows maximized performance of a particular component but it has never been less relevant to apply those to your expectations in the apps you ACTUALLY USE to do post production work.Â
Therefore, the ONLY benchmarks that are relevant are the ones that are done by testing the apps you ACTUALLY USE to determine a particular component or configuration’s value to you. Here’s some apps that I use and what I have found they need from a machine.Â
For example here’s some differing compute loads and what types of PC hardware/config will serve it well.Â
Storage (applies to all): Everything wants fast storage and IO. Splitting up storage between media and boot and cache, each optimized is good. Storage/cacheing has become an issue too and managing the flow of data and using high performance caching devices separate from both system drive and media storage is key to optimizing. As you look at the applications below
AE: In daily use, largely still single threaded operations with dashes of multithreading throughout, and a splash of GPU compute here and there, particularly on plugins/effects. Today, this means favoring higher clock speeds over core count on the CPU. Get as much RAM as you can justify because AE and RAM previews will use it. Generally AE-only artists don’t need tons of data storage, but what they have should be fast. Often they are best served by something like a 9900k system and a modest GPU from NVidia.Â
Note that one of the challenges of optimizing AE for multithreading is that not every type of compute task lends itself well to parallelism. Sometimes you have to wait for the result of one computation to use the result of that to start the next computation. This same performance optimization issue also affects other similar apps like Fusion.Â
Premiere: A little more balanced between CPU cores and clock speed and GPU. Having said that Premiere still favors clock speed over massive core count, can take advantage of Quicksync on newer Intel CPUs BTW, and uses GPU but does not rely heavily on it and primarily processes color and effects on GPU (with some exceptions). Premiere doesn’t require quite as much RAM as AE, but I guess it doesn’t hurt. Having said that Premiere seems to need an awful lot of compute hardware thrown at it to smoothly handle media at 4k. By comparison FCPX (which I don’t use because it’s Mac only) is way more optimized and gets better performance from lesser hardware. I think there’s a lot of room for improvement for Premiere here but it probably means a rewrite.
Encoding: h264 or now h265 encoding is massively parallel and really shows off what a lot of cores can do. Currently CPU dominated we’re starting to see this moving to GPU options as well. If all you did all day was encode stuff, go for core count and fast IO. However, for most of us, encoding occupies only a few minutes per day compared to creative work.
Resolve: GPU dominated (for color page operations anyway). Here, CPU performance matters but a mid-line CPU is probably adequate but what you want are GPU compute units. The best units you can afford, plus more of them. 2 or 3 GPUs scale really well with Resolve, but in my testing I’ve found it best to keep them matched. I did some mismatched testing with different gen GPUs and it’s pretty variable and inefficient. Not that every little bit doesn’t help…but one card ends up waiting on the other to finish a task. PCI-E lanes required for multi-GPU support push the user to go with higher level platforms like X299.Â
Cinema 4D: When rendering, massive CPU core count is your friend. But when modeling, key framing, animating etc a lot fo that is more single threaded but obviously previews can be run OpenGL (etc) on the GPU. Other renderers are GPU-dominant. 3D is not my forte so I’m going to let others cover this.
But I said all of that as a preface to make this point: You can choose any one activity or app and build a kick-butt machine tuned specifically to the requirements of that activity, and walk away with maximized ROI. An AE-only machine is going to look quite different than a Resolve-only machine, and again quite different from a C4D optimized machine. But often we need to engage in a mix of activities and the choice about whether to try to build the ultimate “do it all” workstation ($$$$) vs separating the tasks is something we all have to look at in light of our own mix of work.
Anyway, when I sat down I had no idea I’d write ll that but alas, the coffee was good and plentiful. Plus, when you really get into this stuff there are just a lot of considerations to get your head around. By no means did I write a definitive guide here (is there such a thing?) and understand why Chris Zwar’s is over 10,000 words. I look forward to it.
