Voodooalert+x264 logo
US+UK flag DE+AT flag redblue redblue+hover redgreen redgreen+hover bluegreen bluegreen+hover redgreenblue redgreenblue+hover
Switch language:

Explanatory notes for the result list and its colors below:

GREEN - Operating system has been virtualized (VMware, XEN, KVM, VirtualBox, ...) or run within a Wine runtime environment - invalid for reference comparisons!
BLUE - Benchmark was run on a system below minimum specifications (e.g. 512MB RAM instead of 1GB), or with specifications below default (like with SSE4.x instruction set extensions artificially blocked) - invalid for reference comparisons!
RED - Benchmark was not run with reference software (e.g. custom x264 build, newer version, split input data for clustering etc.) - invalid for reference comparisons!
[1] Factor relative to the reference system. One click on a factor makes it the new reference, all other results factors will be shown relative to that one. (good for comparisons).
[2] "Sockets in use / Cores per socket / Threads per socket"
[3] You may also search for chipsets in the search field. You can see the chipset names by moving your mouse over a platforms name (the mainboard/system name).
[3] It is possible to filter clock speeds in the search field, e.g.:      You may also combine search terms in the field like e.g. "CPU name 1"+"CPU name 2", which is suitable for comparisons. Mind the syntax! "Item1"+"Item2"+"Item3" etc.!

[4] Hovering the mouse over a platform will show the platforms chipset.
[5] This is the efficiency per core and MHz. Consider this an "IPC" (instruction per clock) value. The faster a processor is per MHz per core, the higher the effciency. Naturally,
this favors efficient custom builds and may affect Hyperthreading/SMT CPUs to some extent, as they tend to be more or less efficent running multiple threads per core,
depending on the global logical CPU count.
[6] Average frames per second, the more the better. The total number of frames equals 31382 (2 × 15691).

The format of the runtime is HHHH:MM:SS.mmm, where H = hours, M = minutes, S = seconds and m = milliseconds.

Additional information about the lists content as well as tutorials and additional links can be found at the [bottom].


Hide custom builds
Hide virtualized systems
Hide systems below minimum specifications
Show intermediate clock rates. All clock rates for each system will be shown instead of just reference, minimum and maximum clock rates. Here, a "system" is a combination of operating system, CPU, mainboard/platform and user.
Show notebooks/tablets only. Hide all notebooks/tablets. Show all systems.

#RuntimeFactor[1]fps[6]Efficiency[5]UserS/C/T[2]CPU(s)MemoryPlatform[4]Operating System / Virtual Machine / Build infos
10002:23:26.98161.014x3.646100.00%GAT1/2/4 Intel Core m5-6Y54 1.10GHz8GB LPDDR-III/1866 14-17-17-40-1THP Elite X2 1012 G1Intel Skylake-U/YWindows 10 Pro x64 (Official r2665 x64 Build)
20004:37:33.72431.533x1.88451.68%GAT1/2/4 Intel Core m5-6Y54 1.10GHz8GB LPDDR-III/1866 14-17-17-40-1THP Elite X2 1012 G1Intel Skylake-U/YWindows 10 Pro x64

Results list developed by [Umlüx] for VA/XIN.at and further developed by [GrandAdmiralThrawn]. Additional file hosting mirrors provided by [Seth], [CryptonNite], [Blacktron] and [Cracky].

Additional information:

Additional information about the field "Operating System / Virtual Machine / Build infos"

1.) This field may contain a variety of information, but primarily just the operating system the benchmark was run on. There may be additional strings like "on VMWare ESXi", which would relate to a virtualization hypervisor. In such a case the test was run in a virtual machine based on VMWare ESXi. Sometimes the host operating system may also be shown, a complete string could look like this: "Windows 7 Pro x64 on VBox/OpenBSD 5.4 UNIX". In this case the benchmark would've been run on a Windows 7 Pro 64-Bit within a VirtualBox virtual machine. VirtualBox itself would've ran on OpenBSD 5.4 UNIX. Results like those will always be marked in green at the very least. Because of space considerations, not all information may be present, or some information may have been abbreviated, like e.g. "VBox" for "VirtualBox".

