Intel's 72-Core “Knight's Landing” Xeon Phi Chip Cleared for Takeoff | Hacker News Reader

Intel's 72-Core “Knight's Landing” Xeon Phi Chip Cleared for Takeoff

hothardware.com

84 pointstaspeotis48 comments

I was wondering how radically this architecture differs from more conventional x86 cores, and found this: "An Overview of Programming for Intel Xeon processors and Intel Xeon Phi coprocessors (2012)" [0]. This paper refers to a slightly older architecture - "Knight's Corner", but it should be roughly the same. Essentially, it has a large number of x86 cores with 4 in-order threads per core. Each core has a 512 KB L2 cache and the entire coprocessor is cache-coherent through a high-speed ring bus. There is also some quantity of GDDR5 (up to 8GB) on said ring bus. The great advantage over Xeon is its scaling to very high levels of parallelism: though threads on the same core will benefit from data locality, the architecture scales uniformly with more cores unlike a NUMA multi-socket setup. There's more information about the sorts of optimisations required to get good performance in the paper, but they're much the same sort of things as for Xeon. Also, according to the paper, any algorithm well suited for a GPU is well suited to the Phi architecture, though the Phi architecture is far more general-purpose in its applications.

[0] - https://software.intel.com/sites/default/files/article/33016...

The Knights Landing (KNL) memory hierarchy is different from Knights Corner because it now features MCDRAM (HBM) - even with three different modes [0].

[0] - http://www.anandtech.com/show/9794/a-few-notes-on-intels-kni...

> I was wondering how radically this architecture differs from more conventional x86 cores

The big difference besides memory and organisation is that the KNL cores are beefed-up Silvermont cores (the new Atom), which is an out of order core and pretty much what you would expect of a modern x86 architecture. The Knight's Corner cores were custom cores, somewhere between barrel and vector processors. The Knight's Landing should be even more general-purpose than the old Xeon Phi's and easier to program for.

The real question is when they will release a socketed version. The disadvantages of the PCI-E form factor are somewhat mitigated by the on-board memory, but it would still be nicer to not have to program against them as an accelerator card.

EDIT: Looks like this is in the works already [0].

[0] - http://www.nextplatform.com/2015/03/25/more-knights-landing-...

I'd love to see these parts on the desks of developers. I can't imagine there are only 4 things my computer can be doing right now. And even if there aren't, it's about 16 times fewer context switches to do.

It took Intel 10 years, starting with Larrabee in 2006, to finally produce a MIC architecture that reaches the same level of performance as high-end GPUs: AMD's, Nvidia's, and Intel's top chips now all hit 6-8 single-precision teraflops per chip. This will hopefully bring some competition to the GPU compute market which is currently owned by Nvidia.

The two main reasons Knights Landing is so competitive compared to the previous-generation Knights Corner is that (1) it doubled the raw compute performance per core thanks to its two 512-bit VPUs (vector processing units) per core compared to only 1 VPU per core for Knights Corner, and (2) it upped the number of cores from 61 to 72 while maintaining and even slightly increasing the clock frequency from 1.25 GHz to 1.3 GHz. All this was possible because Knights Landing is manufactured in 14nm while Knights Corner was 22nm, so its logic gates are 2-2.5x denser. Meanwhile all AMD and Nvidia discrete GPUs are still stuck at 28nm. The only reason GPUs still perform comparably to Knights Landing is that their execution units are simpler and smaller than Intel MIC cores.

Hm I thought Xeon Phi was sort of a failed launch? I remember the previous version being heavily discounted at one point, and it didn't seem like they were releasing new versions very quickly.

What are people using the Xeon Phi for?

nVidia seems to be making a killing off machine learning applications. The entire GTC 2015 was about deep learning.

I assume that Xeon Phi is not nearly as effective for machine learning (?).

Xeon Phi is somewhat misunderstood, and its early incarnations have not helped that. The most important point to understand is that it is neither a CPU or GPU architecture. Code designed for either of those architectures will be very suboptimal even if it does run adequately.

The Xeon Phi is a modern reincarnation of a barrel processor. It understands x86-64 opcodes but your data structures and algorithms need to be designed quite differently than vanilla CPU code if you want to optimize throughput. No one is doing that though.

In principle, if your code is correctly designed for the architecture, the Xeon Phi should significantly outperform both CPUs and GPUs for a wide range of use cases. The strength of these architectures is that their throughput is relatively insensitive to both latency and lack of trivial parallelism, which are the major bottlenecks to a lot of modern software performance. It is why Intel resurrected this style of computing architecture.

Basically, very few people know how to design software for these architectures even though it is pretty easy (much easier than GPU code). I have experience designing software for exotic architectures like this, I know what they are capable of in terms of throughput, but have never worked with a Xeon Phi. Nonetheless, the silicon specs suggest that someone that actually knows what they are doing should be able to significantly outperform e.g. GPUs for things like machine learning. Right now, it is basically being wasted because most developers treat them like weird CPUs.

I'd love to play with one of the new Xeon Phi processors to characterize its true performance but I am unlikely to see one. But I would not dismiss their performance; it is an extremely efficient kind of architecture for a surprisingly wide range of workloads if used well.

