Threads und Cores bei CPUs

[crys_]

Xeon Phis sind keine normalen CPUs.
Mehrkernige CPUs (i3, i5, i7) sind MIMDs (Multiple Instruction Multiple Data) Prozessoren, können also mehrere komplett verschiedene Befehle parallel, deshalb auch mehrere Programme ausführen. Bei einem i5 mit 4 Kernen ohne HT können so 4 Prozesse echt parallel bearbeitet werden. Xeon Phis sind SIMD (Single Instruction Multiple Data) Prozessoren, genau wie Grafikkarten (gibt trotzdem Unterschiede, wie schon angesprochen sind Xeons x86). Es kann nur ein Programm ausgeführt werden aber mit vielen Datensätzen parallel. Stell dir vor du rechnest mit einem Rechenschieber, aber nicht nur mit einem sondern du kopierst die Bewegung deiner Hand auf hunderte und rechnest so parallel. Du kannst aber auf jedem Rechenschieber nur das gleiche machen und nicht auf einem 1+1 und auf dem nächsten 42-13 rechenen da + und - ein anderer Befehl ist.

Programme die Xeon Phis oder Grafikkarten mit OpenCL/Cuda ausnutzen sind hoch spezialisiert und nur wenige Algorithmen lassen sich so gut parallelisieren, für "normale" Arbeiten absolut unbrauchbar. Soviel ich weiß gehen die sowieso erst bei 3000$+ los...

 

[bingo88]

Naja, der Xeon Phi ist im Grunde ein Mini-SMP-Cluster, das ist vergleichsweise nah an einem "normalen" System dran. Man kann sich per SSH auf dem Phi einloggen und ganz normal wie auf einem Linux PC arbeiten (allerdings nur Konsole, keine GUI). Auch kann man mehrere Programme gleichzeitig ausführen, das ist zwar aus Performancesicht nicht unbedingt optimal, das sieht auf einem normalen PC u. U. aber auch nicht besser aus. Das ist schon ein deutlicher Unterschied zu GPUs. Daher ist der Phi genau genommen eine MIMD-Architektur, da unterschiedliche Cores unterschiedliche Dinge tun können (wobei jeder Core wiederum eine VPU genannte SIMD-Einheit hat).

Man muss beim Phi nämlich zwei Betriebsmodi unterscheiden: Offloading und Native. Offloading ist das, was man auch mit GPUs (OpenCL, CUDA, usw.) macht, also die Nutzung als reiner Koprozessor. Dabei werden dann nur bestimmte Programmteile auf dem Phi ausgeführt (sogenannte Kernel), der Rest der Anwendung läuft auf dem Hostsystem. Im nativen Betriebsmodus wird hingegen die komplette(!) Anwendung auf dem Phi ausgeführt (muss man natürlich vorher für den Phi kompilieren, was Zugang zu den Sourcen voraussetzt). Man kann den Phi auch als eigenständigen Knoten in ein MPI-Netzwerk einbinden.

 

[crys_]

Damit wäre der Unterschied zur Graka geklärt Mir war nicht bewusst das man den Phi auch in diesem nativen Betriebsmodus betreiben kann. Wobei die Anwendungen dafür wahrscheinlich noch seltener sind. Im Prinzip ein Cluster im Steckkartenformat. Mit welcher API wir das dann gemacht wenn man es direkt für den Phi kompiliert? Läuft das in die Richtung MPI?

 

[442]

Wünsche mir solche Beschreibungen und Erklärungen gerade für die PCGH bzw. hier für die Website, nachdem jetzt das Thema aufgekommen ist, PCGH entwickelt sich immer mehr zu einer Spielewebsite.

 

[bingo88]

Mit welcher API wir das dann gemacht wenn man es direkt für den Phi kompiliert? Läuft das in die Richtung MPI?

