News Intel präsentiert fünf Modelle des Xeon Phi „Knights Corner“

[Dr.Pawel]

Naja ich denke erstmal muss man Intel da wirklich Respekt zollen! Wenn man bedenkt wie düster es da noch aussah vor "kurzem"....
@ Eyefinity: Der größte Schwachsinn den ich seit langem gelesen habe. Intel hat jetzt ein Marktfähiges Produkt, warte mal ab, Intel hat es bisher auf die eine oder andere Weise immer geschaft selbst Produkte an den Markt zu bringen die eigentlich schlechter sind als die der Konkurrenz und der Erfolg gibt ihnen recht. Wie man Erfolg hat ist egal, wer gewinnt hat immer recht! Da kann z.B. AMD noch die nächsten 20 Jahre heulen das sie per "korruption" nieder gerungen wurden von Intel, die hatten Erfolg damit und basta!
Ich denke wir werden einfach abwarten müssen, ich persönlich aber glaube das es ein Erfolg wird, gibt ja auch schon genug Firmen die wohl auf den Zug aufspringen wollen.

Mfg
PaWel

 

[CHAOSMAYHEMSOAP]

...da hat wenigstens AMD mal wieder was zu lachen...

Angesichts der miesen Geschäftszahlen und der Entlassungen wird AMD wohl das Lachen im Halse steckenbleiben.

Dazu kommt, daß AMD gerade mal um ein System in der Top500 zulegen konnte, während Intels Xeon Phi 6 neue Systeme verbuchen kann und mit 7 Systemen in gut doppelt sovielen Rechnern als Beschleuniger arbeitet.

 

[blöderidiot]

what is supported:

• the basic x86 instruction set ,
• the additions for Intel 64, which is Intel’s moniker for AMD64, the well-known 64-bit extension of x86,
• the x87 FPU instructions, which have been integrated since the arrival of the 486,
• new set of 32 512-bit wide ZMM registers that are accompanied with a new vector instruction set operating on those registers. It is possible to operate on vectors of 32-bit and 64-bit integer and floating point values, making them 16- respectively 8-wide

Das ist ideal ideal für Forschung und Simulation. Kann man praktisch jeden liebgewordenen wertvollen Code, insbesondere mit guten alten OpenMP-Schleifen, nach Rekompilation drauf laufen lassen. Da braucht man nicht Diplomanden oder Doktoranden abzustellen, die (mit 50% Erfolgswahrscheinlichkeit) nach CUDA oder (mit 25% Erfolgswahrscheinlichkeit) nach OpenCL portieren.

 

[Ycon]

Bis ins Jahr 21013 wartet meiner Meinung nach wohl kaum jemand

Aber schon beeindruckend, was für eine Steigerung Intel ggü. Larrabee noch mal geschafft hat (auch wenn Larrabee kein wirklicher Prototyp war, sondern eher eine Studie).

 

[Nai]

Da braucht man nicht Diplomanden oder Doktoranden abzustellen, die (mit 50% Erfolgswahrscheinlichkeit) nach CUDA oder (mit 25% Erfolgswahrscheinlichkeit) nach OpenCL portieren.

Es hat weniger etwas mit OpenCL oder CUDA und dem Portieren darauf zu tun, sondern dass GPUs diverse Hardwareoptimierungen und Hardwarelimitierungen haben, welche es zu berücksichtigen gilt und wofür man den Algorithmus anpassen und optimieren muss. Berücksichtigt man diese nicht oder lässt es der Algorithmus nicht zu diese zu berücksichtigen, kann man schnell 90 % Performance verlieren.
CPUs sind da bei weitem nicht so sensibel.

 

[Cey123]

Auf semiaccurate.com findet sich ein guter Artikel dazu. Das Ding soll ein Todesstoß für gpgpu sein, da die geringere Rechenleistung durch die universelle Einsetzbarkeit durch x86-Programmierer mehr als wett gemacht werden soll. Sprich, sich gpgpu dadurch für kaum eine Firma mehr lohnt.

 

[Nai]

Ich wäre sehr vorsichtig mit dem was Charlie Demerjian schreibt, weil dieser nicht ganz unvoreingenommen ist und schon seit nem Jahrzehnt regelmässig das baldige Ableben von Nvidia vorhersagt.

