Benchmarking Performance: CPU Rendering Tests

Rendering tests are a long-time favorite of reviewers and benchmarkers, as the code used by rendering packages is usually highly optimized to squeeze every little bit of performance out. Sometimes rendering programs end up being heavily memory dependent as well - when you have that many threads flying about with a ton of data, having low latency memory can be key to everything. Here we take a few of the usual rendering packages under Windows 10, as well as a few new interesting benchmarks.

Corona 1.3

Corona is a standalone package designed to assist software like 3ds Max and Maya with photorealism via ray tracing. It's simple - shoot rays, get pixels. OK, it's more complicated than that, but the benchmark renders a fixed scene six times and offers results in terms of time and rays per second. The official benchmark tables list user submitted results in terms of time, however I feel rays per second is a better metric (in general, scores where higher is better seem to be easier to explain anyway). Corona likes to pile on the threads, so the results end up being very staggered based on thread count.

Rendering: Corona Photorealism

Blender 2.78

For a render that has been around for what seems like ages, Blender is still a highly popular tool. We managed to wrap up a standard workload into the February 5 nightly build of Blender and measure the time it takes to render the first frame of the scene. Being one of the bigger open source tools out there, it means both AMD and Intel work actively to help improve the codebase, for better or for worse on their own/each other's microarchitecture.

Rendering: Blender 2.78


As a synthetic, LuxMark might come across as somewhat arbitrary as a renderer, given that it's mainly used to test GPUs, but it does offer both an OpenCL and a standard C++ mode. In this instance, aside from seeing the comparison in each coding mode for cores and IPC, we also get to see the difference in performance moving from a C++ based code-stack to an OpenCL one with a CPU as the main host.

Rendering: LuxMark CPU C++

POV-Ray 3.7b3

Another regular benchmark in most suites, POV-Ray is another ray-tracer but has been around for many years. It just so happens that during the run up to AMD's Ryzen launch, the code base started to get active again with developers making changes to the code and pushing out updates. Our version and benchmarking started just before that was happening, but given time we will see where the POV-Ray code ends up and adjust in due course.

Rendering: POV-Ray 3.7

Cinebench R15

The latest version of CineBench has also become one of those 'used everywhere' benchmarks, particularly as an indicator of single thread performance. High IPC and high frequency gives performance in ST, whereas having good scaling and many cores is where the MT test wins out.

Rendering: CineBench 15 MultiThreaded

Rendering: CineBench 15 SingleThreaded


Benchmarking Performance: CPU System Tests Benchmarking Performance: CPU Web Tests


View All Comments

  • Tuna-Fish - Tuesday, June 20, 2017 - link

    Just a tiny nitpick about the cache hierarchy table:

    TLBs are grouped with cache levels, that is, L1TLBs are with the L1 caches and the L2 TLB is with the L2 cache, as if the level of TLB is associated with the level of cache. This is not how they work -- any request only has to have it's address translated once, when it's loaded from the L1 cache. If there is a miss when accessing the L1 TLB, the L2 TLB is accessed before the L1 cache is.
  • PeterCordes - Monday, July 3, 2017 - link

    This common mistake bugs me too! The transistors for the TLB's 2nd level are probably not even near the L2 cache. (And the L2 cache is physically indexed / physically tagged, so it doesn't care about translations or virtual addresses at all). The multi-level TLB is a separate hierarchy from the normal caches.

    I also commented earlier to point out several other errors in [the uarch details]( e.g. mixing up the register-file sizes with the scheduler size.
  • yeeeeman - Tuesday, June 20, 2017 - link

    What this review shows just how good of a deal AMD Ryzen CPUs are. I mean, R7 1700 is like 300$ and it keeps up in many of the tests with the big boys from Intel. Reply
  • Carmen00 - Tuesday, June 20, 2017 - link

    Small typo on the first page, Ian: "For $60 less than the price of the Core i7-7800X...". But the comparison shows $389 vs $299, which is a $90 difference. Otherwise a fantastic, in-depth review, thank you very much! Reply
  • Ian Cutress - Tuesday, June 20, 2017 - link

    Official MSRPs haven't changed. What distributors do with their stock is a different story. Reply
  • Carmen00 - Wednesday, June 21, 2017 - link

    I'm talking about the MSRPs. There's a table ("Comparison: Core i7-7800X vs. Ryzen 7 1700") on Page 1 with the MSRPs as $299 and $389, a $90 difference. The text just above this table says that there's a $60 difference, but 389-299=90, not 60. So either the text is incorrect, or the MSRPs in the table are incorrect. Reply
  • Tephereth - Tuesday, June 20, 2017 - link

    Missing temps and in-game benchmarks... u're the only one in the whole web that has an 7800x to test, so please post those :( Reply
  • Gothmoth - Tuesday, June 20, 2017 - link

    after reading a dozend reviews i say:

    great now we have the choice between two buggy platforms.... well done.
    i am not going to be a bios betatester for AMD or Intel.

    these two release are the worst in many years i would say.

    i hope AMD has threadripper ironed out.
  • AntDX316 - Tuesday, June 20, 2017 - link

    The new processors are in totally another level/league/class. It dominates in everything and more except a couple benches. Reply
  • AnandTechReader2017 - Tuesday, June 20, 2017 - link

    Of course they are, Ryzen is mainstream, Thread Ripper is the competitor.
    Thread Ripper will be quite interesting, the scaling of the "infinity fabric" will come to the fore and show if AMD's new architecture is a worthy competitor.

Log in

Don't have an account? Sign up now