The Intel Xeon E7-8800 v3 Review: The POWER8 Killer?
by Johan De Gelas on May 8, 2015 8:00 AM EST- Posted in
- CPUs
- IT Computing
- Intel
- Xeon
- Haswell
- Enterprise
- server
- Enterprise CPUs
- POWER
- POWER8
SAP S&D Benchmark
The SAP SD (Sales and Distribution, 2-Tier Internet Configuration) benchmark is an interesting benchmark as it is a real-world client-server application. It is one of those rare industry benchmarks that actually means something to the real IT professionals. Even better, the SAP ERP software is a prime example of where these Xeon E7 v2 chips will be used. We looked at SAP's benchmark database for these results.
Most of the results below all run on Windows 2008/2012 and MS SQL Server (both 64-bit). Every 2-Tier Sales & Distribution benchmark was performed with SAP's latest ERP 6 Enhancement Package 4. We analyzed the SAP Benchmark in-depth in one of our earlier articles. The profile of the benchmark has remained the same:
- Very parallel resulting in excellent scaling
- Low to medium IPC, mostly due to "branchy" code
- Somewhat limited by memory bandwidth
- Likes large caches (memory latency)
- Very sensitive to sync ("cache coherency") latency
Let's see how the quad Xeon compares to the previous Intel generation, the cheaper dual socket systems, and the RISC competition.
When we said that the competition in the high-end market was heating up, we were not kidding. The dual socket (24-core) S824 beats the dual socket Xeon E5 by a large margin (+35%), despite the latter having 50% more cores (36 vs 24).
At IBM's website, this server is priced at $65k, but the actual street prices are around $35k, slightly below what a typical similar quad Xeon costs (around $40k) .Of course, IBM should make it easier for small enterprises to get their hardware quickly at a decent price. But this shows that it is not impossible that POWER servers can become an alternative to the typical x86 systems... just not from IBM's webstore. The POWER8 system might be somewhat cheaper to acquire than the HP DL580 Gen9, but that Intel system is still almost 40% faster, so IBM is not an alternative quite yet. Then again, IBM is a lot more competitive than a few years ago. The S824 is not that far behind the Quad Xeon E7 v2, so it is a good thing that the new Xeon E7 offers about 20% better performance than the latter.
So who is on the top of server foodchain?
They might be power hungry, but the new POWER8 has made the Enterprise line of IBM more competitive than ever. Gone are the days that IBM needed more CPU sockets than Intel to get the top spot. Nevertheless, it should be noted that you can get several 8-socket Xeon systems for the price of one IBM E870 enterprise server.
Facebook
Twitter
RSS
146 Comments
View All Comments
thunng8 - Monday, May 11, 2015 - link
Sorry about the languageA couple points that are wrong on benchmarks:
- The Power7 p270 is a 2 socket system with 2 processors in one socket (4 processors). It was designed to get more cores into 1 socket and not outright performance per processor. If you want to show the best quad processor on 4 socket system, then it would be this result:
http://download.sap.com/download.epd?context=40E2D...
- Your comment about Power7 needing more sockets to match Intel is not based on reality. IBM held the 8 socket lead in SAP SD from March 2010 with this result:
http://download.sap.com/download.epd?context=40E2D...
It wasn't surpassed by Intel until June 2014 with this result:
http://download.sap.com/download.epd?context=40E2D...
Note: Even the Power7 result from 2010 shows higher throughput per core than the just released Haswell server chips.
And then 4 months later Power8 overtook it again. BTW, IBM recently announced the 12 core 4.02Ghz cpu in the E880..that should get an extra ~15% throughput per socket.
- Power8 L2 cache runs at full speed clock speed
A point completely overlooked and what makes Power systems really excel is the efficiency of the Power hypervisor. IMO it is the biggest selling point of the Power ecosystem.
thunng8 - Monday, May 11, 2015 - link
Another datapoint (not on spec site yet, but listed on the IBM e880 performance site):http://www-03.ibm.com/systems/power/hardware/e880/...
SpecIntRate: 14400
SpecfpRate: 11400
Which makes it (per processor):
SpecIntrate: 900
SepcfpRate: 713
thunng8 - Monday, May 11, 2015 - link
Also, the ibm power 760 is the same deal with the p270.It is actually a 4 socket system with 2 processors per socket.
Technical overview here:
http://www.redbooks.ibm.com/redpapers/pdfs/redp498...
thunng8 - Wednesday, May 13, 2015 - link
Well, it has been a few days since I've listed a quite few of your misrepresentations of the data in comparison to POWER, and nothing has changed and no reply at all.I find it hilarious that you can put this text in the article:
"the new POWER8 has made the Enterprise line of IBM more competitive than ever. Gone are the days that IBM needed more CPU sockets than Intel to get the top spot."
and still have it there when I've pointed out over the last 5 years (or maybe longer, I couldn't be bothered looking further), Intel has only overtaken POWER system for only 4 months. i.e. 4 months out of 60+ months
JlHADJOE - Sunday, May 10, 2015 - link
"No less than 98% of the server shipments have been 'Intel inside'... From the revenue side, the RISC based systems are still good for slightly less than 20% of the $49 Billion (per year) server market*."Wow! So RISC has 2% market share and 20% revenue.
FunBunny2 - Monday, May 11, 2015 - link
Gee. Sounds kinda like the Apple approach to production.akula2 - Sunday, May 10, 2015 - link
POWER8 is far better than Intel's counterpart.IBM is way ahead of Intel for the next generation computing with their Brain Chip.
I hope Intel's share slips with the emerging ARM 64 bit CPU (A-72) in the Server space.
ats - Tuesday, May 12, 2015 - link
Whoa, there is wrong then there is Brutalizer WRONG!First of all many IMDBs support full locking at multiple granularity including both TimesTen and SAP HANA. IMDBs are not read only and are used in the most critical performance transaction processing scenarios (because disk based DBs simply can't keep up!)
Second, IMDBs are used for a variety of DB workloads from transaction processing to analytic workloads.
Third, if your queries are taking hours, you are doing analytic workloads, not transaction processing. Transaction processing is the DB workload most dependent on locking functionality and requires real time responses. Analytic workloads are the least dependent on locking performance.
Fourth, many IMDBs are designed and deployed as the sole DB layer, including SAP HANA and TimesTen. Both fully support shadowing to disk.
Fifth, you can run businesses on **SCALE UP** severs like UV2K. Unless you now want to claim you can run businesses on mainframes, Sun's large scale servers, Fujitsu's large scale servers, IBMs large scale servers, or HP's large scale servers.
Sixth, if you think an UV2K is a cluster, you don't have enough knowledge to even post about this topic. UV2k is a SSI cache coherent SMP, no different than Oracle Sparc M6 or and IBM P795.
Seventh, you don't need a direct channel between sockets. You have never needed a direct channel between sockets. In fact the system that put Sun on the map, UE10K, did not have direct connections between each socket. In fact MANY MANY large scale sun systems have not had direct connections between sockets. If you actually knew anything about the history of big servers you would know that direct connections can be slower, using switches can be slower, and using torii and hypercubes can be slower, or they all can be faster. Looking at an interconnection network topology doesn't tell you jack. What matters is latency and latency vs load.
Eighth, people who fail at math should probably not try to make math based arguments. To directly connect N sockets, each socket needs N-1 links, no n^2 links. And you should probably learn something about how bandwidth and latency works. The more you directly connect, the less bandwidth you have between each node and the highly the latency hot spotting becomes. Using min channel widths isn't necessarily the best solution. And actually, you can have throughput and low latency, it just impacts cost.
Ninth, ScaleMP has no relation to SGI's UV2k. None.
10th, more business software runs on X86 than anything else in the world. More DBs run on x86 than anything else in the world. And neither ScaleMP nor UV2k are scale out solutions. UV2K is a pure scale-up system. You might know that if you only had a clue.
1) There are 8, 16, 32, 64, 128, AND 256 processor **SCALE-UP** x86 systems. And the x86 Superdome delivers higher performance than any previous HP scale-up system. And no, you don't need socket counts, you need performance. Socket counts are quite immaterial, and shrinking by the by.
2) SGI UV2K is not a scale out system. Its a SSI Scale Up system. When you finally admit this, you'll be one step closer to not riding the short bus.
And fyi, plenty of people use x86 for large sap installations. In fact, x86 runs more sap installations than anyone else combined.
Oh and: http://global.sap.com/solutions/benchmark/bweml-re...
And just for fun, WE LAUGH AT YOUR PUNY ORACLE SAPS: http://global.sap.com/solutions/benchmark/sd3tier.... still under a million? You are being beaten by 8 socket servers, ouch that's gotta hurt!
ats - Tuesday, May 12, 2015 - link
Whoa, there is wrong then there is Brutalizer WRONG!First of all many IMDBs support full locking at multiple granularity including both TimesTen and SAP HANA. IMDBs are not read only and are used in the most critical performance transaction processing scenarios (because disk based DBs simply can't keep up!)
Second, IMDBs are used for a variety of DB workloads from transaction processing to analytic workloads.
Third, if your queries are taking hours, you are doing analytic workloads, not transaction processing. Transaction processing is the DB workload most dependent on locking functionality and requires real time responses. Analytic workloads are the least dependent on locking performance.
Fourth, many IMDBs are designed and deployed as the sole DB layer, including SAP HANA and TimesTen. Both fully support shadowing to disk.
Fifth, you can run businesses on **SCALE UP** severs like UV2K. Unless you now want to claim you can run businesses on mainframes, Sun's large scale servers, Fujitsu's large scale servers, IBMs large scale servers, or HP's large scale servers.
Sixth, if you think an UV2K is a cluster, you don't have enough knowledge to even post about this topic. UV2k is a SSI cache coherent SMP, no different than Oracle Sparc M6 or and IBM P795.
Seventh, you don't need a direct channel between sockets. You have never needed a direct channel between sockets. In fact the system that put Sun on the map, UE10K, did not have direct connections between each socket. In fact MANY MANY large scale sun systems have not had direct connections between sockets. If you actually knew anything about the history of big servers you would know that direct connections can be slower, using switches can be slower, and using torii and hypercubes can be slower, or they all can be faster. Looking at an interconnection network topology doesn't tell you jack. What matters is latency and latency vs load.
Eighth, people who fail at math should probably not try to make math based arguments. To directly connect N sockets, each socket needs N-1 links, no n^2 links. And you should probably learn something about how bandwidth and latency works. The more you directly connect, the less bandwidth you have between each node and the highly the latency hot spotting becomes. Using min channel widths isn't necessarily the best solution. And actually, you can have throughput and low latency, it just impacts cost.
Ninth, ScaleMP has no relation to SGI's UV2k. None.
10th, more business software runs on X86 than anything else in the world. More DBs run on x86 than anything else in the world. And neither ScaleMP nor UV2k are scale out solutions. UV2K is a pure scale-up system. You might know that if you only had a clue.
1) There are 8, 16, 32, 64, 128, AND 256 processor **SCALE-UP** x86 systems. And the x86 Superdome delivers higher performance than any previous HP scale-up system. And no, you don't need socket counts, you need performance. Socket counts are quite immaterial, and shrinking by the by.
2) SGI UV2K is not a scale out system. Its a SSI Scale Up system. When you finally admit this, you'll be one step closer to not riding the short bus.
And fyi, plenty of people use x86 for large sap installations. In fact, x86 runs more sap installations than anyone else combined.
Oh and: http://global.sap.com/solutions/benchmark/bweml-re...
And just for fun, WE LAUGH AT YOUR PUNY ORACLE SAPS: http://global.sap.com/solutions/benchmark/sd3tier.... still under a million? You are being beaten by 8 socket servers, ouch that's gotta hurt!
MyNuts - Tuesday, May 12, 2015 - link
Great, i guess. Wheres the holograms and teleporters. I see just another calculator :(