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. ITEOS, Stuttgart
  2. Hays AG, Oststeinbek
  3. Hauk & Sasko Ingenieurgesellschaft GmbH, Stuttgart
  4. finanzen.de, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 99,00€ (Bestpreis!)
  2. (aktuell u. a. Sharkoon Shark Zone M51, Astro Gaming C40 TR Gamepad für 169,90€, QPAD MK-95...
  3. (u. a. Tropico 6 - El Prez Edition für 21,99€, Minecraft Xbox One für 5,99€ und Red Dead...
  4. (u. a. Asus VP278H für 125,00€, LG 27UD59-W für 209,00€ und HP Pavilion PC für 989,00€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Support-Ende von Windows 7: Für wen Linux eine Alternative zu Windows 10 ist
Support-Ende von Windows 7
Für wen Linux eine Alternative zu Windows 10 ist

Windows 7 erreicht sein Lebensende (End of Life) und wird von Microsoft künftig nicht mehr mit Updates versorgt. Lohnt sich ein Umstieg auf Linux statt auf Windows 10? Wir finden: in den meisten Fällen schon.
Von Martin Loschwitz

  1. Lutris EA verbannt offenbar Linux-Gamer aus Battlefield 5
  2. Linux-Rechner System 76 will eigene Laptops bauen
  3. Grafiktreiber Nvidia will weiter einheitliches Speicher-API für Linux

Shitrix: Das Citrix-Desaster
Shitrix
Das Citrix-Desaster

Eine Sicherheitslücke in Geräten der Firma Citrix zeigt in erschreckender Weise, wie schlecht es um die IT-Sicherheit in Behörden steht. Es fehlt an den absoluten Grundlagen.
Ein IMHO von Hanno Böck

  1. Perl-Injection Citrix-Geräte mit schwerer Sicherheitslücke und ohne Update

Open Power CPU: Open-Source-ISA als letzte Chance
Open Power CPU
Open-Source-ISA als letzte Chance

Die CPU-Architektur Power fristet derzeit ein Nischendasein, wird aber Open Source. Das könnte auch mit Blick auf RISC-V ein notwendiger Befreiungsschlag werden. Dafür muss aber einiges zusammenkommen und sehr viel passen.
Eine Analyse von Sebastian Grüner

  1. Open Source Monitoring-Lösung Sentry wechselt auf proprietäre Lizenz
  2. VPN Wireguard fliegt wegen Spendenaufruf aus Play Store
  3. Picolibc Neue C-Bibliothek für Embedded-Systeme vorgestellt

  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