It understands x86-64 opcodes but your data structures and algorithms need to be designed quite differently than vanilla CPU code if you want to optimize throughput. No one is doing that though.

Would you be willing to expand on that? It sounds fascinating.

I'd also gladly take links or key words to google for.

jandrewrogers wrote a bit more a year ago in https://news.ycombinator.com/item?id=8649774

Hm, that's interesting. If true, it sounds like they need to take a lesson from nVidia and start providing more tools -- for example, the CUDA compiler, and libraries like cuDNN and cuFFT.

I'm sure you can do better by hand than the code generated by the CUDA compiler. But people need something to get started with, and it's probably good enough for a lot of applications. In order to get adoption, the vendor has to meet developers closer to the application.

There are very few people writing assembly code from scratch anymore... and those that do are probably the kind of people who are designing their own hardware anyway!

It makes more sense for the vendor to be writing libraries in assembly, since they know the architecture best. Then apps can build on top of that in higher level languages.

They have good OpenCL and MPI support. Intel has tools that help characterize the performance of programs running on it. They are, obviously, complex tools that take some time and dedication to master.

http://shop.oreilly.com/product/9780124104143.do is an introduction and weights more than 400 pages.

According to an Intel employee I spoke to, OpenCL won't be available from day one on knights landing - all it will support will be OpenMP and MPI. Apparently they're the two main libraries which their target customer (HPC) require, so they're not putting any effort into OpenCL until they're sure it's wanted.

Intel already supports OpenCL on previous versions of the Phi. I see no reason not to assume that code will run at higher performance on Knights Landing than it did on previous versions, even if the code generated does not squeeze out every tiny bit of performance of the x86 side of the cores.

I'm not sure you understand - I mean they won't actually provide an OpenCL runtime/compiler. It's not that the code won't be slower/less performant, it's that it won't actually be possible to run it at all.

They even have some interesting tools, but should IMHO invest more in them:

https://ispc.github.io/

Cuda computational model does not fit Phi well, you need a different approach (and, ideally, a different language).

Do you have access to one of the older Phis which were (and maybe still are) available on discount? http://www.phoronix.com/scan.php?page=news_item&px=MTgzNjY

> sort of a failed launch

Yeah. But I think it's good for Intel to follow through here instead of abandoning it like they did Larrabee. Intel has some real design talent, so it would be great if they can get their software team and hardware team to work on a solution that competes well with GPUs.

It doesn't help Phi that Intel's OCL support isn't quite there yet, IMO.

If they could just put their weight behind OCL and add their own extensions to support the cases where their accelerator design is different from GPUs, it would be attractive to HPC types to port their software to support it, IMO.

> What are people using the Xeon Phi for?

I don't know but I suspect it will shine for CPU-bound code that folks don't want to waste time porting x86 executables to a new language/framework. Memory-bound stuff will probably not see an advantage over GPUs. I don't think they'll attract enough attention to TBB/Cilk or whatever they're promoting alongside Phi.

How many years therapy does this come with for the person who has to push down the motherboard lever?

None, since it's a PCI-E card, not a processor.

