1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intel zeigt Larrabee (Update 2)

x86 vs MMP

  1. Thema

Neues Thema Ansicht wechseln


  1. x86 vs MMP

    Autor: Crass Spektakel 23.09.09 - 00:45

    Larrabe ist defacto ein PentiumMMX mit 2Ghz und 32 Kernen. So weit so gut, eine Standard-Architektur aufgeblasen auf Massive-Multi-Processing.

    x86 ist eine durchaus performante Architektur. Im CPU-Markt gibt es nur wenige Architekturen die da wirklich mithalten können und wenn überhaupt dann kommt selbst die gleiche Leistung sehr teuer. Allerdings sind absolute Leistung und Leistung pro Transistorcount zwei paar Stiefel.

    Der Overhead von x86 mag ein paar hundertausend Transistoren ausmachen und bei einem einzelnem Kern stört das nicht. Aber wenn man sich mit NVidia-Architektur (240 Kern) oder AMD (800 Kerne) anlegt dann werden aus "ein paar Hundertausend pro Kern" schnell "untragbare Riesenmengen". Sicherlich wird Larrabe pro Kern mehrfach schneller sein als ein NVidia-Kern oder ein AMD-Kern aber für das Zielfeld ist sowas irrelevant, da sind 800 ultraeinfache Kerne einfach schneller als 32 relativ komplexe Kerne.

    Wo Larrabe aber Sinn machen könnte: Als Server-CPU. Das meine ich toternst, sehr oft kann man sich um 64Bit herummogeln, viele Serverjobs skalieren sehr gut. Ein LAMP-Server mit einem Larrabe würde vermutlich die schnellsten i7-CPUs in den Schatten stellen und weil das Ding relativ normal zu programmieren ist dürfte auch recht schnell ein Unix portiert sein. Da sind NVidia und AMD stark im Nachteil. Trotzdem, solange nicht jeder PC einen 16Kern i7 mitbringt sind NVidia und AMD mit ihren GPUs absolut im Vorteil.

    Wenn Intel mit NVidia und AMD bei Massive-Multi-Processing gleichziehen will dann wird das mit einer überkomplexen x86-Architektur wohl kaum klappen. Vieleicht sollten sie mal ihre alten i860/960/ARM-Architekturen herauskramen, dann könnte das was werden, da gibts mehr Bang-per-Transistor.

  2. Re: x86 vs MMP

    Autor: default 23.09.09 - 00:49

    Naja, also programmieren wird man Larrabee sowieso mit speziell darauf ausgelegten Toolkits, die das Parallelisieren und Optimieren erleichtern. Wofür dann noch x86? Ich sehe da keinen Vorteil.

    Wie auch immer: Larrabee lässt viel zu lange auf sich warten und währenddessen schlafen AMD und NVidia natürlich nicht. Bis das Ding erscheint, haben die wahrscheinlich wieder eine neue Generation ihrer GPUs draußen. Gerade jetzt stellt AMD ja die neue 5xxx-Serie vor, wenn Larrabee erscheint, gibt's bestimmt 6xxx.
    Und mit jeder Generation werden die GPGPU-Fähigkeiten besser.

  3. Re: x86 vs MMP

    Autor: Ach 23.09.09 - 02:05

    Ich find den auch als Redering- oder gleich als Supercomputing Beschleuniger äußerst interessant. Dabei nicht unbedingt als Einzel-GPU, da dürfte nämlich ein schnelles Dualboard in spätestens einem 3/4 Jahr mit 2x8 realen und 2x8 virtuellen Kernen nicht weit entfernt, eventuell sogar darüber liegen. Aber als Karte(n) mit 2 oder mehr GPU´s darauf, da könnte man eine Ganze Menge Rechenpower in einem einzelnen PC Gehäuse bündeln.

    Zudem könnte ich mir gut vorstellen, dass der Larrabee einen effektiven idle Modus besitzen wird, bzw. ganz abgeschaltet würde wenn keine Aufgabe anstände. Schließlich ist er, im Gegensatz zur eigentlichen GPU und zur CPU, für den grundsätzlichen Betrieb eines Computers auch gar nicht nötig.

    Nvidia/Ati mögen die schnellere Hardware besitzen, aber in seiner Vielseitigkeit und in der Einfachheit/Zeitersparnis der Programierung, wird der Larrabee nicht zu schlagen sein.

  4. Re: x86 vs MMP

    Autor: Ach 23.09.09 - 03:08

    @default

    Was soll sich den bei der x86 Programmierung großartig ändern? Multitasking Anwendungen gibt es doch schon lang genug. Das ist ja gerade der Vorteil, das man das bereits Vorhandene effektiv weiternutzen kann.

    Neuartige "Toolkits" findest du wenn, dann bei den GPU Herstellern. Sie nennen sich bei Nvidia "Havok" und "Stream" bei Ati und machen die Weiterverwendung der von Graphikshadern Berechneten Daten in PC Anwendungen überhaupt erst möglich.

    Dass der Geschwindigkeitsvorteil einer GPU schlagartig dahin schmilzt, sobald die Berechnung nicht mehr genau vorhersagbar ist, oder sich eine anstehende(n) Aufgabe(n) nur noch auf einige wenige Shader der GPU verteilen lässt, können diese "Toolkits" aber genauso wenig verhindern, wie sie die Komplexität der Shader-Programmierung auf ein x86 Niveau senken könnten.

    Ist wohl eher ein Hardware- und weniger ein Softwareproblem.
    x86 CPU´s sind vielseitig auf kosten der Geschwindigkeit,
    GPU´s sind sau schnell auf kosten der Vielseitigkeit.

  5. Re: x86 vs MMP

    Autor: default 23.09.09 - 03:42

    Ach schrieb:

    > Neuartige "Toolkits" findest du wenn, dann bei den GPU Herstellern. Sie
    > nennen sich bei Nvidia "Havok" und "Stream" bei Ati und machen die
    > Weiterverwendung der von Graphikshadern Berechneten Daten in PC Anwendungen
    > überhaupt erst möglich.
    >

    Hmm, ich glaube du bringst hier etwas durcheinander. Havok ist eine Physik-Engine. ;) Meinst wohl CUDA?
    Diese (relativ) low-level-Schnittstellen meinte ich aber gar nicht mal speziell.

    >
    > Ist wohl eher ein Hardware- und weniger ein Softwareproblem.
    > x86 CPU´s sind vielseitig auf kosten der Geschwindigkeit,
    > GPU´s sind sau schnell auf kosten der Vielseitigkeit.

    Aber die x86er vom Larrabee sind doch stark vereinfacht, eben drum damit man viele auf ein Die packen kann. Und das, während GPU-Shaderprozessoren immer mehr können (siehe z.B. CUDA-Dokumentation). Ich behaupte einfach mal, die haben sich mittlerweile sehr aneinander angenähert.

  6. Re: x86 vs MMP

    Autor: Phil.42 23.09.09 - 10:32

    Crass Spektakel schrieb:
    --------------------------------------------------------------------------------
    > x86 ist eine durchaus performante Architektur. Im CPU-Markt gibt es nur
    > wenige Architekturen die da wirklich mithalten können und wenn überhaupt
    > dann kommt selbst die gleiche Leistung sehr teuer. Allerdings sind absolute
    > Leistung und Leistung pro Transistorcount zwei paar Stiefel.
    >

    Naja, die x86-Struktur ist veraltet und so langsam stößt sie an Grenzen. Ich hoffe, dass schon munter an einem Nachfolger geforscht wird! Also bei Intel und AMD und nicht nur bei IBM und so :D

    > Der Overhead von x86 mag ein paar hundertausend Transistoren ausmachen und
    > bei einem einzelnem Kern stört das nicht. Aber wenn man sich mit
    > NVidia-Architektur (240 Kern) oder AMD (800 Kerne) anlegt dann werden aus
    > "ein paar Hundertausend pro Kern" schnell "untragbare Riesenmengen".

    Hier hast du einen Fehler drin. Klassische GPUs sind mit CPUs nicht so wirklich zu vergleichen, da die Shaderunits deutlich schwächer sind und man defakto 5 Shaderunits braucht um normale Berechnungen (Addition, Multiplikation) durchführen zu können.
    Die GPUs haben also etwa 200-250 "Kerne" die aber jeweils dennoch deutlich kleiner und primitiver sind als wirkliche CPU-Kerne.
    Ähnliches schreibst du ja gleich, wollte es nur nochmal klarstellen, dass hier niemand zu einfache Schlüsse zieht :)

    > Sicherlich wird Larrabe pro Kern mehrfach schneller sein als ein
    > NVidia-Kern oder ein AMD-Kern aber für das Zielfeld ist sowas irrelevant,
    > da sind 800 ultraeinfache Kerne einfach schneller als 32 relativ komplexe
    > Kerne.
    >

    Tja, man sagte auch mal, dass Hardwarebeschleunigung immer schneller ist als Softwarerendering...Unreal hat uns erstmals das Gegenteil bewiesen.
    Die vielen primitiven Kerne sind für einige Aufgaben äußerst praktisch und sehr gut geeignet, das heißt aber nicht, dass sie in der gesamten Grafikberechnung den richtigen CPUs überlegen sind (Stichwort: Programmierung und Softwarerendering)

    > Wo Larrabe aber Sinn machen könnte: Als Server-CPU. Das meine ich toternst,
    > sehr oft kann man sich um 64Bit herummogeln, viele Serverjobs skalieren
    > sehr gut. Ein LAMP-Server mit einem Larrabe würde vermutlich die
    > schnellsten i7-CPUs in den Schatten stellen und weil das Ding relativ
    > normal zu programmieren ist dürfte auch recht schnell ein Unix portiert
    > sein. Da sind NVidia und AMD stark im Nachteil. Trotzdem, solange nicht
    > jeder PC einen 16Kern i7 mitbringt sind NVidia und AMD mit ihren GPUs
    > absolut im Vorteil.
    >
    > Wenn Intel mit NVidia und AMD bei Massive-Multi-Processing gleichziehen
    > will dann wird das mit einer überkomplexen x86-Architektur wohl kaum
    > klappen. Vieleicht sollten sie mal ihre alten i860/960/ARM-Architekturen
    > herauskramen, dann könnte das was werden, da gibts mehr
    > Bang-per-Transistor.

  7. Re: x86 vs MMP

    Autor: Ach 23.09.09 - 12:58

    > Meinst wohl CUDA?
    Jau, da hast du recht :).

    Wobei Havok selber keine Engine sondern tatsächlich eine Software ist. Siehe:
    http://de.wikipedia.org/wiki/Havok_%28Software%29
    Und auch darin, dass Intel an einem eigenen DSK arbeitet muss ich dir recht geben, allerdings ändert es nichts daran, dass GPU´s nicht viel mehr als leistungsstarke Co Prozessoren mit eigener Befehlssprache sind.

    > während GPU-Shaderprozessoren immer mehr können (siehe z.B. CUDA-Dokumentation).
    > Ich behaupte einfach mal, die haben sich mittlerweile sehr aneinander angenähert.

    Naja, und ich behaupte mal, dass sich GPU-Shaderprozessoren nur im Bereich der Graphik/Physik Berechnung erheblich weiterentwickelt haben, und es nach wie vor mit viel Aufwand und vielen Einschränkungen verbunden ist, ihre Leistung in x86 Programme sinnvoll zum Einsatz kommen zu lassen. Als Numbercrasher halt :). Das war´s dann aber auch schon.

  8. Re: x86 vs MMP

    Autor: ultrapaine 23.09.09 - 15:30

    >Naja, die x86-Struktur ist veraltet und so langsam stößt sie an >Grenzen. Ich hoffe, dass schon munter an einem Nachfolger >geforscht wird! Also bei Intel und AMD und nicht nur bei IBM und so :D

    Ich weiß nicht ob ich das Prinzip richtig verstanden habe, aber bei aktuellen CPUs von Intel/AMD ist doch nur der Microcode x86.
    Bis auf dem etwas aufwändigeren Befehlsdecoder ist doch eine x86 CPU nix anderes als eine normale RISC CPU, von daher würde es doch reichen, wenn man den Microcode anpasst, und den Softwareherstellern mal ein wenig auf die Füße tritt, ähnlich wie beim BIOS und EFI.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. HUK-COBURG Versicherungsgruppe, Coburg
  2. operational services GmbH & Co. KG, Berlin, Frankfurt am Main, Braunschweig
  3. Hays AG, Oststeinbek
  4. Freie und Hansestadt Hamburg, Behörde für Stadtentwicklung und Wohnen, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Ghost Recon Breakpoint für 24,00€, Anno 1800 Gold Edition für 42,75€, Assassin's Creed...
  2. 9,00€ (Standard)/15,00€ (Gold)/18,00€ (Ultimate)
  3. 38,99€
  4. (u. a. BenQ 24,5 Zoll Monitor für 99,00€, Sharkoon PureWriter Tastatur 59,90€, Lenovo IdeaPad...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programmieren lernen: Informatik-Apps für Kinder sind oft zu komplex
Programmieren lernen
Informatik-Apps für Kinder sind oft zu komplex

Der Informatikunterricht an deutschen Schulen ist in vielen Bereichen mangelhaft. Apps versprechen, Kinder beim Spielen einfach an das Thema heranzuführen. Das können sie aber bislang kaum einhalten.
Von Tarek Barkouni

  1. Kano-PC Kano und Microsoft bringen Lern-Tablet mit Windows 10

Amazon, Netflix und Sky: Disney bringt 2020 den großen Umbruch beim Videostreaming
Amazon, Netflix und Sky
Disney bringt 2020 den großen Umbruch beim Videostreaming

In diesem Jahr wird sich der Video-Streaming-Markt in Deutschland stark verändern. Der Start von Disney+ setzt Netflix, Amazon und Sky gehörig unter Druck. Die ganz großen Umwälzungen geschehen vorerst aber woanders.
Eine Analyse von Ingo Pakalski

  1. Peacock NBC Universal setzt gegen Netflix auf Gratis-Streaming
  2. Joyn Plus+ Probleme bei der Kündigung
  3. Android TV Magenta-TV-Stick mit USB-Anschluss vergünstigt erhältlich

Mr. Robot rezensiert: Domo Arigato, Mr. Robot!
Mr. Robot rezensiert
Domo Arigato, Mr. Robot!

Wie im Achtziger-Klassiker Mr. Roboto von Styx hat auch Elliot in Mr. Robot Geheimnisse. Die Dramaserie um den Hacker ist nicht nur wegen Rami Malek grandios. Sie hat einen ganz eigenen beeindruckenden visuellen Stil und zeigt Hacking, wie es wirklich ist. Wir blicken nach dem Serienfinale zurück.
Eine Rezension von Oliver Nickel und Moritz Tremmel

  1. Openideo-Wettbewerb Die fünf besten Hacker-Symbolbilder sind ausgewählt
  2. Cyberangriffe Attribution ist wie ein Indizienprozess
  3. Double Dragon APT41 soll für Staat und eigenen Geldbeutel hacken

  1. Vodafone: Kabelfernsehkunden sterben in Zukunft aus
    Vodafone
    Kabelfernsehkunden sterben in Zukunft aus

    Vodafone sieht bei jungen Menschen wenig Interesse, Kabelfernsehen zu abonnieren. Ein deutscher Netflix-Manager sprach über den Streaminganbieter.

  2. FBI-Wunsch: Apple verzichtete auf iCloud-Verschlüsselung
    FBI-Wunsch
    Apple verzichtete auf iCloud-Verschlüsselung

    Apple war einer Bitte des FBI laut der Nachrichtenagentur Reuters nachgekommen und verzichtete auf die Einführung verschlüsselter iPhone-Backups in der iCloud. Apple habe einem Streit mit Beamten aus dem Weg gehen wollen, erklärte eine Reuters-Quelle - geholfen hat es indes nicht.

  3. Rainbow Six Siege: Ubisoft verklagt DDoS-Anbieter
    Rainbow Six Siege
    Ubisoft verklagt DDoS-Anbieter

    Seit Monaten gibt es DDOS-Angriffe gegen Rainbow Six Siege, nun klagt Ubisoft gegen einen Anbieter. Der offeriert das Lahmlegen der Server ab 150 Euro, offenbar stecken auch Deutsche hinter den Attacken.


  1. 19:21

  2. 18:24

  3. 17:16

  4. 17:01

  5. 16:47

  6. 16:33

  7. 15:24

  8. 15:09