Linux-Bench Components And Test Setup
While Windows Server is still a popular platform, many Xeon E5-based servers are also going to run some flavor of Linux as an operating system. Server-oriented hardware also has relatively poor graphics capabilities. Most are able to render a single 2D terminal with a decent amount of latency, and that's about it. As a result, we are using a variety of Linux-based benchmarks to test the Xeon E5-2600 v3.
If you've manually configured and run benchmarks under Linux, then you know they can be an exercise in frustration. For this review, we are using a "simple" test script to automate running a few common Linux benchmarks. It's free and can be found at linux-bench.com or on GitHub. There is also a new Docker.io version of the script on GitHub, so it can be run using perhaps the hottest technology of the year. The bonus of using this type of script is that it is freely available to test on your own server.
It is designed to run off of a standard Ubuntu 14.04 LTS LiveCD using only three commands. As a result, it can even be run remotely on servers with no local disks installed via KVM-over-IP. We did run with a local LiveCD image, booting into a CLI environment before each iteration to ensure no artifacts were leftover from previous runs.
The Linux-Bench script itself does little other than install dependencies and run benchmarks. As a disclaimer, I am one of the community contributors to the script. However, I do not help maintain any of the individual benchmarks.
The byte-unixbench project can be found on Google Code here. However, it has roots dating back to 1983. It is an extremely popular suite that has a number of component tests like Dhrystone, Whetstone, and shell scripts. Specifically, we are interested in the CPU tests, so metrics for 2D/3D GPU and storage are excluded. Also, since these systems have many processing cores, we utilized the high CPU count patch.
c-ray 1.1 is a popular and simple ray-tracing benchmark for Linux systems written by John Tsiombikas. It is designed so that, on most systems, it should not need to access RAM and therefore is highly sensitive to processor performance. You can find archived results, including those from SGI systems, here.
STREAM is perhaps the seminal memory bandwidth application. The benchmark was created and is maintained by Dr. John D. McCalpin. More information can be found here.
OpenSSL caused a stir with the now famous "Heartbleed" bug earlier in 2014. This is the technology that secures much of the Internet's data traffic, and is a common server application.
HardInfo is a simple benchmark that's popular in Linux-based environments. It is well known perhaps because the benchmark is installed by default on many Ubuntu desktop systems.
NAMD is a molecular modeling benchmark. It was developed by the Theoretical and Computational Biophysics Group in the Beckman Institute for Advanced Science and Technology at the University of Illinois at Urbana-Champaign. More information can be found here.
NPB or NAS Parallel Benchmarks are a set of computational fluid dynamics applications originally intended to benchmark parallel supercomputers for NASA. We are using only one node for our testing, though today's multiprocessor systems in some ways mirror parallel computers from many years ago. You'll find more information on NASA's site, here.
7-Zip is a popular open source compression application. Servers compress data for storage purposes and also before transmitting. It is an extremely common tool and common application.
redis is a popular new Web technology to help online applications scale. This is an in-memory key value store, making it memory bandwidth- and CPU performance-bound. It's an emerging technology with a strong developer base.
Sysbench is another venerable benchmarking application. It is extremely easy to use and, for this test, we are only focusing on CPU performance.
You can easily replicate these tests by downloading and running them individually. Using the Linux-Bench script's parameters have been profiled across over 100 different systems, from low-end Atoms up to quad-socket Xeon and Opteron servers, thanks to an active community participating and posting edits in GitHub.
Actually we should be trying to move away from traditional serial-styled processing and move towards parallel processing. Each core can handle only one task at a time and only utilize it's own resources by itself.
This is unlike a GPU, where many processors utilize the same resources and perform multiple tasks at the same time. The problem is that this type of architecture is not supported at all in CPUs and Nvidia is looking for people to learn to program for parallel styled architectures.
But this lineup of CPUs is clearly a marvel of engineering and hard work. Glad to see the server industry will truly start to benefit from the low power and finely-tuned abilities of haswell along with the recently introduced DDR4 which is optimized for low power usage as well. This, combined along with flash-based storage (aka SSDs) which also have lower power drain than the average HDD, will slash through server power bills and save companies literally billions of dollars. Technology is amazing isn't it?
However, with multiple cores, now we can have better AI and other "off-screen" items that don't necessarily always depend upon the user's direct input. There's still a lot of work to be done there, though.
I think all of the major server vendors are going to suck up all of the major memory manufacturers DDR4 capacity for a while before the prices go down.
Whether it helps or hinders will ultimately depend on the VM admin. What most VM admins don't realize is that HT can actually end up degrading performance in virtual environments unless the VM admin took specific steps to use HT properly (and most do not). A lot of companies will tell you to turn off HT to increase performance because they've dealt with a lot of VM admins that don't set things up properly (a lot of VM admins over allocate which is part of the reason using HT can degrade performance, but there are other settings as well that have to be set in the Hypervisor so that the guest VMs get the resources they need).
In many cases, trying to convert algorithms to threads is simply more trouble than it is worth.
A game is made by sound, logic and graphics. You may dedicate this 3 processes to a number of cores but they remain 3. As you split load some of the logic must recall who did what and where. Logic deals mainly with FPU units, while graphics with integers. GPUs are great integers number crunchers. They have to be fed by the CPU so an extra core manage data through different memories, this is where we start failing. Keeping all in one spot, with the same resources reduces need to transfer data. By implementing a whole processor with GPU, FPU, x86 and sound processor all in one package with on board memory makes for the ultimate gaming processor. As long as we render scenes with triangles we will keep using the legacy stuff. When the time will come to render scenes by pixel we will need a fraction of today's performance, and half of the texture memory (just scale the highest quality) and half of models memory. Epic is already working on that.
Great points. One minor complication is that the NVIDIA GeForce Titan used in the Haswell-E review would not have fit in the 1U servers (let alone be cooled well by then.) Onboard Matrox G200eW graphics are too much of a bottleneck for the standard test suite.
On the other hand, this platform is going to be used primarily in servers. Although there are some really nice workstation options coming, we did not have access in time for testing.
One plus is that you can run the tests directly on your own machine by booting to a Ubuntu 14.04 LTS LiveCD, and issuing three commands. There is a video and the three simple commands here: http://linux-bench.com/howto.html That should give you a rough idea in terms of performance of your system compared to the test systems.
Hopefully we will get some workstation appropriate platforms in the near future where we can run the standard set of TH tests. Thanks for your feedback since it is certainly on the radar.