(I'm assuming you were referring to the possibility of bending pins by trying to mount a processor incorrectly? Might be way off.)

He might have been referring to the non-pci-e version that's in the works, as hendzen pointed out: http://www.nextplatform.com/2015/03/25/more-knights-landing-...

It looks really beefy.

On a related subject, can someone shed some light on the reasons and maybe the legal justification for export controls for these processors? I recall reading an article a few months ago about limitations imposed on exports to China of Xeon processors. Are these such a competitive advantage?

It's wasn't ban just for Intel Xeon, but Nvidia and AMD as well. So it is competitive advantage because there are no alternatives. It's obvious that such restrictions won't affect China's access to actual hardware, but prevent their cooperation with CPU/GPU vendors.

AMD will probably have a 32 core CPU by the time (If they are not bankrupt). It would offer a better performance since Xeon Phi CPUs are probably weaker.

http://wccftech.com/amd-exascale-heterogeneous-processor-ehp...

32 core, or "32 core":

http://www.pcworld.com/article/3003113/components-processors...

AMD's new Zen architecture implements SMT, similar to Intel's hyperthreading.

The contention about core count on the Bulldozer architecture seems spurious to me. At the time Bulldozer was being developed, multi-core systems were just being introduced to the consumer market. It was unclear what sort of architecture would be most performant. AMD made a (bad only in hindsight) bet that Bulldozer would be a viable architecture for general purpose compute loads. It turns out that combining 1 FPU with two integer pipelines is not as effective as an SMT architecture.

At the time Bulldozer was developed and released, what exactly constituted a core was still not precisely defined. It turns out that Intel's SMT architecture is much more effective, and thanks to market- and mind-share, people associate the definition of a core with Intel's specific implementation.

AMD's new development is on an SMT architecture known as Zen. Like all AMD news and marketing, it sounds exciting. Hopefully they execute well and it actually turns out to be exciting.

Cores are real Zen cores with dedicated FPU units. This has nothing to do with bulldozer.

However these still have higher bandwidth memory for streaming data in/out of processing. Increasing core count without increasing memory throughput only works for some types of problems (with high locality of data).

Seems like they will be using Coherent Fabric. I think together with HBM, this can rival Intel offerings.

http://www.fudzilla.com/news/processors/38402-amd-s-coherent...

nice. I remember reading about this (what feels like) ages ago at this point. Patiently waiting to see if Terry Davis shows up. reference:[0]

[0]: https://usesthis.com/interviews/terry.davis/

Are there any publicly accessible clusters/clouds with these?

NVIDIA Titan X today: 336 GB/s, 7 teraflops

Intel Xeon Phi next year: 400 GB/s, 6 teraflops

NVIDIA Pascal next year: 1 TB/s, >10? teraflops

NVIDIA still wins for my applications. Intel is aiming too low.

Supercomputers are not just compute. They also need networking. Knights Landing has a 100 gbit specialized network on-die, called Omni-Path. The competition has to use a discrete chip for that, and Intel's got a more scalable network fabric, apparently.

Appealing to numbers without more context doesn't make for a very interesting conversation.

I'm going to guess that your applications do some kind of streaming numerical processing or maybe some kind of large linear algebra. And, GPU cores are great that.

There's other applications that have a more complex work profile in terms of interleaving branchy logic with numerical processing. A good example of this might be a OLAP Database. They need do some query parsing, building a plan, optimizing that plan, work with indexes, do data decompression (traditional schemes and data specific schemes) then process that data, and do operations on it (join, filter, aggregate).

There's so many steps in that process and some of them require branching logic some of then numerical processing and some of them a combination of both. If you breakup a large query (partition) the Phi being good at both kind of computation and having fast RAM makes it an ideal platform to develop this.

This can run native x86 code though (although to take advantage of the architecture code might have to be re-written to some extent).

So this means you can run the same code on a desktop Xeon as this one.

Yeah, Intel's behind the curve for sure. But what if they had a soup-to-nuts open ecosystem? IMO that can be a real winner for simple, convenient deployment of a total solution.

It doesn't make up for being a generation+ behind, but I expect they'll catch up over time.

I'm not sure Intel will catch up. Underestimating the power and importance of graphics hardware seems to be a chronic problem that they have.

It's a shame NVIDIA's Project Denver custom CPU didn't seem to work out very well. I was really hoping they'd be able to produce a CPU worthy of pairing with their top-end GPUs, to make an x86-free workstation and lessen their dependence on Intel. Wouldn't that be something?

Good luck getting to that tflop upper limit on anything but the most trivially parallel tasks. Phi got much more flexibility than the GPUs.

> NVIDIA still wins for my applications

Just a wild guess, but perhaps different people have different applications where GPUs don't fit in as well.

Why do you think they still do it? It would seem they have enough people for someone to check NVIDIA's numbers.

Are they offering something closer to general purpose CPUs, something that could schedule OS threads to run on it?

According to the article hendzen linked to, the Phi processors are absolutely general purpose CPUs -- they can be the main CPU on the board and can boot and run stock OSes.

This is much more powerful than a GPU, which is fundamentally SIMD -- it can hit TFLOPS speeds running hundreds of threads doing different things. While not everyone will need this power, I suspect it will open up entire new classes of applications.

It still only hits teraflops speed when you're running very wide SIMD code - non-SIMD stuff is a lot slower, probably roughly the same speed penalty as running non-SIMD code on a GPU based on what they've released. Not only that, most researcher's very wide SIMD code is written for CUDA which this doesn't support. Oh, and the AVX-512 instructions required to take advantage of the full speed of this aren't used by any Intel product currently in existence - you basically have to develop code specifically for this board.

Intel gives narrower and faster threads. For some applications it's better than wide slow threads of mainstream GPUs. E.g. Intel's favorite demo of raytracing is a terrible task for a GPU. I don't know if anybody is actually doing raytracing outside demos or if there are practical tasks that call for such an architecture.

Monte Carlo particle transport is a big application. It's very similar to ray tracing (ray tracing for rendering is really a special case of particle transport, specific to photons with simplified physics), except that the interactions are a lot more complicated. This is a very important task in a lot of HPC fields like astrophysics, nuclear physics etc and it isn't as well suited to CUDA style parallelism because the obvious minimum unit of computation (a single particle) has a lot of branching and data lookups. Phi is probably a bit better suited, though it still has issues with all the data lookups, which aren't very amenable to caching strategies that might otherwise help.

Thanks, I did not know about this. Yes, I figure memory access is still an issue for them since each core runs only 4 threads.

Intel Xeon Phi: general-purpose CPU w/o ridiculous stuff like warps, groups, different memory types, etc.

Actually Titan X is 6.1 teraflops (single-precision) and 0.192 teraflops (double-precision).

But this Xeon Phi is 8+ teraflops (single-precision) and 3 teraflops (double-precision).

So Knights Landing is a bit faster for SP, and ~15x faster for DP(!)

Reply on news.ycombinator.com