nVidia geht auf Sendung

Laut osnews - NVIDIA Announces ARM CPU for Desktop, Server, HPC geht nVidia auf der CES 2011 auf Sendung. Nachdem nVidia bei Intel rausgeworfen wurde, blieb nur eines übrig, eine andere Architektur. Und so will nVidia den Markt nicht etwa mit den Fermi-Chips aufmischen, sondern von Servern über den Desktop den Schoss mit ARM-CPUs erobern.

Lustig, entgegen dem Vorgehen von Intel und AMD, die CPU um eine GPGPU-Einheit zu erweitern sieht nVidia, wenig überraschend, es viel einfacher einen ARM-CPU-Core auf das GPGPU-Die zu verpflanzen.

Auch sonst werden ARM-CPU Designs mit anderen Kontexten in Verbindung gebracht. nVidia sieht die CPUs mit ARM IP aber definitiv und unverrückbar im Bereich high performance. Womit dann klar nicht nur der Desktop in die Hände von nVidia fallen wird, und natürlich auch den Super-Computer-Bereich. Wir reden hier nicht über die Tegra Chips, die nVidia auch weiterführen wird, sondern um neue Chips die nVidia in strategischer Partnerschaft mit ARM entwickelt hat oder entwickelt werden wird.

Gespenstisch?

Real! Lesen Sie es hier: nVidia Pressroom - NVIDIA Announces "Project Denver" to Build Custom CPU Cores Based on ARM Architecture, Targeting Personal Computers to Supercomputers

Offen!

Auch Apple nutzt ARM-CPUs, nVidia Grafik-Lösungen. Und es gibt Gerüchte, das Apple gerne ARM-Chips in Mac Books einsetzen möchte. Dem steht natürlich der Anspruch von Apple entgegen, gerne auf das Chip-Design Einfluss zu nehmen, zu kontrollieren. Ist nVidia also der Messias, der zur benötigten Grafikleistung auch eine CPU mitliefert? Oder wird nVidia ein Wettbewerber?

Kommentare

Darstellungsoptionen

Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.

High Performance

Auch sonst werden ARM-CPU Designs mit anderen Kontexten in Verbindung gebracht. nVidia sieht die CPUs mit ARM IP aber definitiv und unverrückbar im Bereich high performance.

Da hab ich inzwischen meine Zweifel. Ich hab mein RGBench mal auf meinem Nokia N900 (600 MHz Cortex A8-CPU) laufen lassen:

273 Punkte!