Du kompilierst deine Anwendung eigentlich nur mit dem Intel Compiler (C/C++/Fortran). Bei Anwendungen mit vielen Abhängigkeiten ist das zwar ein riesiger Aufwand, aber prinzipiell kann man dann auch so Sachen wie Python auf der Karte laufen lassen. Man muss den Code natürlich ggf. noch für den Phi tunen, der kann zum Beispiel kein SSE, sondern nutzt eine eigene 512-Bit SIMD-Einheit (ähnlich zu AVX). Wobei der Intel Compiler auch schon recht gut optimieren kann. MPI läuft auch nativ auf der Kiste, da gibt es fertige Sachen von Intel. Ich habe damals mit einem selbstkompilierten MPICH gerabeitet, das lief ehrlich gesagt nicht so gut. Im Vergleich zu OpenMP (also Shared Memory, nicht OpenMPI) war das richtig langsam. Für den Intel MPI Kram hatte ich leider keine Lizenz, habe das daher nicht wirklich getestet. Vom Hörensagen soll das aber durchaus brauchbar sein. Insgesamt finde ich die ganze Plattform durchaus angenehm, gefällt mir besser als CUDA.

Aber auch beim Offloading hast du nicht direkt was mit einer API zu tun. Da läuft viel über #pragma (im Fall von C/C++), wobei man auch Frameworks von Intel nutzen kann, bspw. Threading Building Blocks oder Cilk Plus.

Wünsche mir solche Beschreibungen und Erklärungen gerade für die PCGH bzw. hier für die Website, nachdem jetzt das Thema aufgekommen ist, PCGH entwickelt sich immer mehr zu einer Spielewebsite.

Gut, man muss schon sagen, dass das recht exotische Hardware ist. Die ist zwar sehr interessant, aber du kannst ohne die passende Software auch nichts damit anfangen. Als das noch eine GPU werden sollte (Larrabee), hat PCGH auch mal darüber berichtet. Meine ich zumindest ^^ Das hat eher was von SPARC oder PowerPC.

 

[cryon1c]

Wünsche mir solche Beschreibungen und Erklärungen gerade für die PCGH bzw. hier für die Website, nachdem jetzt das Thema aufgekommen ist, PCGH entwickelt sich immer mehr zu einer Spielewebsite.

Naja all zu viel passiert auf dem Hardware-Markt gerade nicht. Intel hat fertig, AMD kommt nicht nach, Nvidia schiebt hier und da mal was auf den Markt und stellt Preisrekorde auf. Da schreibt man halt immer mehr über Spiele, denn da passiert mehr.

 

[crys_]

Wünsche mir solche Beschreibungen und Erklärungen gerade für die PCGH bzw. hier für die Website, nachdem jetzt das Thema aufgekommen ist, PCGH entwickelt sich immer mehr zu einer Spielewebsite.

Prinzipiell geb ich dir recht, fände es z.B. mal super wenn man in einem Heft mal die Architektur von Intel/AMD gegeneinander vergleicht und die Stärken/Schwächen an der Architektur aufzeigt. Oder mal Hyper-Threading sauber erklären, dann sind solche Threads wie dieser überflüssig Diese Xeon Phis sind aber schon extrem exotisch, das hat mit normaler Hardware für den Consumermarkt nun wirklich gar nichts mehr zu tun.

Du kompilierst deine Anwendung eigentlich nur mit dem Intel Compiler (C/C++/Fortran). Bei Anwendungen mit vielen Abhängigkeiten ist das zwar ein riesiger Aufwand, aber prinzipiell kann man dann auch so Sachen wie Python auf der Karte laufen lassen. Man muss den Code natürlich ggf. noch für den Phi tunen, der kann zum Beispiel kein SSE, sondern nutzt eine eigene 512-Bit SIMD-Einheit (ähnlich zu AVX). Wobei der Intel Compiler auch schon recht gut optimieren kann. MPI läuft auch nativ auf der Kiste, da gibt es fertige Sachen von Intel. Ich habe damals mit einem selbstkompilierten MPICH gerabeitet, das lief ehrlich gesagt nicht so gut. Im Vergleich zu OpenMP (also Shared Memory, nicht OpenMPI) war das richtig langsam. Für den Intel MPI Kram hatte ich leider keine Lizenz, habe das daher nicht wirklich getestet. Vom Hörensagen soll das aber durchaus brauchbar sein.

Ich hoff mir fällt mal einer in die Hände Das ist sicher ein tolles Spielzeug Intel wird bei seiner MPI Implementierung schon ordentlich für den Phi optimiert haben, das wird auf jeden Fall besser laufen...man will ja verkaufen und muss besser sein als die Open-Source Lösungen

 

[bingo88]

Ich hoff mir fällt mal einer in die Hände Das ist sicher ein tolles Spielzeug Intel wird bei seiner MPI Implementierung schon ordentlich für den Phi optimiert haben, das wird auf jeden Fall besser laufen...man will ja verkaufen und muss besser sein als die Open-Source Lösungen

