|#||Runtime||Factor||fps||Efficiency||User||S/C/T||CPU(s)||Memory||Platform||Operating System / Virtual Machine / Build infos|
|1||0002:23:26.981||61.014x||3.646||100.00%||GAT||1/2/4||Intel Core m5-6Y54 1.10GHz||8GB LPDDR-III/1866 14-17-17-40-1T||HP Elite X2 1012 G1Intel Skylake-U/Y||Windows 10 Pro x64 (Official r2665 x64 Build)|
|2||0004:37:33.724||31.533x||1.884||51.68%||GAT||1/2/4||Intel Core m5-6Y54 1.10GHz||8GB LPDDR-III/1866 14-17-17-40-1T||HP Elite X2 1012 G1Intel Skylake-U/Y||Windows 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 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.
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.
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.
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.
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.
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.).
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.
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.
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].