Das sind etwa soviel wie ein Pentium II 266 MHz oder ein PPC 604 250 MHz. Es kann natürlich sein, dass der von Nokia gelieferte gcc crap ist oder zumindest die FPU nur schlecht ausnutzt. Im CoreMark von Spec sieht es ja etwas besser aus (knapp vor einem Atom, taktbereinigt, sofern ich mich an die Zahlen in der c't von vor ca 9 Monaten richtig erinnere). Aber selbst das sind keine HPC-Werte. Da gilt es Core i7 oder Power 7 zu schlagen oder wenigsten die BlueGene-CPUs (und dann entsprechende Netzwerkanschlüsse dazu).

Bis dann

R"udiger

Auslegung

Ich erwarte das nVidia die ARM-Cores mehr oder weniger zum Datenschieben verwendet, von Festplatte in den Speicher in den Cache zur GPGPU und zurück. Ein bisschen php und Web-Seiten rendern, SQL Abfragen herrichten, fertig. Mit den kleinen Kernen kann man auch viele davon auf ein Die bringen, ähnlich dem Rock-Konzept von SUN.

Die eigentliche HPC-Rechenleistung bringt doch der nVidia Fermi-Bereich auf dem Die, von dem ARM-Kern(en) gefüttert. Und der nimmt es locker mit Core i7, Power 7 und BlueGene-Cluster auf, wenn das Problem auf die Shader sinnvoll abbildbar ist. Hat der Chef von nVidia nicht klar gemacht, das Fermi das GPGPU-Design und HPC-Design schlechthin ist? Ich kann mir nicht vorstellen, das nVidia Fermi auf gibt, um Lizenzen für CPU-Leistung an ARM zu bezahlen.

Fermi vs. BlueGene/Q CPU

Das Maß der Dinge bei Flops/Watt ist zur Zeit IBMs neuer Prozessor für BlueGene/Q. Das Ding ist um Faktor zwei besser als nVidias Fermi Plattform. Und dafür kann man ganz gewöhnlichen Hybridcode für MPI+OpenMP verwenden.

Was nutzt es?

Mit meiner alten, entstaubten Radeon HD3870 löse ich bei dem boinc Projekt milkyway Berechnung in einem 10-tel der Zeit der CPU. Schön, dass IBMs BlueGene/Q effektiver und effizienter ist. Aber ich werde in einen normalen Rechner leider keinen BlueGene/Q Prozessor haben, weil IBM kein Interesse daran hat diesen als Massenprodukt in den Handel zu bringen.

Während Fermis und ATIs sowieso gerne verbaut werden.

BlueGene/Q ist leider ein Produkt für den Elfenbein-Turm der Wissenschaft.

BlueGene CPUs sind abgewandelte PPC 4xx CPUs

Daher ist die Wahrscheinlichkeit, daß man solche CPUs auch kaufen kann sogar relativ hoch. Man wird abwarten müssen, wie sich die Geschichte weiterentwickelt. Dieser 17 Core Chip verbraucht sehr wenig Strom und kann sehr viel einfacher als eine GPGPU-Karte programmiert werden. Man wird auf ihm auch ganz profane Enterprise Software abarbeiten können.

Eben was nützt es.

Was nützt einem eine GPGPU?
Oft ziemlich wenig. Sie steckt nämlich noch mehr in dem Dilemma, dass auch SIMD-nutzende Anwendungen eher dünn gesäht hat. Und bei GPGPU ist das Problem noch schlimmer.
Nicht nur 2,4,8 oder 16 Werte gleichzeitig (je nach Datentyp) sondernein vielfaches davon (je nach GPU).

Vor allem Verzweigungen sind wohl Gift für die GPUs. Gut sehen GPU immer aus, wenn sich die Aufgabe auf Lineare Algebra zurückführen lässt. Das gilt für viele aber bei weitem nicht alle wissenschaftlichen Anwendungen. Und beim Consumer erst recht. Neben echtzeit 3D-Darstellung fallen mir nur Bildverarbeitung und Video-En- und DeCoding ein.

BTW: Auf dem dem SourceTalk im September in Göttingen hab ich den HPC-"Track" besucht. Dort war davon die Reden, das bereits heute 20-30% aller Desktop- und Server-CPUs im HPC-Bereich (öffentlich und in Firmen) verbaut werden, Tendenz steigend. Für ca 2015 wurden 50% erwartet! Dieser Elfenbeinturm ist ziemlich fett und lukrativ.

In sofern ist für die meisten Anwender der GPU-Hype wohl nicht mehr als eben ein Hype der vorübergeht. Aber - um auf den Ausgangsbereicht zurückzukommen - Nvidia dürfte ein Interesse an schnellen (im Desktop-Maßstab) ARM-CPUs haben, und dürfte daher dort die Entwicklung forcieren.
Das dürfte dann in der Tat eine Bedrohung fü]r den PPC im Embedded-Bereich werden, da der Hochleistungs-Embebbed-Bereich ja bisher die PPC-Domäne zu sein schien.

Bis dann

R"udiger

Nachteile von GPGPUs

In der Festkörperphysik kann man die GPGPUs gut auslasten, allerdings hat man da ein ganz anderes Problem: der Arbeitsspeicher ist winzig! Selbst die teuersten Karten haben nur 6GB RAM, das ist wahrlich nicht viel.

Dazu kommt, daß es bisher keine LAPACK für eine GPGPU gibt. nVidia liefert wenigstens BLAS und eine brauchbare FFT mit, AMD gibt't faktisch gar nichts außer einem C Compiler.

Nachteile von GPGPUs

Aber ich denke, bei einer Monte-Carlo-Simulation mit Metropolis wird es schon schwierig oder bei einer Molekulardynamiksimualtion mit cutoff-Radius. Alles dinge die mit einem 'if' laufen. Und ohne die if steigt die Rechenzeit ins unermessliche. Und im Bereich KI gibt es noch mehr solcher Algorithmen. Alles auch sehr Rechenzeitintensive Geschichten.

Bis dann

R"udiger

GPGPUs

Ich dachte auch mehr an density functional theory. Andere Verfahren mit entsprechend großen Matrizen dürften auch sinnvoll auf GPGPU-Karten laufen. Bei der DFT ist aber der Arbeitsspeicher relativ schnell ein Problem.

GPGPU-Hype