Ist schon ein cooles Teil, leider nur sehr teuer. Zumal der anders als GPUs nicht auf jedem Board läuft. Man braucht Unterstützung für PCI-E Large Base Address Register, ich kenne aktuell kein Consumer Board, das das kann. Da muss man schon zu speziellen, zertifizierten Workstation oder Server Boards greifen, das macht die Sache nicht gerade günstiger in der Anschaffung.

 

[crys_]

Ist schon ein cooles Teil, leider nur sehr teuer. Zumal der anders als GPUs nicht auf jedem Board läuft. Man braucht Unterstützung für PCI-E Large Base Address Register, ich kenne aktuell kein Consumer Board, das das kann. Da muss man schon zu speziellen, zertifizierten Workstation oder Server Boards greifen, das macht die Sache nicht gerade günstiger in der Anschaffung.

Privat werde ich mir sowas auch definitiv nicht anschaffen Da gibts vorher den übertriebensten Gamer-PC aller Zeiten Aber es gibt sicher mal im Arbeitsumfeld ein Projekt wo man ein sehr kompaktes Clustersystem braucht

 

[bingo88]

Jo, das wäre natürlich ne Option. Die kommende Generation Knights Landing wird es ja auch gesockelt geben. Dürfte interessant werden

 

[442]

Gut, man muss schon sagen, dass das recht exotische Hardware ist. Die ist zwar sehr interessant, aber du kannst ohne die passende Software auch nichts damit anfangen. Als das noch eine GPU werden sollte (Larrabee), hat PCGH auch mal darüber berichtet. Meine ich zumindest ^^ Das hat eher was von SPARC oder PowerPC.

Larrabee? Da hast du mir gleich etwas zum nachlesen gegeben.
Mich interessiert halt alles in die Richtung ziemlich. Und so gehts anscheind auch ein paar anderen hier, sonst würde nicht so kultiviert diskutiert werden.

Naja all zu viel passiert auf dem Hardware-Markt gerade nicht. Intel hat fertig, AMD kommt nicht nach, Nvidia schiebt hier und da mal was auf den Markt und stellt Preisrekorde auf. Da schreibt man halt immer mehr über Spiele, denn da passiert mehr.

Ist mir klar, ich hab mich auch nicht wirklich an der Diskussion beteiligt. Ich finde einen geringen Spiele-Anteil sogar gut, klar, 3 Videos am Tag von GTA oder Skyrim mit Mods vs. Skyrim 720p ist wieder etwas zu viel, da ich aber keine wirklich gute Spiele-Seite (lese selten PC Games und Gamestar) kenne, emfpinde ich das als ganz angenehm. Da hat man die wichtigsten Infos auf einem Haufen.

Prinzipiell geb ich dir recht, fände es z.B. mal super wenn man in einem Heft mal die Architektur von Intel/AMD gegeneinander vergleicht und die Stärken/Schwächen an der Architektur aufzeigt. Oder mal Hyper-Threading sauber erklären, dann sind solche Threads wie dieser überflüssig Diese Xeon Phis sind aber schon extrem exotisch, das hat mit normaler Hardware für den Consumermarkt nun wirklich gar nichts mehr zu tun.

Intel und AMD miteinander vergleichen geht schief: Du kennst doch sicher den AMD vs. Intel Thread hier im Forum oder?
Ist halt die PCGH, das Forum hat den Namen extreme und wenn schon Flaute im Consumer-Markt herrscht, würden sich etwas speziellere Themen ja anbieten.
Ich finde das würde passen.


Nun hab ich aber genug von meinem Senf dazugegeben, ich verfolge die Diskussion weiterhin im Stillen.

 

[Olstyle]

Ist schon ein cooles Teil, leider nur sehr teuer. Zumal der anders als GPUs nicht auf jedem Board läuft. Man braucht Unterstützung für PCI-E Large Base Address Register, ich kenne aktuell kein Consumer Board, das das kann. Da muss man schon zu speziellen, zertifizierten Workstation oder Server Boards greifen, das macht die Sache nicht gerade günstiger in der Anschaffung.

Ich bin mir relativ sicher PCIe LBA schon in einem BIOS gesehen zu haben, will es aber nicht beschreien.
Ansonsten freue ich mich gerade einfach über einen hinten raus sehr interessanten Thread.

 

