• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

14C/28T Haswell-EP Xeon Surfaces in Malaysia

S

Sweepr

Diamond Member
Intel’s Haswell-X Xeon EP Processor has surfaced in Penang, Malaysia during the company’s “Design in Asia” tour.

The Intel Haswell-X Xeon EP processor made an appearance in a visit from VR-Zone’s Nebojsa Novakovic to one of Intel’s facilities in Penang, Malaysia during Intel’s “Design in Asia” tour. The processor appears to be the Socket 2011-3 Haswell EP or Xeon E5 v3 and features 14 cores, a 35 MB cache, twin 9.6 GT/s QPI channels, and support for quad channel DDR4-2133 memory.

Even though the processor is still at least a year from commercial announcement, and the Ivy Bridge EP chips will only be arriving this summer, it seems that Intel’s Haswell Xeons have already reached at least the QS phase. Selected customers may be receiving fully working ES versions by the end of the year.

www.tomshardware.com/news/Haswell-X-Xeon-EP-Intel,23477.html

Published two days ago but no one's posted here yet.
 
Last edited:
IMG_4735.jpg
 
Is the HW architecture really able to handle so many threads and the overhead and crowding of data it would create? Or are there more fundamental changes in the "EP" chips?
 
CakeMonster said:
Is the HW architecture really able to handle so many threads and the overhead and crowding of data it would create? Or are there more fundamental changes in the "EP" chips?
Click to expand...

Are you thinking of hyperthreading efficiency here or more just the regular data I/O congestion concerns?
 
caution said:
...and all those cinebench boxes rendering ^_^
Click to expand...

Cinebench doesn't understand processor groups, and so, is pointless on these extra wide systems. Actually the quad capable E5s are a strange duck anyway. It's often cheaper to configure two duals, and you don't get the extra RAS features of E7.
 
Last edited:
Idontcare said:
Are you thinking of hyperthreading efficiency here or more just the regular data I/O congestion concerns?
Click to expand...

I was mainly thinking of IO congestion. Is the design ready and is it as simple as the above mentioned bandwidth increases or will there be more penalties?
 
CakeMonster said:
I was mainly thinking of IO congestion. Is the design ready and is it as simple as the above mentioned bandwidth increases or will there be more penalties?
Click to expand...

With the optimized prefetchers and huge fast caches that Intel has, I do expect them to have the IO situation hammered out.

I have no proof of this mind you, just confidence in their product engineers.
 
Properly written code should not have problems scaling this big - the point is in the "properly" 🙂 I am currently testing my stuff on dual 12-core Ivy EP and there are no issues with threading performance - then again, my code is mostly lockless and in rare cases it stays as little as possible in the critical section.

The problem with more than 32 physical / 64 logical cores on Windows is processor group support. The code has to be explicitly aware of CPU groups, otherwise it will not be able to use more than 64 logical cores in x64 more (32 logical cores in 32-bit mode) and CPU scheduler will "pin" all its threads into a single CPU group which is 64-cores (logical) wide.

If the Windows software you use is not aware of CPU groups then the only chance is to launch many instances of it and hope that Windows scheduler will equally spread them across 64-core groups. Then, there is the issue of NUMA memory accesses etc.

In short, to unlock performance on systems with more than 32 physical cores the software must be optimized for this:

1. Use NUMA-aware memory allocation and respect NUMA boundaries when doing work

2. On Windows (Server 2012+) it also must use new CPU-group aware Win32 APIs and set the thread affinities properly and manually.

I suspect that most consumer software except specific enterprise/HPC apps is not CPU-group aware, and subset of that software is not even NUMA-aware. Using of these apps in benchmarks of these high-core-count platforms will simply be flawed.

In fact, I believe Anandtech already did a test of Xeon E5 4600 where they used software which is not CPU-group aware, and this resulted in rather lousy results. And this is still Sandy Bridge EP 4S. Once Ivy Bridge EX (and, later, Haswell EX) becomes available, this problem will be amplified.
 
You must log in or register to reply here.
Back
Top