Hallo,

Ich habe das Gefühl, dass es momentan ein ziemlichen Hype um die GPGPUs gibt. Jeder erwartet das sein Desktop durch GPGPU sagenhaft schnell würde und dort riesige Performancesprünge zu erwarten wären. Die sagenhafte Peak-Performance von GPGPUs scheint dies ja auch zu bestätigen. Sie liegt in der Tat um ein vielfaches höher, als die Werte typischer CPUs.

Was aber vielfach übersehen wird, ist, dass diese Leistung sich nur in speziellen Anwendungsfällen abrufen lässt, nämlich bei allem, was nahezu ausschließlich mit Matrizen und Vektoren (im mathematischen Sinn) zu tun hat. Alles andere wird kaum davon profitieren. Und das ist nicht eine Frage von schlechten Programmierern oder Algorithmen, sondern liegt im SIMD-Prinzip, das eben nur bei bestimmten Aufgabenstellungen hilfreich ist.

Deshalb ist es immer wichtig, neben einer guten GPGPU eine gute normale CPU zu haben. Und deshalb wird Nvidia, wenn sie mitihren Tegras auf den Desktop und ins HPC-Segment wollen, eine hochleistungs-ARM-Kern bauen müssen. Das schnellst was RAM im MOment zu bieten hat sind die COrtex A9 und konkurieren mit Intel-Atom-CPUs und nciht mit Core i7 oder gar Power7.

Bis dann

R"udiger

GPGPGU ist kein Hype

Nur ist GPGPU eher ein Nachfolger der alten Vektorrechner und ist somit nichts für die normalen Desktopanwendungen. Bei solchen Anwendungen reden wir auch nicht nicht mehr von Peak-Performance, die Dinger sind wirklich sehr schnell. Allerdings muß man wissen was man da treibt und die Probleme müssen dazu passen.

Ein ganz anderes Thema ist ARM als Desktop Ersatz, ARM ist einfach nur langsam. Insbesondere das für den HPC Bereich zu verwenden ist ein schlechter Scherz. Wenn man die Preise von nVidia sieht, dann kann man auch zu IBMs BlueGeneQ greifen, das ist auch nicht mehr wesentlich teurer. Bisher hat ARM ähnlich wie IA32 nur wenige Register es fehlt die 64Bit Erweiterung. Der natürliche Schritt wäre es die Architektur zu wechseln und nicht auf ARM zu setzen. Aber die Geschichte zeigt, daß die Kunden lieber Frickellösungen wollen.

OK, GPGPU ist ein Desktop-Hype

Hallo,

Im HPC-Bereich stimem ich dir zu. Und genauso wie damals Vektorrechner kein Allheimittel waren, aber vielfach sehr nützlich, ist es auch nun mit den GPGPUs.

Aber im Desktopbereich wird momentan ein ziemlicher Hype um GPGPU gemacht, siehe Nvidia Pläne mit einer leistungsstarken GPGPU+ARM-Kern als Desktop-Konkurenz. Und dort ist es IMHO wirklich nicht viel mehr als ein Hype.

Der Hype ist wohl eher dem geschuldet, dass Nvidia die Felle davon schwimmen. Wer braucht schon noch eine leistungsfähige GraKa, wenn die der on-CPU-Grafikprozessor für 95% aller Anwendungen (inkl. vieler Spiele) ausreicht. ATI hat sich in die ARme von AMD gerettet, aber Nvidia könnte ein Problem bekommen und in Nischen verdrängt werden (Hardcore-Gamer und HPC-"Vektor"-Anwender). Wobei Matrox zeigt das man auch in Nischen ganz gut leben kann.

Bis dann

R"udiger

Hype oder Ausdruck von unterschwelliger Enttäuschung

Vielleicht ist der GPGPU-Hype beim Desktop einfach nur Ausdruck einte nteschwelligen Enttäuschung. Man merkt, dass es bei den CPUs nicht weitergeht. Man merkt, dass auf dem Smartphone Dinge flüssig laufen, die auf dem Notebook mit angeblich viel schnelleren CPUs ruckeln. Also sucht man nach einem Strohhalm und der heißt, nachdem der Strohhalm Multicore schon zerbrochen ist, derzeit GPGPU.
Wirklich helfen könnten eher CPUs, die nicht nur in Benchmarks schnell sind, sondern im echten Leben eine gute Performance liefern.

