Folding Forum

X86 code, yes will absolutely run on PHI, but that is not the same as SSE code. So as you said, marketing BS. Be very wary of quoting anything from a product's announcement page.

And even if they fix this shortcoming, it will never be any more common (or less expensive) than a Tesla card. Just not a consumer level product.

Yeah I guess so. It seems targeted for supercomputers, which are never cheap.

iceman1992 wrote:Yeah I guess so. It seems targeted for supercomputers, which are never cheap.

Kinda cheap if do it yourself

csvanefalk wrote:Kinda cheap if do it yourself

I don't get what you mean. How can it be cheap?
And how "cheap" are you talking about?

I wonder how Microsoft is going to treat it. Presumably you'll have to buy one of the Windows Server licenses -- or switch to Linux.

bruce wrote:I wonder how Microsoft is going to treat it. Presumably you'll have to buy one of the Windows Server licenses -- or switch to Linux.

It can run as a standalone unit using factory embedded Linux.(no idea how good/capable it will be)

All the recent hardware seems to be moving toward general volume cloud computing for multiple users. Not, high speed parallel computing. So this appears to be an add on for Xeons to be upgradeable for mulit user cloud computing without upgrading the main chip or further investment. So it probably won't make one instance of a program run faster, but if you wanted to run mulituser on the same program; it would be faster. But probably not as fast as just running one instance on the same hardware without the add on. This has been Intel methodology for quite a few years now, not faster; just more stuff faster.

But isn't that the same trend as providing dua-core / quad-core / octa-core / ... multi-core CPUs, taken to an extreme, which is what the SMP client is able to take advantage of?

The only potential issue that I see is the possible lack of support of SSE extensions which is currently being required by SMP and many other FahCore's. Each Xeon core seems to be limited to the x86 instruction set rather the IA-32, x86-64 (AMD64) instruction sets supported by Sandy Bridge. which (if true) would require a version of the SMP FahCore with disable-able Assembly Optimizations and AFAIK that's not currently supported.

I think it would be stupid to release a new device without full support of the commonly accepted extensions to x86 so that's probably a misinterpretation of what we're reading, but anything is possible.

PHI is geared towards "highly threaded" but simpler vector codes. If your app speeds up because it is massively parallel, then PHI is for you. But if your app is multi-threaded, but also processor intensive, like FAH, then you stick with Xeons.

Pretty good, if length, description of Phi and GPGPU in general. Certainly outlines some of the issues that PG has been facing:
http://semiaccurate.com/2012/11/13/what ... pu-market/



"In the end, GPGPUs are a work in progress. That is the smiley happy term for the English term, "Bloody mess"."

Love the Seymour Cray quote. What a great visual reference...

The Semiaccurate article on the Phi is very interesting and indicates that it thinks gpgpu is a dead duck. It also indicates that the launch of the Phi is a killer blow to Nvidias gpgpu dominance. Who knows but a lot of people are always predicting nvidias demise, what I see is the gpu becoming like a cpu and vice versa so I suppose the future either lies in a socket or an add in card. Who knows the next thing may be a coprocessor chip from intel. I can see the motherboards now with a spare socket for a knights corner chip just like the math coprocessor all over again. All I know is I wont be able to afford one

It has been mentioned that the main barrier stopping Xeon Phi folding is its lack of SSE support. Would the Phi not be able to use standard loops without optimizations. I have found my Xeon only slows down slightly using the standard loops.

Ben_Lamb wrote:It has been mentioned that the main barrier stopping Xeon Phi folding is its lack of SSE support. Would the Phi not be able to use standard loops without optimizations. I have found my Xeon only slows down slightly using the standard loops.

A? fahcores are hardcoded to SSE. AFAIK, only old fahcore_78 actually switches dynamically between FPU and SSE. The performance difference is quite big.

Correct. No SSE means 3X slower on fahcores that can down shift like core _78. All other CPU cores won't run at all without SSE support.

Ok thanks, what does the message folding with standard loops on this execution mean then. Allways thought the assembly optimizations were things like sse.