Live data from Hacker News

Using Intel’s Xeon Phi for Brain Research Visualization

top500.org

31–39 of 39 posts

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#31

The lowest price Xeon Phi in this generation is $2,348 (1.3ghz, 64 cores) - I can't help but feel Intel would do well to introduce an enthusiast product in to the lineup. Even 1.0ghz, 48 cores for $1000. They're Tesla priced without an equivalent desktop gamer graphics card, and that means you can't just dip your toe into the water; you've got to buy the canoe up front. Programming on a normal x86 doesn't really coun…

Last year they sold a bunch of them 60 cores for $200. I got one, the problem is that they run hot and need a server that can support them. I'm yet to acquire a server with bar support, so it's still sitting. :-( Anyways, they are out there for decent price, keep your eyes open and you will find a deal.

More than just "run hot", they were the "passive" models that require external cooling. You might be interested in these 3D printed designs for the cooling:

http://www.thingiverse.com/thing:997213

http://ssrb.github.io/hpc/2015/04/17/cooling-down-the-xeon-p...

As you mention, you'd still need a motherboard with 64-bit Base Address Register support, but at least you could keep it from burning up (or more likely, shutting down when it overheats).

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#32

The lowest price Xeon Phi in this generation is $2,348 (1.3ghz, 64 cores) - I can't help but feel Intel would do well to introduce an enthusiast product in to the lineup. Even 1.0ghz, 48 cores for $1000. They're Tesla priced without an equivalent desktop gamer graphics card, and that means you can't just dip your toe into the water; you've got to buy the canoe up front. Programming on a normal x86 doesn't really coun…

Programming a modern Xeon x86 does count. Modernising your software for a haswell/skylake server Xeon (ISA was made public) also modernises it for the new Xeon Phi. You have a nearly identical ISA and programming model. In other words, modernising your code to scale well on a 16C/2P Xeon system is essentially dipping your toe for a full blown KNL Xeon Phi.

PS. For pricing, take into account that the new generation Xeon Phi's are bootable, you do not need a host CPU babysit like Tesla's case.

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#34

Earlier quoted context omitted.

> It's sort of the problem it's least competitive to solve on a raw performance, performance per watt or development cost basis. This is not true for anything beyond running compute shaders on large 1D, 2D, or 3D buffers. Just because something is 'graphics' doesn't mean that a GPU is automatically faster. > Production-ready renderers like Arnold, Octane and mental ray (NVIDIA's renderer) perform best or are exclusiv…

My bad, I wrote Arnold instead of Arion, I mix them up when writing it out. iRay is sort of a feature of mental ray, I guess if you're being pedantic. Octane isn't production ready, but I suppose if you're used to building render farms it's not production ready. It's certainly production ready for someone paying for all those licenses. > This is not true for anything beyond running compute shaders on large 1D, 2D, or…

> Yes, but rendering is a shader on a bunch of those buffers right?

No. Tracing rays is fundamentally a sorting problem when dealing with the acceleration structure. Rasterizing samples means accumulation of values and weights, which means either atomics or separate buffers (and if you are using the GPU creating a buffer for every core is out of the question). You could sort the samples into buckets and rasterize those separately, but you are again faced with GPU partitioning at the very least.

There are plenty of ways to use the GPU to do all aspects of rendering, but it is not even remotely as trivial as you are making it out to be.

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#35
post #30

Earlier quoted context omitted.

Memory bandwidth is important too. The Knights Landing processors have a 16GB on-chip memory to the cores have significantly higher bandwidth than you'd get with DDR4; the additional memory bandwidth makes more of an impact on the runtime of some algorithms than raw compute performance does.

The optional 16GB L3 is on separate chips, but it's colocated inside the same chip package. This kind of MCMs (multi-chip modules) have been used for a long time in the semiconductor industry since the 70s. Recent examples include AMD Xenos in XBox 360, Wii U CPU, IBM POWER chips.

Nope. First, it's not L3 cache and secondly comparing 3D-stacked in-package memory (MCDRAM, HBM, HBM2) with your examples is misleading. https://en.wikipedia.org/wiki/High_Bandwidth_Memory

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#36
post #31

Earlier quoted context omitted.

Last year they sold a bunch of them 60 cores for $200. I got one, the problem is that they run hot and need a server that can support them. I'm yet to acquire a server with bar support, so it's still sitting. :-( Anyways, they are out there for decent price, keep your eyes open and you will find a deal.

More than just "run hot", they were the "passive" models that require external cooling. You might be interested in these 3D printed designs for the cooling: http://www.thingiverse.com/thing:997213 http://ssrb.github.io/hpc/2015/04/17/cooling-down-the-xeon-p... As you mention, you'd still need a motherboard with 64-bit Base Address Register support, but at least you could keep it from burning up (or more likely, shutt…

Nice, thanks, I'll check those out. My plan was to run it only during the winter months outside, with massive fans.

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#37
post #30

Earlier quoted context omitted.

The optional 16GB L3 is on separate chips, but it's colocated inside the same chip package. This kind of MCMs (multi-chip modules) have been used for a long time in the semiconductor industry since the 70s. Recent examples include AMD Xenos in XBox 360, Wii U CPU, IBM POWER chips.

Nope. First, it's not L3 cache and secondly comparing 3D-stacked in-package memory (MCDRAM, HBM, HBM2) with your examples is misleading. https://en.wikipedia.org/wiki/High_Bandwidth_Memory

You can configure the near memory to be used as cache or directly addressed memory as desired. Users of existing codes will configure it as cache.

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#38
post #11
post #7

Earlier quoted context omitted.

I agree - but I think there appears to be a more significant shift underpinning this. I suspect that we are beginning to see an architectural divergence between server and client. This reverses the last 20 years where intel made inroads into the datacenter and there were few fundamental differences between xeons and their desktop brethren (the i5/i7 etc). Intel will have vastly different ISAs on server and client thi…

It's is rather silly for Phi to be positioned as "it's just like x86, oh wait except for needing to use special SIMD instructions to get max performance". Kind of like Atom being x86 for ultra mobile platforms, just not being able to match the power/performance of ARM. Once you start sacrificing things to maintain x86 compatibility, you really loose its benefits.

You really do need these changes to get max parallelism though. Where it shines is situations where you'd otherwise be porting to a GPU. On the Phi its a recompile and adding a few intrinsics to your inner loops. This is much faster than getting reasonable performance on a heterogeneous architecture and you don't have to micro-manage the slow PCIe link between the CPU and the GPU.

Re: Using Intel’s Xeon Phi for Brain Research Visualization

#39
post #37

Earlier quoted context omitted.

Nope. First, it's not L3 cache and secondly comparing 3D-stacked in-package memory (MCDRAM, HBM, HBM2) with your examples is misleading. https://en.wikipedia.org/wiki/High_Bandwidth_Memory

You can configure the near memory to be used as cache or directly addressed memory as desired. Users of existing codes will configure it as cache.

Direct addressing is the preferred configuration. Only if your existing code's working set does not fit in MCDRAM does the cache configuration make sense.

It might sound pedantic on my part, but 'it can act as cache' is very different in practice from 'It is a cache'.

Post reply on HN