Die Ursache für langsame Applikationen ist nicht die Hardware

Leider hat es sich eingebürgert Programmiersprachen zu nutzen, die sehr viele Dinge dynamisch machen. Dynamisch ist zwar schon flexibel aber auch einfach nur langsam, da gibt es nichts zu beschönigen. Leider wird diese Tatsache geleugnet und durch viel Marketing Blabla überdeckt, so daß viele diesen Unfug auch noch glauben. So kommt es, daß neue Computersoftware die neue Hardware mit im Grunde überflüssigen Overhead zukleistern und die Systeme langsam erscheinen, was sie in Realiter nicht sind.

Es fehlen auch die Programmiersprachen mit diesem Phänomen sinnvoll umzugehen. Auf der einen Seite gibt es zwar effektive Programmiersprachen: Ada, C, C++, Fortran, ... diese bieten aber nur unzureichende Unterstützung für moderne Paradigmen (Reflection etc.). Sprachen wie C#, Java, Smalltalk, Python, Ruby, ... hingegen verwenden immer langsame Mechanismen, selbst wenn dies nicht notwendig ist. Hinzukommt, daß Bytecode nie so effektiv abgearbeitet wird wie echter Maschinencode. Man darf sich hierbei nicht von der Erfolgen von speziellen VMs auf der x86 Plattform blenden lassen, denn diese wird selbst nur "emuliert" und nicht nativ abgearbeitet. Auf reinen RISC Plattformen sind die VMs nicht so schnell wie echter Maschinencode.

Kraut und Rüben

Eigentlich fing das Problem mit den Shared Libs an. Tolle Idee. Nur wieso bringt jedes Programm seinen eigenen Shared Libs mit?

Mit dem Entwicklungswerkzeugen, billigen Speichern und leistungsfähigen Systemen muss niemand mehr die Hardware, deren Grenzen und die Möglichkeiten in Betracht ziehen. Schauen, was es gibt. Man macht eben alles selbst. Zumindest in der Non-Unix-Welt.

Und jeder mit einer inkompatiblen Version eines Entwicklungswerkzeugs, dass wiederum eine komplette Umgebung installiert.

Ich hab es nicht nur einmal erlebt, das ein Druckertreiber mit mehreren hundert Kilobyte einen .net-Installer mit mehreren hundert Megabyte benötigt. Nur weil der Hersteller es dem Endkunden leichter machen wollte, als es mit den Systemfunktionen des OS geht. Oder weil es billiger ist, einen Hunder-Megabyte Installer zu erstellen, als eine Beschreibung für die OS-Systemfunktion? Hundert-Megabyte? Klar, du musst ja die GUI und die Hilfe-Texte in hunderten von Sprachen mit verpacken und die teuren Grafiken dürfen auch nicht fehlen.

Bei den Freiheiten, die Programmierer haben, darf man sich nicht wundern, wenn die auch im vollen ausgenutzt wird.

Ansonsten benötigen wir einen Code-Steuer pro Kilobyte für Programme. Was glaubst du, wie irre schnell die Programme kleiner werden würden und sich jeder mehrfach umschauen würde, ob eine Funktion nicht doch bereits in einer Lib vorhanden ist.

Nein, das ist Traum, das wird nicht passieren. Wir werden Installer mit hunderten von Megabyte bekommen, die einen Isntaller installieren, der den Treiber für das System aus sucht und installiert und all die Kontroll- und Rootkit-Programme und das DRM Geraffel mit verbaut.

Wer hat das sagen>

Hallo,

Bei den Freiheiten, die Programmierer haben, darf man sich nicht wundern, wenn die auch im vollen ausgenutzt wird.

Sind das wirklich die Entwickler, die hier das verbocken, oder sind es die Marketingabteilungen und die Produktplaner, die eine Zeitdruck aufbauen, in dem amn die Lösungen nur schnell hinschludern kann?

Gut durchdachte Entwicklung kostet Zeit! Zeit, in der die Entwickler (aber auch das Management !!!) bezahlt werden wollen und noch kein neues Produkt auf dem Markt ist. Also wird die Zeit in optimierte Programme nur da investiert, wo es ohne nicht geht. Bei bei Treibern für einen 50 Euro Tintenstrahldrucker reicht die Zeit eben kaum weiter als zum Zusammenklicken aus ein paar allg. Buildingblocks.

