Performance Metrics - II

In this section, we mainly look at benchmark modes in programs used on a day-to-day basis, i.e, application performance and not synthetic workloads.

x264 Benchmark

First off, we have some video encoding benchmarks courtesy of x264 HD Benchmark v5.0. This is simply a test of CPU performance. As expected, the latest generation 45W Core i7-6770HQ emerges as the best of the lot, surpassing even 65W TDP CPUs from a couple of generations back.

Video Encoding - x264 5.0 - Pass 1

Video Encoding - x264 5.0 - Pass 2

7-Zip

7-Zip is a very effective and efficient compression program, often beating out OpenCL accelerated commercial programs in benchmarks even while using just the CPU power. 7-Zip has a benchmarking program that provides tons of details regarding the underlying CPU's efficiency. In this subsection, we are interested in the compression and decompression MIPS ratings when utilizing all the available threads. This workload doesn't show the benefits evident in the previous section, with systems using the 65W TDP CPUs getting a slight lead over the NUC6i7KYK.

7-Zip LZMA Compression Benchmark

7-Zip LZMA Decompression Benchmark

TrueCrypt

As businesses (and even home consumers) become more security conscious, the importance of encryption can't be overstated. Intel CPUs supporting the AES-NI instruction have acceleration for the encryption and decryption processes. The Core i7-6770HQ in the NUC6i7KYK does have AES-NI support. TrueCrypt, a popular open-source disk encryption program can take advantage of the AES-NI capabilities. The TrueCrypt internal benchmark provides some interesting cryptography-related numbers. In the graph below, we can get an idea of how fast a TrueCrypt volume would behave in the Intel NUC6i7KYK (Skull Canyon) and how it would compare with other select PCs. This is a purely CPU feature / clock speed based test.

TrueCrypt Benchmark

Agisoft Photoscan

Agisoft PhotoScan is a commercial program that converts 2D images into 3D point maps, meshes and textures. The program designers sent us a command line version in order to evaluate the efficiency of various systems that go under our review scanner. The command line version has two benchmark modes, one using the CPU and the other using both the CPU and GPU (via OpenCL). The benchmark takes around 50 photographs and does four stages of computation:

  • Stage 1: Align Photographs
  • Stage 2: Build Point Cloud (capable of OpenCL acceleration)
  • Stage 3: Build Mesh
  • Stage 4: Build Textures

We record the time taken for each stage. Since various elements of the software are single threaded, others multithreaded, and some use GPUs, it is interesting to record the effects of CPU generations, speeds, number of cores, DRAM parameters and the GPU using this software.

The combination of CPU power and EDRAM helps the compute capabilities when it comes to OpenCL acceleration in the second stage of the benchmark. Only the ASRock VisionX 471D with an AMD GPU performs better. Skull Canyon is placed in the top two in all the CPU-intensive stages.

Agisoft PhotoScan Benchmark - Stage 1

Agisoft PhotoScan Benchmark - Stage 2

Agisoft PhotoScan Benchmark - Stage 3

Agisoft PhotoScan Benchmark - Stage 4

Dolphin Emulator

Wrapping up our application benchmark numbers is the Dolphin Emulator benchmark mode results. This is again a test of the CPU capabilities, and this workload favors the 65W TDP CPUs. The architectural changes in Skylake are not enough to overcome the benefits provided by the higher-clock speed of the Core i7-4770R.

Dolphin Emulator Benchmark

Performance Metrics - I Gaming Benchmarks
Comments Locked

133 Comments

View All Comments

  • utferris - Monday, May 23, 2016 - link

    This can be better with ECC memory support. I just can not use any machine without ECC for work.
  • ShieTar - Monday, May 23, 2016 - link

    But a low-frequency consumer quad-core is fine? What exactly do you do at work?
  • Gigaplex - Tuesday, May 24, 2016 - link

    Sometimes reliability is more important than performance.
  • close - Monday, May 23, 2016 - link

    Guess ECC is not high on the list for potential NUC buyers, even if it's a Skull Canyon NUC. I think most people would rather go for better graphics than ECC.
  • kgardas - Monday, May 23, 2016 - link

    Indeed, the picture shows SO-DIMM ECC, but I highly doubt this is even supported since otherwise it's not Xeon nor Cxxx chipset...
  • close - Tuesday, May 24, 2016 - link

    http://ark.intel.com/search/advanced?ECCMemory=tru...
  • tipoo - Monday, May 23, 2016 - link

    What work do you want to do on a 45W mobile quad with (albeit high end) integrated graphics, that needs ECC?

    I wonder how that would work with the eDRAM anyways, the main memory being ECC, but not the eDRAM.
  • Samus - Monday, May 23, 2016 - link

    All of the cache in Intel CPU's is ECC anyway. Chances of errors not being corrected by bad information pulled from system RAM is rare (16e^64) in consumer applications.

    ECC was more important when there was a small amount of system RAM, but these days with the amount of RAM available, ECC is not only less effective but less necessary.

    I'm all for ECC memory in the server/mainframe space but for this application it is certainly an odd request. This is, for the most part, a laptop without a screen.
  • TeXWiller - Tuesday, May 24, 2016 - link

    >ECC was more important when there was a small amount of system RAM,
    The larger the array the larger target it is for the radiation to hit. Laptops are often being used in high altitude environments with generally less shielding than the typical desktop or even a server so from that perspective ECC would seem beneficial basic feature. Then there are the supercomputers, a fun read: http://spectrum.ieee.org/computing/hardware/how-to...
  • BurntMyBacon - Tuesday, May 24, 2016 - link

    @TeXWiller: "The larger the array the larger target it is for the radiation to hit."

    While this is true, transistor density has improved to the point that, despite having magnitudes more capacity, the physical array size is actually smaller. Of course the transistors are also more susceptible given the radiant energy is, relatively speaking, much greater compared to the energy in the transistor than it was when transistors were larger. There is also the consideration that as transistor density increases, it becomes less likely that radiation will strike the silicon (or other substrate), but miss the transistor. So we've marginally decreased the chance that radiation will hit the substrate, but significantly increased the change that any hit that does occur will be meaningful.

Log in

Don't have an account? Sign up now