Better late than never: Monster 15-core Xeon chips let loose by Intel Intel's long-reigning top dog in the x86 server market, the Xeon E7 "Westmere-EX" of April 2011, can finally enjoy a well-deserved retirement: its "Ivy Bridge–EX" replacement, prosaically named the Xeon E7 v2 series, has finally arrived. Intel's 15-core 'Ivy Bridge–EX' Xeon E7 v2 die Count the compute cores on this Xeon E7 …
I imagine it is because the figures come from a survey, and therefore reflect what the conservative admins are actually running, rather than what the marketing flyboys at Microsoft would like them to run.
But I don't know. (And I'm not the down-voter. It seems a reasonable question to me.)
Because with the Sparc T5 chip, only 2 threads per core can actually execute at once! Making it effectively a 32 thread CPU...But with lower overall performance than these new Xeon chips.
Scale up is also usually preferred over scale out due to ease of development, so a CPU than can do more work with 15 threads than one with 32 threads would usually be preferred.
Impressive that you can get 8 of these Xeons in a server without additional glue - so 120 fast cores and up to 192 DIMM slots (with 32GB DIMMs that's 6TB of RAM!) - that should lead to some impressive scaling boxes and allow Windows Servers to continue eating into the midrange market.....
But with lower overall performance than these new Xeon chips? What are you smoking? Until theres actually any benchmarks published, SPARC T5 currently smokes recently announced Ivybridge-EP v2 and compared to previous fastest Westmere-EX, SPARC T5 shows up to 5x faster performance depending on the benchmark. A SPARC T5-4 4-socket recently demolished the 8-socket HP ProLiant DL980 G7 server on the 10TB TPC-H datawarehouse benchmark by 2.4x with 28% better price/performance running a real enterprise level database! That’s 4.8x better performance per chip and 3x better performance per core! And SPARC T5 runs all 8-threads per core with a full 16-cores utilizing critical thread technology-and oh, by the way, its been out for almost a year now. https://blogs.oracle.com/BestPerf/entry/20131125_t5_4_tpch_10000gb
"A SPARC T5-4 4-socket recently demolished the 8-socket HP ProLiant DL980 G7 server on the 10TB TPC-H datawarehouse benchmark by 2.4x with 28% better price/performance running a real enterprise level database!"
So newer hardware / OS / database that costs 70% more can beat lower cost 2 year old hardware / OS / database - what a surprise.
"That’s 4.8x better performance per chip and 3x better performance per core!"
But much worse performance per thread.
If we assume that the performance per core and 8 CPU total Xeon system cost stays roughly the same (actually performance per core has gone up a lot), and assume performance is largely proportional to CPU power, then a box based on 8 new Xeon CPUs (with 120 cores) would easily beat the Sun / Oracle system on price performance - without even allowing for the greater memory bandwidth, faster cores, and improved OS / database versions now shipping...
Always nice to see the sales drones having a whose dick is bigger contest. Meanwhile the market spoke long ago that it was going to prefer x86_64 commodity boxes whenever it could. Now perhaps ARM might be able to change that in the future but walking dead like SPARC and Itanium sure won't.
Leaving out the "technobabbly blather" as you call it, those of use with actual experience of Sparc T series processors, can attest to the fact that if you have an application which requires fast single-threat processing, then they perform horribly. That's especially true if you try and load up all those threads, as each of those threads will be competing for just two execution units. Also the Sparc T processors were designed to be relatively simple, and lack many of the superscalar features that make processors like Power and Intel's XEONs run very fast in a single threaded mode.
Indeed, for those Solaris-based applications (including many Oracle apps) which require very fast single thread performance, then you have to use M series machines, which are rebadged Fujitsus using Fujitsu's processor design. Unfortunately, excellent as they are, Oracle's M series machines are much more expensive than servers based on Intel's XEON processor.
The T series machines are designed for throughput, not speed. They make very clever use of otherwise "dead" time when a thread is stalled waiting for data from memory, but speedy they are not. Only if you have an application that scales very well over multiple threads will you see good performance. Intel's own implementation of this, hyperthreading, can also be problematical for some applications, although it's rather less ambitious with only two threads. The Fujitsu SPARC64 processor, in later incarnations, had two threads per core, and I've had time-sensitive applications where that feature had to be turned off as response times became erratic once there was a significant statistical chance that two threads were competing for the same core (hyperthreading and similar implementations distort CPU utilisation figures as, once threads start competing, threads in execution start slowing down).
I recall a senior manager who once signed up to buy a lot of these SUN T series machines, having been sold the line that they were incredibly power efficient and could be used to consolidate workloads. Unfortunately, when implemented, he found out the hard way that these servers were wholly unsuitable for many of the applications that were in use. Ironically, many of these were based on Oracle databases. Indeed, some of Oracle's own applications perform rather poorly on T series. Of course, if he'd actually cared to ask people who understood these issues before committing, we could have told him, but he believed the particular line he was spun be the sales team.
A case of horses for courses.
These arguments sounds about 3-4 years old before Oracle acquired Sun. The old T-Series were definitely positioned as throughput systems, but with poor single thread, single core performance, but those days are long gone. Wondering if you realize that Oracle new M-Series and T-Series, both 100% designed and developed by Oracle, are based on the same core architecture and actually have significant application & database performance across any workload, especially Oracle SW based. Todays SPARC T5 and SPARC M6 systems show significant single thread and per core performance, in many cases faster than anything else out there. Just do a google search "Oracle SPARC benchmark" and see for yourself.
@Steven Jones,
That is not true anymore. It is true that first iterations of the SPARC T-cpus had weak single threaded performance. But later T-cpus such as T5 can allocate a whole core to a single thread on the fly, which means T5 has extreme throughput, and very good single threaded performance too. You can eat the cake and have it, at the same time with T5. Thus, they are not weak single threaded anymore.
This Intel Ivy Bridge-EX seems like a nice cpu, and for smaller servers it might be adequate. But if you need serious oomph you need to go to 32 socket servers, such as IBM P795 or Oracle M5-32 or the 64 socket Fujitsu M10-4S server. But datasets are increasing as we enter the Big Data age, and you need many TB of RAM. Oracle M5-32 and the Fujitsu M10-4S are the only servers on the market with 32 TB RAM. The M10-4S can have 64TB RAM with the new dimms. IBM Mainframes have at most... 3.5TB RAM I think. And IBM P795 has at most... what is it? 4TB RAM?
Intel's marketing says butt is being truly kicked? Sounds more like that old Wendy’s commercial “Wheres the beef?” As in wheres the benchmarks to prove these marketing claims (Ivybridge-EX vs SPARC T5)? And wheres the systems to justify the price comparisons-Estimates again? If you read the fine print, and yes, Intels made sure its less than 6 point type, the benchmark claim and comparison to SPARC T5 is based on “Intel Estimate” using SPECint_rate_base2006. Nice to compare performance based on estimated RAW performance, but wheres the system level application benchmarks? Wheres SPECjEnterprise2010 or TPC-C or even TPC-H? From what I can see, SPARC T5 is kicking Ivybridge v2 ass. On SPECjEnterprise2010, SPARC T5-2 is 1.5x faster than just announced 2-socket X4-2 Ivy Bridge E5-2697 v2 system. On SPECjbb2013, SPARC T5-2 is 1.8x faster than 2.7 GHz Intel Xeon E5-2697 v2. And the SPARC T5-4 just blew the doors off the previous 8-socket Xeon E7-4870 based HP DL980 G7 on TPC-H at 10TB by 2.4x. Until Intel or its partners publish real world benchmarks, making false claims based on “Internal Estimates” just shows how desperate Intel really is these days. Heres the beef. https://blogs.oracle.com/BestPerf/
Look down a bit further and you'll see comparisons using same JDK 8. The SPARC T5-2 server running SPECjbb2013 on a per chip basis is 1.3x faster than the NEC Express5800/A040b server (2.8 GHz Intel Xeon E7-4890 v2) based on both the SPECjbb2013-MultiJVM max-jOPS and SPECjbb2013-MultiJVM critical-jOPS metrics.
.
"The SPARC T5-2 server running SPECjbb2013 on a per chip basis is 1.3x faster than the NEC Express5800/A040b server (2.8 GHz Intel Xeon E7-4890 v2)"
Right, so gold boat anchor costing vastly more is only 1.3 times faster than a previous generation 2.8GHz Xeon.
A previous generation 3.3Ghz Xeon E5-2667 should give about the same performance as the SPARC T5 on a per chip basis...for much less money.
FYI. 2.8 GHz Intel Xeon E7-4890 v2 is brand new (what this article is talking about). And compared to previous generation Xeons, SPARC T5 shows a significant performance advantage whether per chip or per core based comparisons if you look at any real world benchmark, whether DB based or Java based. And considering that software licensing favors faster per core performance, the ~10-20% HW price difference between a SPARC T5-2 and a similarly configured 2.8 GHz Intel Xeon E7-4890 v2 2-socket system gets erased pretty fast considering the SPARC T5-2 has a 21% performance/core advantage (based on SPECjbb2013) than the very latest 2.8 GHz Intel Xeon E7-4890 v2 systems. If we ever see any DB benchmarks published on these Xeon E7-4890 v2, will be interesting to see how it compares to the leadership results already published with SPARC T5.
for the windows comparison.
They say UNPLANNED downtime...
Take planned and unplanned into account please.
Or just don't bother we all know the answer.
I have no doubt that modern windows server is quite stable, but the frequent reboots for updates is well still quite a problem at least on win2k8(as well as win7), I'll be trying win2k12 in the next month or so.
"but the frequent reboots for updates is well still quite a problem"
It isn't these days. If your environment is really 24 x 7 without a patching window then you simply reboot one Windows Server cluster node at a time. The down time for moving a service across cluster nodes is seconds. Or zero for the many Active Active application / service options.
Also in such an environment you would normally retain the default Windows Server Core install - and reboots required for patches on that are relatively rare.
I find that such reboots are just as frequently required due to system firmware updates, so Linux is not immune to those and requires a similar amount of planned downtime. Or if you actually keep your kernel version patched against all vulnerabilities - ditto a similar number of reboots needed!
And yeah, >$6k a chip?
At its introduction, the i486 cost $1792, adjusted for inflation ($950 in 1989). The Pentium was about $1300 in constant dollars ($800 in 1993). And those were single-core chips.
Even completely ignoring the vast per-core performance differences, charging less than five times as much for fifteen times as many cores doesn't seem wildly out of line.
Even with ECC memory there is still a slight chance of either detected but uncorrectable errors, or worse, undetected data corruption. The City doesn't like undetected errors and corruption.
Lockstep, which isn't really lockstep at all in the historic meaning of the phrase. rearranges the memory somewhat so that there is a "better" ratio of correction bits to actual data bits. This current scheme appears to have been around since (at least) 2009, e.g. in HP's Xeon Blades and maybe elsewhere. The advantage is that it reduces (but still does not quite eliminate) the chance of uncorrectable errors and undetected data corruption.
Here's a historic example.
If you have 32/36 bit wide memory (e.g. made up of 4 parity SIMMs), all you get is parity. No possibility of correction.
If you rearrange it to be 64/72bit wide memory, the mathematics of ECC means you get ECC for free.
It's a bit more complicated than that but that's the underlying concept.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