Zum Thema shared-libs: Das scheint wenigstens unter UNIX-Systemen einigermassen gut zu funktionieren, insbsondere bei Linux, oder kennst du dort einen Zoo von quasi identischen libs pro Programm?

Bis dann

R"udiger

Beispiel Mac OS X

Es sind sicherlich firmenpolitische Entscheidungen, die die Größe von Programmpaketen bestimmen.
Mac OS X wurde von Version zu Version immer schneller. Bis zum Wechsel zu Intel und damit verbunden der defakto-Einstellung der Entwicklung des Macs. Seit dem wird Mac OS X von Version zu Version langsamer, ohne erwähnenswerte Verbesserungen und die Dateigrößen schwellen immer weiter an.
Die Größe der 10.6.x-Updates, die nur Bugfixes enthalten ist mittlerweile auf 600 - 700 MB angeschwollen, das 10.6.5 Comboupdate, welches alle vorherigen Updates enthält, ist über 1 GB groß.
Zum Vergleich, die Dateigröße der für 10.4.x-Updates lag für PowerPC immer deutlich unter 100 MB. Selbst die Updates für Intel, obwohl sie immer in etwa doppelt so groß waren, wie die PPC-Updates, lagen nur etwas über 100 MB. Das Comboupdate von 10.4.11 ist für PowerPC 180 MB groß und für Intel 323 MB.

Full ACK

Hallo,

Ich wundere mich auch immer, wieso Leute behaupten, Java, oder C# Code wäre so schnell, wie native übersetzter (z.B.) C-Code. Dito bzgl. llvm. Ich habe vor einiger Zeit das mal überprüfen wollen und mein Benchmark (nach viel Mühe den llvm zum Laufen zu bekommen) durchgeführt. Ergbenis: +50% (IIRC) Rechenzeit!. "Aber das sei ja genauso schnell" ;-)

Im Übrigen, ich finde das selbst C++ oft langsamer ist als reiner C-Code, weil all die ganze Konstruktoren und Destruktoren mit abgearbeitet werden müssen. Aber der Unterschied ist nicht ganz so groß (als ich zuletzt gemessen haben waren es IIRC ca 10%).

Aber letztlich kennt man das seit Jahren. Ich erinnere mich noch an Sequenzer-Programme (Cubase und Konsorten) die liefen auf einem Atari ST mit 8 MHz und lahmen Speicher genauso schnell wie auf einem 386er PC mit 33 MHz und modernerer Architektur. Aber beim Atari hatte man gelernt die CPU optimal auszunutzen, beim PC wurden einfach alle High-Level-APIs genutzt ohne Gedanken an die Performance.

Bis dann

R"udiger

LLVM vs. GCC

Also eigentlich heißt es nicht LLVM sei genauso schnell, sondern deutlich schneller:
"LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster. " http://developer.apple.com/technologies/tools/whats-new.html#llvm-compil...

Atari ST mit 8 MHz vs. 386er PC mit 33 MHz ist eines der vielen Beispiele für das vom mir beschriebene Phänomen, dass x86-Hardware eben nur in Benchmarks schnelle Ergebnisse liefert, im echten Leben aber keinen Performance-Vorsprung bietet, sondern im Gegenteil im Vergleich eher durch Trägheit auffällt. Da hat sich über die Jahre nichts geändert.

Nächste Enttäuschung programmiert?

Hallo,

Wenn dem so sein sollte, dann ist die nächste Enttäuschung aber programmiert. Denn Smartphones und Co sind bei Videos nicht wegen ihrer CPU ruckelfrei (obwohl es auch dort mitunter Klagen gibt). sondern wegen ihrer spezialisierten Decodereinheiten, wie sie sich auch in modernen GPUs finden. Nur sind diese Einheiten nicht Teil dessen, was unter GPGPU läuft, sondern spezielle Schaltung, die nix anderes können.
\Wobei es wohl auch gute GPGPU-Implementierungen der Codecs gibt. Dann ziehen aber die GPU auch wieder mehr Strom, ergo auch nicht optimal.

Der Punky ist doch Smartphone und Co sind spezialisierte Geräte, die bestimmte Aufgaben erfüllen sollen, nämlich Officeaufgaben und "Heim-Multimedia". Ein PC ist per definitionem eine Universalmaschine, die alles abdecken soll, vom Internet-PC, über Office-PCs und SAP-Terminals , die heimischem Multimedia Station , bis hin zum High-End-Gamer und NumberCrunching. Diese Universalität geht dann aber auf Kosten der Effizienz bei speziellen Aufgaben.