[crys_]

Was für ein Sockel sollen die dann haben? Die Dinger müssen ja relativ groß werden. Immerhin sollen sie die dreifache Single Thread Leistung bekommen, dann kann man sie zumindest eingeschränkt als CPU nutzen.
Falls es noch jemand interessiert, hier gibt es ne kleine Einführung

Ich bin mir relativ sicher PCIe LBA schon in einem BIOS gesehen zu haben, will es aber nicht beschreien.
Ansonsten freue ich mich gerade einfach über einen hinten raus sehr interessanten Thread.

Resteverwertung

Edit:

Intel und AMD miteinander vergleichen geht schief: Du kennst doch sicher den AMD vs. Intel Thread hier im Forum oder?
Ist halt die PCGH, das Forum hat den Namen extreme und wenn schon Flaute im Consumer-Markt herrscht, würden sich etwas speziellere Themen ja anbieten.
Ich finde das würde passen.

Klar geht das schief. Aber mich würde einfach mal explizit interessieren warum die AMDs in den meisten Szenarien schlecht abschneiden und warum in manchen nicht. Was genau zeichnet ein Programm aus das auf einem AMD performant läuft. Wie muss das Programms z.B. die Caches nutzen das der Bottleneck von AMD da umschifft wird. Einfach technisch Klartext, dann können die Fanboys flamen wie sie wollen (beide Seiten gemeint)

 

[Olstyle]

Wann AMD schnell ist lässt sich ohne spezielle Instruktionssätze oder Cache Spielereien sagen: Parallelisierte Integer Berechnungen.

 

[crys_]

Wann AMD schnell ist lässt sich ohne spezielle Instruktionssätze oder Cache Spielereien sagen: Parallelisierte Integer Berechnungen.

Würdest du mir du mir das als CPU-Architektur unerfahrenen Menschen kurz erleutern? Würde mich echt interessieren

 

[Olstyle]

Ein Modul mit Bulldozer Architektur(also FX und neuere große APUs) hat zwei Integer ALUs und eine floating point ALU.
Ergo hat man bei floating point Rechnung nur halb so viele "Kerne". Bei Integer kann man dagegen den allgemeinen Effizienz Nachteil zumindest durch mehr ALUs ausgleichen(in der Regel treten ja AMD Prozessoren mit genau so vielen Modulen an wie Intel mit "echten" Kernen +-HT), das hilft aber nur wenn die auch alle genutzt werden ->Parallelisierung ist nötig.

 

[crys_]

Also teilen sich beide "Kerne" im AMD-Modul eine floating point ALU und bei Intel hat folglich jeder Kern (da vollwertig) eine eigene Int und FP ALU. Heißt bei FP Berechnung brechen dem AMD 50% der Kerne weg...Macht Sinn Muss mich jetzt doch mal irgendwann mit den aktuellen Architekturen auseinander setzen, interessiert mich echt sehr.

Also bei AMDs immer fleißig aufrunden

 

[Olstyle]

Genau. Ich dachte eigentlich das wäre mittlerweile Allgemeinwissen.

Wobei ALU wieder nicht ganz korrekt war weil "ALUs" bei modernen X86 eigentlich immer Multiskalare Cluster sind.
EDIT:
Weil es mich selbst mal interessiert hat hier ein Nehalem Kern (Urvater der i7, leider finde ich nichts aktuelleres)
http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
Und hier ein Bulldozer Modul:
http://upload.wikimedia.org/wikipedia/commons/e/e9/AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG
Wie man sieht nicht gerade alles 1:1 vergleichbar.
Ein Worst Case für AMD wäre aber z.B. SSE ADD. Dafür hat Intel in einem Kern genau so viele Einheiten wie AMD pro Modul (128Bit breit, also werden aus 4x64 Bit für AMD 2x128Bit).

 

[Joker_54]

Bei AMD wird die FP-Einheit FMAC (Floating Point Multiply Accumulator) und die Integer Einheiten einfach "Pipeline" genannt

 

[Olstyle]

Wie kommst du/AMD darauf? Pipeline ist was komplett anderes als eine Integer Einheit .
Wobei aber ein Modul neben den zwei Integer Einheiten auch zwei Pipelines haben dürfte wovon halt eine stallt wenn beide die FPU brauchen.