2.) Another oddity might be a piece of information enclosed in round brackets after the rest of the data, like e.g. "(Official r2334 x64 Build)", "(Custom LLVM/Clang x64 Build)" or "(Custom GCC 4.9.0 Build)". That means that the user has no longer run the standard version of the benchmark. The binary - the executable of the benchmark - was rather exchanged with another. That may happen on Windows, if the user copies over a newer and faster version of x264. On UNIX or Linux systems this will always be the case, as the reference version could be run under Wine, but would then be marked as a green result (emulated/virtualized), making the stunt pointless. Strings like "Official r2334 Build" hint at Windows systems where files were simply exchanged with newer ones released by the official x264 developers. Strings like "(Custom LLVM/Clang Build)" oder "(Custom GCC 4.9.0 Build)" however hint at UNIX-style or other systems, like Linux, BSD UNIX, Solaris, MacOS X or Haiku OS, where the user has compiled the software from source code. In certain cases this can also be done on Windows systems however. All results like those are marked in red. Also true for these strings: Because of space considerations, not all information may be present, or some information may have been abbreviated, like e.g. "(GCC 4.8.4)" for "(Custom GCC 4.8.4 Build)".

3.) The abbreviation "x64" stands for 64-bit machines, whereat this is only applicable to machines based on the x86 microarchitecture (Intel/AMD/VIA/etc.), not to RISC or native VLIW architectures (PowerPC/ARM/MIPS/IA-64/etc.). If the abbreviation is missing for any x86 processor one can usually assume that this was a 32-bit machine or at least a 32-bit operating system.

Additional information about the field "Platform" and its mouse-over data:

1.) Platforms can be many things: E.g. a mainboard in a desktop PC or server. For notebooks or systems coming from various OEM manufacturers it may be the machine name as designated by the manufacturer.

2.) In some cases the platform information may be missing altogether. That means that the user has simply not specified the platform. Often this kind of thing happened for older submissions where the specification rules were much less well-established. It is often impossible to acquire this data at a later point in time, leaving the field blank.

3.) The same may be true for chipsets shown upon mouser-over in the platform column. In rare cases, the chipset of a machine may not be ascertainable because the data is not available and/or because the user can no longer provide it either. Furthermore, in the case of modern, highly integrated SoC systems it can happen that there simply is no such thing as a chipset to address bus systems, main memory or storage devices. If this is the case, it's recognizable by the chipset name being equal to the processor descriptor, as all such functions are now integrated into the processor directly.

Additional information about the field "Memory":

1.) To understand the memory specifications, a certain amount of previous knowledge will be required. Besides the amount in megabytes, gigabytes or terabyes, additional performance-relevant technologies like ECC (Error Checking and Correction) or register buffers will be specified. The clock speed of the memory will always show the actual data rate and not the physical control clock frequency, in the manner common for this sector of the industry.

2.) In some cases there may be additional information, like "CL9" or "9-10-9-27-2T". These mean e.g. "CAS latency 9" or may show an even more detailed breakdown of several latency settings of the main memory (RAS-to-CAS latency, RAS Precharge delay etc.). To completely understand all this, you will need a deep understanding of and knowledge about DRAM memory technology. For the layman - and mostly everybody actually - it shall be said that the leftmost number is always the most relevant or even the only one specified. When going further to the right, the numbers have increasingly little effect on performance. Since we're talking about latencies here, it shall also be stated that lower numbers mean shorter latencies and quicker reaction times. The latencies are not specified in units of time, but clock cycles dependent on clock speed for their performance impact. So, "CL9" will be faster for a data rate of 1600MHz as compared to a data rate of 1333MHz. CL9 will be faster than CL11 however, as long as both systems were running the memory at the same clock speed.

3.) In the case of virtualized operating systems, only the amount of memory assigned to the virtual machine will be shown here.

Additional information about the field "CPU(s)":