Vielleicht läutet sich hier das Ende des PCs ein und es wird in Zukunft mehr spezialisierte Geräte geben, insbesondere für den privaten Konsumenten. Und Office ziehen Net-Tops und zentrale Server ein. Bleiben nur die High-End-Gamer und NumberCruncher übrig.
Aber GPGPU wird m.E. diese Entwicklung nicht stoppen können, dazu ist diese zu unflexibel.

Bis dann

R"udiger

Schweinezyklus

Die Rufe, dass die Mainframes tot sind, gibt es schon lange. IBM verdient damit ein gutes Geld.

Es war immer ein Wechselspiel, mal holten die PCs auf und die Mainframes schienen am Ende, dann legt IBM nach und die Mainframes bieten Dinge, die man schon immer haben wollte. Die kommen dann langsam auf die PCs und dei Mainframes werden uninteressant, ... und so weiter.

So ähnlich wird es auch beim Desktop und dem Laptop gehen. Ich bin der Meinung das die Zeit der Laptops vorbei ist. Im Zug arbeitet keiner, die schauen sich Filme an und hören Musik. Die Pads werden kommen. Wer nicht komplett auf die Cloud setzt, auch der Hype wird mal vorüber gehen, hat einen "Desktop" zuhause. Und ganz ohne Rechenleistung kommen nur die Normal-Verbraucher aus.

Videoschnitt, Fotographie oder andere Hobbies werden Leistung rechtfertigen. Ob die aus einer "reinen" CPU kommt oder einer APU, denn die GPGPU wird Bestandteil des CPU-Cores werden, ist egal.

Hier ist auch die Frage, ob ByteCode nun schneller ist, irrelevant. Wenn man es ernst meint, mit optimierung auf die APU, dann müßt ihr zugeben, das ByteCode auf einem Mehrprozessorsystem bestenfalls nicht die ganze Performance bietet (muss ja On-The-Fly übersetzen) und eine gewissen Latenz benötigt. Latenz kann Problemlösungen verhindern, ist mir klar. Aber im Allgemeinen sollten die Nachteile von ByteCode die Vorteile keinesfalls verhindern. Transportabler Code.

Euer Wunsch, performanter C-Code, funktioniert letztendlich nur bei Source-GNU/Linux Distributionen. Die werden bei Endnutzern auf wenig Verständnis und Verlangen stossen.

Ich seh es nicht so eng, die Nachfrage wird den Markt schon regeln. Es ist doch erstaunlich, das die Nachfrage nach Stromsparenden CPUs ausgerechnet ARM gegen Intel nach oben gespühlt hat. Wer hätte jemals gedacht, das die ARM CPUs einmal Intel das fürchten lehren? Und nun kommt nVidia und sagt: ARM? Passt scho!

ARM hat gezeigt, das Berechnungen auch mit sehr wenig Abwärme funktioniert. Und nachdem das klar war, muss nun nicht nur Intel und AMD nachziehen, die Effizienz wird auch bei den Grafikkarten nicht halt machen. Bis vor kurzem galt bei nVidia noch: Leistung Leistung Leistung, egal wie laut der Lüfter dreht. Aber die lernen schnell.

Vor allem aber die Verbraucher ;-)

Anwendungsfälle.

Hallo,

Bzgl Byte-Code hast du natürlich insofern recht, als es immer auf den Anwendungsfall ankommt. Wenn unmittelbare Performance keine Rolle spielt, ist Bytecode in aller Regel gut genug. Genauso wie C-Code in alelr Regel gut genug ist Assembler zu verdrängen.

Umgekehrt gibt es aber immer noch Anwenungsfälle in denen Assembler oder zumindest intrinsic von nöten sind. Da ist Bytecode weit von entfernt. Ich habe in den letzten Jahren für eine meiner (leider bei meinem letzten Arbeitgeber gebliebenen) Bibliothek mit Intrinsics programmiert und fast einen Faktor 4 gewonnen! Das hat ganz andere Untersuchungen ermöglicht. Codecs zur Festplattenverschlüsselung wurden lange Zeit (vllt sogar noch heute) in Assembler geschrieben (zumindest für die "wichtigste" Plattform x86). IIRC sind teile von Gromacs (Molekulardynamik-Packet) ebenso geschrieben,um optimale Performance zu erreichen.