Phis sind in der Tat einfacher zu programmieren, und sind bei komplexeren Code performanter. Dafür schlagen die GPUs die Phis in Rohleistung. Was von beiden nun besser ist bzw die bessere Investition ist, ist m.E. stark Fallabhängig. Auch verändern wird sich an diesem Leistungsverhältnis kaum etwas. Denn weder wird ein PHI eine GPU in ihrer Rohleistung schlagen können ohne seine Einfachheit einzubüssen. GPUs im Gegensatz werden niemals so leicht zu Programmieren sein wie ein PHI ohne ihren Performancevorsprung zu verlieren.

Diese GPGPUs sind ja auch keine recht neue Erfindung. Denn GPUs sind intern recht ähnlich wie Vektorprozessoren aufgebaut, welche es schon seit Jahrzeiten gibt und welche afaik immer noch verwendet werden.

 

[Kasmopaya]

Man muss aber auch sagen das Intel mit 22nm 3D Transistoren einen Vorteil hat den NV und AMD noch nicht haben. (3D Fertigung ist ja auch bei TSMC unterwegs) Ohne diesen wäre Intel nicht so weit vorne. Dauert noch bis wir das dann Fertigungsbereinigt betrachten können, sollte auch irgend wann soweit sein, da ja Intel wohl Probleme bekommt bei den neuen Shirnks und es in Zukunft nicht mehr so schnell geht und uns wohl die Strukturgrößen immer länger erhalten bleiben.

Ansonsten würde ich gerne mal den Phi v. Big Kepler in einen unabhängigen Test sehen, vor allem was Performance per Watt angeht. Ich traue dem ganzen nicht, wer weis was man da alles machen kann um weiter vorne zu landen und Intel traue ich alles zu.

 

[Konsolengamer]

Wie man Erfolg hat ist egal, wer gewinnt hat immer recht! Da kann z.B. AMD noch die nächsten 20 Jahre heulen das sie per "korruption" nieder gerungen wurden von Intel, die hatten Erfolg damit und basta!

Wie man Erfolg hat ist egal??? Wer gewinnt hat immer recht???

Auf so einer Basis lässt es sicht erst gar nicht diskutieren.
Intel musste MEHRERE MILLIARDEN BUSSE zahlen, aber Intel hat nie Leute/Firmen erpresst, nein...

---------------------------
...Intel soll Capellas gedroht haben, wichtige Prozessor-Chips für Netzwerk-Rechner nicht zu liefern, falls Compaq nicht den Verkauf von AMD-Produkten einstelle. Capellas habe daraufhin AMD mitgeteilt, es sei "eine Pistole auf seinen Kopf" gerichtet. Er könne deshalb keine AMD-Prozessoren mehr kaufen....
---------------------------

Naja bringen tut es ja eh nichts wenn wir jetzt noch Unwissende aufklären (AMD ist sowieso tot, nur eine Frage der Zeit), aber wenn ich so Zeug wie von Dir lese muss ICH den Kopf mehr als nur schütteln. Was Intel da mit Fujitsu-Siemens und der Saturn-Gruppe und Dell abgezogen hat war Skandalös!

Gruss...

 

[calluna]

@eyefinity

Ja, es war skandalös, aber ist das allein der Grund für AMDs Situation? Wenn ich an den Verbrauchermarkt denke, gibt es z.B. eine Sache, die mir sofort auffällt - was hat AMD für Marken? Wie ist deren Image? Wie sieht die Werbepräsenz der Firma aus? (Ich kann mich an keinen einzigen Werbespot von AMD erinnern.)

Neben technischen Details (mit denen wirbt man nicht) sind vor allem gefühlsbeladene Assoziationen mit einem Wort / Produkt etc. wichtig.

Das ist nur ein Punkt von vielen.

@Kasmopaya

Und Nvidia und AMD traust du in dieser Hinsicht nicht alles zu?

Ohne diesen wäre Intel nicht so weit vorne. Dauert noch bis wir das dann Fertigungsbereinigt betrachten können

Die Logik dahinter erschließt sich mir nicht. Intel ist nicht nur ein Entwickler von Prozessor-Architekturen, sondern vor allem ein Hersteller von solchen Bauelementen. Und die jeweils verwendete Fertigungstechnologie ist ein wichtiger Bestandteil des angebotenen Produkts.

 

[dlux]

Mich würde die tatsächliche Leistung und nicht nur die theoretische Leistung bzw. Peak-Werten interessieren. Die reale Leistung sieht bestimmt besch... ähm, bescheiden aus.

Auf semiaccurate.com findet sich ein guter Artikel dazu. Das Ding soll ein Todesstoß für gpgpu sein, da die geringere Rechenleistung durch die universelle Einsetzbarkeit durch x86-Programmierer mehr als wett gemacht werden soll. Sprich, sich gpgpu dadurch für kaum eine Firma mehr lohnt.

