Az Intel Xeon Phi teljesítményéről eddig nem sok adat látott napvilágot, hiszen korábbi a CLBenchmark eredmények nem biztos, hogy mérvadónak tekinthetők, noha akkoriban hasznosnak bizonyultak, de az OpenCL meghajtó kiforrottsága megkérdőjelezhető. A legnagyobb probléma azonban, hogy a HPC-piac szempontjából nagyon kevesen vizsgálják az egyes gyorsítók működését, pedig ez lenne igazából az érdekes elemzés, hiszen pontosan ide szánják ezeket a termékeket.
Jörg Lotze, az Xcelerit technikai igazgatója még szeptemberben osztotta meg véleményét az Intel Xeon Phi 5110P és az NVIDIA Tesla K20X kapcsán, hogy mégis mennyit lehet nyerni a gyorsítók beszerelésével, amit a HPC-piacon sokat használt Monte-Carlo-módszerre épülő pénzügyi modellezéshez készült programokkal mért. A tényleges eredményekkel kapcsolatban a HPCWire lentebb megnézhető interjúja nem éppen bőséges, mivel inkább az egyszálú teljesítményhez mért gyorsulás mértékére tér ki, de ennek a hátterében nyilván vannak tényleges mérések is, aminek utánakérdeztünk.
Az első teszt rengeteg lehetséges beruházási irányt szimulál a kamatfixing szempontjából véletlen számokkal. Minden egyes Monte-Carlo-módszerre épülő irányban a kamatcsere opció értéke lesz kiszámolva dupla pontossággal. Ez a hardver szintjén nagyon sok párhuzamosan futtatható számítást jelent, valamint magának a programnak viszonylag alacsony a memóriaigénye, tehát elsősorban a nyers számítási teljesítmény lesz a döntő tényező, illetve lényegesen befolyásolja még a sebességet az architektúra működésében a szálak szinkronizációja. Nagyjából 128 000, 256 000 és 512 000 irány mellett egy Sandy Bridge CPU rendre 694, 1399 és 2711 ezredmásodperc alatt végez a program futtatásával. Ehhez képest a Xeon Phi 5110P rendre 603, 795 és 1200 ezredmásodperc eredményeket tud felmutatni, míg a Tesla K20X mindig csúcsteljesítményt nyújt a rendre 146, 280 és 543 ezredmásodperces teljesítményével. Bár a program viszonylag kevés szinkronizációt használ a szálak között, a Kepler architektúra mégis elhúz az Intel megoldásától, ami annak köszönhető, hogy az alkalmazott utasításarchitektúra számottevően hatékonyabban kezeli a párhuzamosan futó programszálak közötti szinkronizációt. Ez valahol érthető, hiszen a Keplert konkrétan erre tervezték, míg a x86 architektúra megalkotásánál fel sem merült, hogy valaha is lesznek egynél több szálat futtató processzorok. Nyilván ilyen koncepcióbeli eltérés kihozhat ekkora teljesítménykülönbséget még kevés szinkronizáció mellett is, nagyjából azonos számítási teljesítményű rendszereknél.
A második teszt szintén több párhuzamosan futó számítást végez, de a Monte-Carlo-módszerre épülő irányok nem teljesen függetlenek egymástól, ami nagyban bonyolítja a párhuzamosítást, az alkalmazás memóriaigénye is jóval nagyobb, illetve több a szálak közötti szinkronizáció. Ez technikailag a központi processzornak kedvez, de nagyjából 128 000, 256 000 és 512 000 irányt így is lehet párhuzamosítani, így a szekvenciális kódhoz képest egy Ivy Bridge CPU rendre 41,8-szeres, 48,5-szeres és 45,2-szeres gyorsulást ér el. A Xeon Phi 5110P ebben a tesztben nem jeleskedik a rendre mért 20,9-szeres, 32-szeres és 39,7-szeres gyorsulásával, ami arra vezethető vissza, hogy az alkalmazás annyira megváltozott, hogy a részfeladatok memóriaigénye nem fért bele a magokhoz rendelt fél megabájtos gyorsítótárba, ami kritikus fontosságú a MIC architektúra esetében. Ezzel gyakorlatilag hiába van sokkal több mag, a részfeladatok feldolgozása drámaian lelassul. A Tesla K20X rendre 52,9-szeres, 71,8-szeres és 86,6-szeres gyorsulásra volt képes egy Ivy Bridge maghoz viszonyítva, ami ismét annak köszönhető, hogy a Kepler utasításarchitektúrája alapjaiban is a rendkívül hatékony szinkronizációra van tervezve.
Fontos megjegyezni, hogy az NVIDIA-n a kód mindig a CUDA platformon volt írva, míg az Intel processzorain, illetve a Xeon Phi gyorsítón futó kód az első tesztprogramban kézzel optimalizált vector intrinsics, míg a másodikban vektorizált és párhuzamosított OpenMP volt. Annyit még megtudtunk, hogy a második teszt esetében a MIC architektúra esetlegesen hatékonyabban működhet OpenCL-ben írt kóddal, de egyelőre erre még nincs konkrét mérés, csupán elméleti síkon az OpenCL nyelv logikai működése sokkal jobban illik a Xeon Phi gyorsítóhoz, így olyan optimalizálásokat lehet bevetni, ami OpenMP-ben nehézkesen kivitelezhető.