Kurz: Bei interaktiven Anwendungen, wo sich die Unterschiede zwischen Bytecode und nativem Code in Bruchteile von Sekunden ausdrücken, hat Byteocde klare Vorteile. Wenn man sich aber Richtung Minuten oder Stunden pro Aktion bewegt, dann dürfte ByteCode immer das nachsehen haben.

Bis dann

R"udiger

Paradigmen-Wechsel

Mit den Smartphones werden die Handies ja wieder größer. Offensichtlich wurde da ein Formfaktor gefunden, der tragbar ist und nutzbar ist. Ob sich da noch ein Brieftaschen-Format (17cm aka 7 Zoll) kommt? Mal sehen. Ansonsten besetzen die Paddles das Zeitungsformat im Haus. Egal ob Tageszeitung, Magazin oder Programmzeitschrift.

Für all diese Formen gilt, das der Platz dafür schon da war und das andere Medien, Papier, damit ersetzt wird (Filo, Notizbuch, Zeitung, ...).

So gesehen sind das spezialisierte Gadgets. Was man aber nicht vergessen sollte, im Prinzip steckt in ihnen ein vollständiger Computer. Und die Versuchung wird kommen, den Wettbewerber durch mehr Fähigkeiten zu übertreffen.

Mal sehen was rauskommt.

Hype oder Zukunft?

Richtig ist, die Gamer-GPUs werden nicht in Büro-Desktops verbaut und bei Laptops herrscht im Moment Ebbe, was leistungsstarke Grafik betrifft. Die APUs, kombinierte CPU & GPGPUs auf einem Die, stecken noch in den Kinderschuhen. Ich erwarte, dass es demnächst die Wahlmöglichkeit gibt, zwischen sehr guter GPU und mäßiger CPU-Leistung gibt, oder viel CPU und mäßiger GPU-Leistung. Aber da ist es noch ein weiter weg hin.

Bis dahin benötigt man für eine Vielzahl guter Spiele, wenn man nicht mit Klötzchengrafik vorlieb nehmen will, leistungsstarke PCIe Grafikkarten. Vor allem auch, weil die Zeit von 1200x1024 vorbei ist. Full-HD ist auch bei Spielen angesagt und verlangt nach mehr Leistung.

Es geht nicht um die Hardcore-Gamer, die mehr in die Grafik als den Rest investieren. Es geht doch schon bei den Gelegenheitsspielern los, die 100 Euro für eine Grafikkarte ausgeben. Und die können auch rechnen.

Die GPGPU ist unter Umständen also bereits vorhanden. Die wenigsten Leute nutzen die Mathe in der FPU und doch ist die Einheit heute bei jeder CPU dabei. Weil es einfacher ist das mit auf dem Die auszuliefern anstatt einen extra Sockel zu Verbraten (Mathe Co-Prozessor). Auch wenn es nur "Spezialanwendungen" sind, die werden unfassbar schnell erledigt. Apple scheint ja geradezu fixiert auf 96 Shadereinheiten der Geforce GT320m. Offensichtlich kann man eine gewissen Anzahl von GPGPU-Einheiten durchaus brauchen. Der Cell war ja letztendlich auch nichts anderes. Eine CPU und einige andere Cores dazu, die bestimmte Sachen schnell rechnen können.

Ich hoffe, das sich OpenCL und Anhang als Standard für diese APU-Bestandteile etabliert, und man so Hersteller-Übergreifend die Leistung nutzen kann.

Ich fürchte nicht, sondern hoffe, das die Idee, alles mit x86 zu erledigen, passé ist. Wenn es parallel geht, für GPGPU geeignet ist, bitte nicht in x86 coden. Ob und wann das automatisch geht, ist eine andere Frage. Ich gehe davon aus, das OpenCL morgen ebenso selbstverständlich wird, wie SSE, Crypto-Erweiterungen und TCP/IP Einheiten.

HPC und GPGPU

Hallo,

GPGPUs sind vor allem dann schnell, wenn sich die Fragestellungen auf lineare Algebra abbilden lassen. Das trifft für eine große Menge der HPC Anwendungen zu (und daher nimmt auch die top500 das LinPack-Benchmark), aber auf viele auch eben nicht.

Ich war September auf dem HPC-"Track" des SourceTalks hier in Göttingen. Dort war man etwas ernüchtert, was die HPC-Tauglichkeit der GPGPUs angeht. Und das obwohl dort vor allem Probleme behandelt wurden, die sich überwiegend auf lineare Algebar abbilden ließen.

