Intel Larrabee: Referenz-Grafikkarte vorgestellt - Update mit Youtube-Video
Bekanntermaßen wird es keine Larrabee-Grafikkarten für Desktop-PCs geben. Als Intel Many Integrated Core Architecture (MIC) lebt das Projekt allerdings im Bereich High-Perfomance-Computing weiter.
Wer gehofft hat, dass mit Intel ein weiterer Spieler beim olympischen Zweikampf zwischen AMD und Nvidia eingreift, der wurde enttäuscht. Am 26.5. verkündete Intel lapidar, es werde (vorerst) keine dedizierte Grafikkarten auf Basis der Manycore-Technologie Larrabee geben.
Larrabee ist also ein reines Forschungsprojekt. Ausgeführt wurde diese Neuausrichtung im Rahmen der Supercomputer-Konferenz ISC 2010 in Hamburg. The artist formerly known as Larrabee tritt nun unter dem sperrigen Namen Intel Many Integrated Core Architecture (MIC) an. Das erste Serien-Produkt soll unter dem Codenamen Knights Corner in 22nm Strukturbreite gefertigt werden. Mehr als 50 Prozessorkerne sollen dann auf einem Chip vereint sein. Entwicklungs-Kit seien aktuell unter dem Codenamen Knights Ferry auf dem Weg zu ausgesuchten Entwicklern, in der zweiten Jahreshälfte wolle man noch mehr Kits zur Verfügung stellen. In Knights Ferry steckt Aubrey Isle, eine erste MIC-Version in 32 Nanometer Strukturbreite mit 32 Kernen und 1,2 GHz Takt. 1-2 GiB GDDR5, 8 MiByte geteilter Cache und 128 Threads (4 Threads pro Kern) sind weitere Eckdaten.
In der Galerie sehen Sie unter anderem die Ex-Larrabee-Grafikkarte für Entwickler, außerdem einen Die-Shot von Aubrey Isle. Ganz neu dabei: Ein Video zur Knights-Ferry-Grafikkarte mit synthetischen Benchmarks.
Mehr zum Intel Larrabee finden Sie auch auf der PCGH-Themenwebseite.
[embhtml=31504]
Entweder das Programm ist multi Thread geschrieben oder nicht.
Ein Programm startet weitere Threads immer von sich aus.
Nur der Programmierer kann wissen, welche Operationen unabhängig parallel arbeiten können.
Wenn Hardware (oder das Betriebssystem) in irgend einer Weise einen Teil des Programmablaufes früher startet (auf dem 2. Kern) dann wird dem Ablauf das Ergebnis des ersten Teils fehlen.
Im besten Fall sind fall back Variablen und Try-Catch Routinen implementiert.
Dann gibt es nur ein falsches Ergebnis.
Ansonsten stürzt das Ganze ab.
Als Beispiel eine Simple Anwendung.
Eine Zahl wird jede Sekunde um 1 erhöht, bis der Nutzer einen Button drückt.
Dann kommt ein PopUp und zeigt die Zahl an.
Shematisch:
10 wenn wieder 1000ms vergangen: geheZu 30
20 geheZu 10
30 _zahl += 1
40 wenn button gedrückt: geheZu 60
50 geheZu 10
60 popup _zahl
wenn ein zweiter Thead bei 10 - 50 startet, laufen plötzlich zwei Timer und die Zahl wird immer um 2 erhöht.
(ganz abgesehen davon dass hier Speicherraum Verletzungen auftreten!)
Wenn er bei 60 einspringt passiert, was eigentlich nur auf Nutzeringabe hätte passieren sollen.
Das Beispiel lässt sich sehr wohl parallelisieren.
a10 starte Thread: b
a20 wenn button gedrückt: geheZu a40
a30 geheZu a20
a40 stoppe thread: b
a50 popup _zahl aus b
b10 wenn wieder 1000ms vergangen: geheZu b30
b20 geheZu b10
b30 _zahl += 1
b40 geheZu b10
Der Nutzen scheint zunächst gering.
Mal angenommen:
- in Zeile 15 bzw. a25 würde eine funktion stehen, die den aktuellen Wert der _zahl auf dem Bildschirm anzeigt
- die Berechnung _zahl += 1 wäre sehr komplex.
dann würde bsp. 1 in Zeile 30 hängen bleiben, aber bsp. 2 regelmäßig den aktuellen Wert (Zwischenergebnis falls noch gerechnet wird) anzeigen.
anonsten schliess ich mich ganz und gar Sentionline007 an
erst 2012 soll USB3 integriert werden?
Larrabee kommt nicht für den Konsumer-Bereich?
TDP der CPU seit Jahren auf hohem Niveau, die Leistungssteigerung geht mit bleibender Verlustleistung überein?
Erinnert mich irgendwie an einen sterbenden Elefanten...
Ach die machen das schon, bin kein Physiker/Mathematiker.