1.) The processor specification is not clearly defined for some rarer cases. There are processors listed at a clock rate of 0MHz. That may happen for certain AMD processors, that had several models of several generations and clock speeds listed under the same name. Since the CPUs were not marketed with clock speeds, but rather performance ratings, the actual clock speed of a specific processor may no longer be ascertainable, because it wasn't specified by the user upon submission of the result. In some cases, this data can no longer be acquired. Another case where this may happen are hosted services - often virtualized - where the CPU data cannot be properly determined or may be falsified by the hypervisor.

2.) Processors with two specified clock speeds separated by a "@" character are showing over- or underclocked systems. Here, the user has altered the clock frequency of the processor to tune the machine for higher performance or lower power consumption.

3.) In certain cases the performance achieved by a machine may look unnaturally high given the specified clock frequency of its processor. Besides the odd submission showing a wrong result due to a crashed benchmark this may be because of the Turbo feature of the processor. Many modern chips overclock themselves automatically and well within their manufacturers specifications when put under certain loads. The results list however will always specify the reference clock speed, as the turbo clock speeds actually reached may not be constant. Those clock speeds may change dynamically based on thermal conditions ("thermal target") or high processor power consumption ("power target"). Should there be doubt about a result, please refer to the manufacturers documentation to assess whether the turbo clock frequency of the processor in question may be the reason.

Additional information about the field "S/C/T":

1.) This is an easily misunderstood field, especially for multiprocessor systems. To learn the actual amount of cores of any complete system, please multiply the first number (sockets per system) with the second one (cores per socket). A system having 4/4/8 has 4 processors with 4 cores and 8 threads each. For the complete system that means 4 × 4 = 16 cores. The system also has more threads than cores per socket, meaning we're dealing with a SMT (Simultaneous MultiThreading) processor set here, like Intels Hyper Threading CPUs. The number of threads per whole system is once again to be determined by multiplying the amount of threads with the amount of sockets. So, in this example we have 4 × 8 = 32 threads for the entire system.

2.) A special case are clustered systems. Clusters are shown as single, complete systems in any case, no matter if it's a shared memory cluster or a distributed HPC system using job queueing. Because of this, the amount of sockets per machine may be unnaturally high for clusters.

3.) In the case of virtualized systems, only the actual amount of cores and threads assigned to the virtual machine will be shown here. Since certain VM hypervisors can't handle that correctly, it may happen that SMT/Hyper Threads get suddenly reinterpreted as real processor cores.

Additional information about the field "User":

1.) A tiny subset of users also have a link on their nick names. This does not indicate any kind of sponsoring and has strictly no commercial background. In fact, it shall be understood as a thank you for the gratuitous provision of significant resources. This happened for instance, as certain university institutes agreed to allow the benchmark to be run on their cluster systems free of charge.

2.) XIN.at understands itself as a service obligated to respect the privacy of its users as far as the conditions allow it. All users shown in this list have either implicitly (when submitted via [Voodooalert.de]) or explicitly agreed to have their nick name published. Real names are only published upon explicit request by the users themselves, which is not the recommended best practice however, despite the respectability of this service. The name under which a result is being published is arbitrary as long as it is sufficiently short. Subsequent changes of names are possible and may be requested via the same channels that results can be submitted over (Voodooalert, eMail, etc.).

Additional information about the "[pp.]" remark:

1.) Fields marked with "perge, perge" ("pp.") need additional relevant explanations to enable users to properly interpret the result. Those may be too elaborate to present within the list itself, so the additional information, usually provided by the person who sent in that result can be found behind a hyperlink on that remark. Those explanations may be presented in German as well as English.

Additional Links:

The x264 benchmark results list makes use of [ie7-js], which is published under the [MIT] license. The x264 benchmark itself contains only software standing under the [GNU General Public License (GPL)]. Furthermore the x264 benchmark includes parts of the movie [Elephants Dream] © copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org, which has been released under the [Creative Commons Attribution] license.

Valid HTML 4.01 Transitional CSS is valid!

Creative Commons License
The x264 benchmark results lists output (http://www.xin.at/x264/*) by [Karl Alexander Veratschnig] and [Michael Lackner] is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Austria License].