Im Übrigen, was soll der Nvidia-Chef schon sagen, anderes sagen, als das Fermi, das HPC-Design schlechthin wäre. Er hat ja keine Alternativen zu bieten. ;-) Und da LinPack nach wie vor die als die Referenzbenchmark im HPC-Bereich dient, bestätigt ihn das natürlich. Interessant wäre aber mal auch ein SpecsMarks (CINT2006 und CFPU2006) auf Fermi zu sehen. Mir sind da keine Zahlen bekannt. Und ich fürchte der Wert wäre wesentlich weniger beeindruckend als bei LinPack.

Im Übrigen die top500-Rechner mit GPGPU haben immer auch einen leistungsfähigen CPU-Cluster an der Seite!

Ergo als HPC-Plattform ist ARM IMHO im Moment ungeeignet. UND Mit GPGPU kann man nicht alles im HPC-Bereich tun.

Bis dann

R"udiger

Hmm...

Ob das die Antwort auf die Frage ist, welcher ominöse OEM im mobilen Bereich gemeint war, der 2008 eine Architekturlizenz bei ARM Ltd gekauft hat?

Mobile OEM?

Laut wikipedia stellte nVidia den Tegra im Februar 2008 vor. Da sah sich nVidia bereits mit zahllosen Ankündigungen für Mobile Geräte als Hauptmacht und Gewinner. Gut möglich, das ARM und nVidia zu dem Zeitpunkt davon ausgegangen sind, das die Lizenz an einen gewichtigen Mobil OEM Fertiger geht. Zeitlich würde es passen.

Auch, dass das einzig nennenswerte Tegra (1) Gerät Microsofts Zune war. Verfolgt man den Faden weiter, würde das heissen, das Microsoft somit mindestens seit 2008 mit nVidia Zusammen an Windows für ARM bastelt.

Es gibt ja viele Firmen die inzwischen ARM-Design in Server bringen wollen, Cisco Ableger und andere. Jetzt ist klar, das wohl schon einige von Microsofts Schritt geahnt hatten. Jetzt macht es Sinn.

Anstatt mit x86-everywhere will Microsoft wohl lieber Windows-everywhere. Und das Verhltnis zwischen Intel und Microsoft war schon lange gespannt. Trotz alldem, man darf man sich nicht darauf verlassen, dass Microsoft sich nicht wieder auf Intels Seite schlägt, wenn Intel Zugeständnisse macht. Zum Beispiel die Linux Entwicklung einstellen?

Die Frage, die mich aber beschäftigt, und die bei dem ganzen Trubel bisher ungenannt blieb: Wie weit ist nVidia, ARM und Microsoft? Wenn man von Produkt-Zyklen von 4 bis 10 Jahren aus geht, dann gibt es die nvidia/ARM Destop & Server frühestens 2012. Oder 2018?

Und was macht Intel inzwischen? Ich kann mir beim besten Willen nicht vorstellen, das man ungerührt zu sieht. Mit den Many-Cores zeigte man zudem bereits die Bereitschaft eventuell auch auf x86 zu verzichten.

Und wie sieht es eigentlich jetzt mit der Idee aus, dass Apple ARM auf kauft?

Zeitplan

Nach dem, was ich bisher verstanden habe sieht der Zeitplan so aus, dass nVidia einen Tegra-2-Nachfloger auf Basis des Cortex A-15 anbieten wird und danach einen Tegra mit dem eigenen nVidia ARM-Kern aus dem gerade öffentlich gemachten Denver-Projekt.

Da laut ARM die ersten Prozessoren mit Cortex A-15 2012 erscheinen sollen, ist mit dem Denver-SoC also ab 2013 zu rechnen. Da Kern und SoC beide bei nVidia entwickelt werden und es so zum Teil eine parallele Entwicklung möglich ist, wäre auch vorstellbar, dass das Denver-SoC schon kurz mach den A-15 SoCs erscheint.

Intel hat nie die Bereitschaft gezeigt, eventuell auch auf x86 zu verzichten. Die ersten Many-Core-Prototypen mit 80 Kernen ohne x86-ISA sind als reines Forschungsobjekt entstanden. Knapp 2 Jahre später wurde dann ein x86 Many-Core gezeigt, der nur noch 48 Kerne besitzt, auf der vierfachen Die-Fläche.

Darstellungsoptionen

Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.