Das liegt daran, dass Charlie keine Ahnung von der Materie hat. Schreibst du ein Programm in OpenCL, dann ist es hardware unabhängig. Das heißt, es läuft sowohl auf GPUs als auch auf X86 CPUs... Die Progamme müssen so oder so geschrieben werden, so viel ist klar.

 

[calluna]

@dlux

Du hast die News auch gelesen? Hast du die Diagramme mit der realen Leistung übersehen und dass die unter dem Peak liegt?

Zu der zweiten Sache: offensichtlich hast du keine Ahnung von diesem Thema, wenn du meinst, dass man in OpenCL etwas schreiben kann, was auch wirklich nützlich sein soll, ohne dabei auf die Eigenheiten der Hardware Rücksicht zu nehmen.

Das, was du schreibst, kann man bei hochgezüchteten CPUs machen oder bei Architekturen, die auch noch unter nicht optimalen Bedingungen gute Leistung bringen, ansonsten aber nicht.

 

[Nai]

Das liegt daran, dass Charlie keine Ahnung von der Materie hat. Schreibst du ein Programm in OpenCL, dann ist es hardware unabhängig. Das heißt, es läuft sowohl auf GPUs als auch auf X86 CPUs... Die Progamme müssen so oder so geschrieben werden, so viel ist klar.

Das ist nicht korrekt. Selbst wenn man ein Programm in OpenCL schreibt, so muss man auf die Eigenschaften einer GPU eingehen, oder man kann es mit der Performance vergessen. Dies ist von Fall zu Fall sehr aufwendig da meist der gesamte Algorithmus dafür angepasst werden muss. Diese Anpassungen machen nur für GPUs Sinn und führen auf CPUs zu einem Performanceverlust.

Für die Optimierung muss man auch diverse Annahmen treffen. ZB werden jeweils 32 Threads zu einem Warp zusammengefasst. Alle Threads des Warps führen alle Befehle gemeinsam aus; wobei die einzelnen Threads des Warps dabei nicht an den Befehlen teilnehmen müssen. Nehmen sie allerdings nicht teil, so bleiben die zu den Thread gehörenden Rechenkerne für diesen Ausführungszeitraum unbelegt und es geht Performance verloren.

Ein einfaches Beispiel dafür:

void kernel main()
{
int ThreadID= get_global_id(0);
for(int i=0; i< GrosseZahl; i++)
if( UnwahrscheinlicheBedingung(i, ThreadID) )
{BerechneEtwasSehrAufwändiges (i,ThreadID) ;}
}

Dieser Code würde nun dazu führen, dass das if bei einer bestimmten Iteration nur bei sehr wenigen Warpthreads wahr ist. Dementsprechen nehmen nur wenige Threads bei der sehr aufwändigen Berechnung Teil, wodurch man bei diesem Berechnen nur ein Bruchteil der maximalen Performance ausnutzt.

Eine einfache Optimierung dafür:

void kernel main()
{
int ThreadID= get_global_id(0);
int i=0;
while(true)
{
for(; i< GrosseZahl; i++)
if( UnwahrscheinlicheBedingung(i, ThreadID) )
break;

if(i== GrosseZahl)
return;

BerechneEtwasSehrAufwändiges (i,ThreadID);
}
}

Dadurch wird die Forschleife nur noch so lange iteriert, bis bei allen Threads des Warps die unwahrscheinliche Bedingung eingetreten ist. Danach führen alle Warpthreads gemeinsam die aufwändigen Berechnungen durch. So geht keine Performance mehr verloren, dass Threads nicht bei den aufwändigen Berechnungen teilnehmen. Insgesamt hat man dadurch eine bessere Performance auf der GPU. Allerdings hätte man nun das Problem, dass bei der For Schleife selbst Rechenzeit verloren gehen, da nun Threads des Warps vorher durch das Break die Schleife verlassen. Also müsste man noch weiter optimieren . . . . . . . .


Diese Annahmen sind "riskant" weil sie zwar de Fakto auf den GPUs so sind, aber nicht in den OpenCL Standard enthalten sind. Insgesamt führt das nun dazu, dass wenn man Code für die GPU optimiert, dieser Code auf CPUs Fehler erzeugt oder langsam läuft. Deshalb hat auch OpenCL durch seine Unspezialisiertheit m.E. seinen Sinn verfehlt.