6 ms·

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 rel

by chubot 11y ago

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 (?).

wyldfire 11y ago
> 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.
jandrewrogers 11y ago
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.
- Tomte 11y ago
  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.
  - Tomte 11y ago
    jandrewrogers wrote a bit more a year ago in https://news.ycombinator.com/item?id=8649774 https://news.ycombinator.com/item?id=8649774
- chubot 11y ago
  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.
  - aristidb 11y ago
    They even have some interesting tools, but should IMHO invest more in them: https://ispc.github.io/ https://ispc.github.io/
  - sklogic 11y ago
    Cuda computational model does not fit Phi well, you need a different approach (and, ideally, a different language).
  - rbanffy 11y ago

by chubot 11y ago

wyldfire 11y ago

> 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.

jandrewrogers 11y ago

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.

Tomte 11y ago
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.
- Tomte 11y ago
  jandrewrogers wrote a bit more a year ago in https://news.ycombinator.com/item?id=8649774 https://news.ycombinator.com/item?id=8649774
chubot 11y ago
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.
- aristidb 11y ago
  They even have some interesting tools, but should IMHO invest more in them: https://ispc.github.io/ https://ispc.github.io/
- sklogic 11y ago
  Cuda computational model does not fit Phi well, you need a different approach (and, ideally, a different language).
- rbanffy 11y ago