Archiv verlassen und diese Seite im Standarddesign anzeigen : SC09: IBM lässt Cell-Prozessor auslaufen - Heise
Heise - SC09: IBM lässt Cell-Prozessor auslaufen (http://www.heise.de/newsticker/meldung/SC09-IBM-laesst-Cell-Prozessor-auslaufen-864497.html)
Wenn man bedenkt, was für ein Hype um dieses Teil gemacht wurden, wieviel Vorschußlorbeeren es bekommen hat, ist es doch erschreckend, wie wenig dann davon übrig bleibt. Somit wird der Cell sich wohl nur im HighEnd-Computing wiederfinden, für den privaten Sektor wird wohl außer PS3 nichts mehr bleiben.
wird wohl die PS4 keinen cell mehr haben
san.salvador
2009-11-19, 19:00:32
wird wohl die PS4 keinen cell mehr haben
Die lassen sich sicher wieder ein völlig krankes System einfallen, um den Devs auf den Wecker zu gehen.
Vielleicht ein Cluster aus 180 dedizierten Soundprozessoren, die alle per wlan kommunizieren? Statt RAM eine interne Bluray-RW?
Sie finden sicher was lustiges. :D
Nightspider
2009-11-19, 19:01:26
wird wohl die PS4 keinen cell mehr haben
Es haben sich ja auch genug Entwickler über die Cell Architektur ausgelassen, das diese auf gut deutsch beschissen zu programmieren ist.
sloth9
2009-11-19, 21:07:37
War mir von Anfang an klar.
Im Consumer-Bereich nie angekommen (ausser PS3 u. beknackten Türshiba-Laptops), für HPC zu speziell!
x86 ftw!
Die Empfehlung für OpenCL wird Cell aber nicht wirklich gerecht.
schade, war ein schöner ansatz. naja, mal schauen wie's mit dem on-die igp bei x86 weitergeht. könnte man was schönes cell-ähnliches draus machen.
schade, war ein schöner ansatz.
Eigentlich ein ziemlicher hässlicher.
Und schon wird wieder die Prozessorwelt etwas ärmer, und diese x86-Struktur verbreitet sich weiter, leider. :mad:
Eigentlich ein ziemlicher hässlicher.
das ist wohl eine frage der perspektive, ich bin kein dev sondern anwender ;)
ich kann mir aber nicht vorstellen, dass es auf lange sicht besonders gut funktioniert, wenn man absolut alles, was rechenleistung braucht, der gpu aufs auge drückt. ein kurz angebundener numbercruncher an der cpu hat doch was für sich oder? ;)
Hm, das war bestimmt ein teurer Spass. Hat sich Sony eigentlich stark bei den Entwicklungskosten beteiligt, wenn auch nur indirekt durch hohe Preise für die achtbare Menge an PS3-Cell?
Und schon wird wieder die Prozessorwelt etwas ärmer, und diese x86-Struktur verbreitet sich weiter, leider. :mad:
ARM wird doch immer mächtiger.
ein kurz angebundener numbercruncher an der cpu hat doch was für sich oder? ;)
Aber nicht wenn man den Cache selber (!) verwalten muss. Das muss man ja noch nichtmal bei GPUs.
Und schon wird wieder die Prozessorwelt etwas ärmer, und diese x86-Struktur verbreitet sich weiter, leider. :mad:War doch abzusehen, dass Cell mit sinkender Strukturbreite uninteressant wird. Spätestens mit AMDs ATi Kauf, war klar, das ab 45nm eine x86 CPU plus ATi GPU deutlich mehr Wumms hat ...
Jetzt kommt Fusion zwar erst in 32nm ... aber das Fazit bleibt sich gleich.
Die Empfehlung für OpenCL wird Cell aber nicht wirklich gerecht.
Da wird der Teufel mit dem Belzebub ausgetrieben. :freak:
Exxtreme
2009-11-19, 23:21:49
Und schon wird wieder die Prozessorwelt etwas ärmer, und diese x86-Struktur verbreitet sich weiter, leider. :mad:
Wieso leider? Hier setzt sich das Beste durch. Wenn die Konkurrenz nicht mithalten kann dann ist das eben so.
Wieso leider? Hier setzt sich das Beste durch. Wenn die Konkurrenz nicht mithalten kann dann ist das eben so.
Öh, das gilt für die Bereiche, wo das Betriebsystem keine Rolle spielt. Auf dem Desktop hat es eine alternative Architektur sehr schwer, gegen den Marktanteil von Windows zu bestehen. Selbst wenn die ein gutes Stück besser wäre, würden die Masse der User (auf dem Desktop) das überhaupt nicht jucken.
Von daher setzt sich überhaupt nicht zwangsweise das Beste durch - auf dem Desktop wohlgemerkt.
san.salvador
2009-11-20, 00:09:51
Öh, das gilt für die Bereiche, wo das Betriebsystem keine Rolle spielt. Auf dem Desktop hat es eine alternative Architektur sehr schwer, gegen den Marktanteil von Windows zu bestehen. Selbst wenn die ein gutes Stück besser wäre, würden die Masse der User (auf dem Desktop) das überhaupt nicht jucken.
Von daher setzt sich überhaupt nicht zwangsweise das Beste durch - auf dem Desktop wohlgemerkt.
Solange als Alternative nur Krüppel wie Cell ums Eck kommen...
(del)
2009-11-20, 00:16:46
War mir von Anfang an klar.
Im Consumer-Bereich nie angekommen (ausser PS3 u. beknackten Türshiba-Laptops), für HPC zu speziell!Ich dachte die bauen eine Abwandlung davon in die Flachglotzen und Zuspieler ein? :|
san.salvador
2009-11-20, 00:19:03
Ich dachte die bauen eine Abwandlung davon in die Flachglotzen und Zuspieler ein? :|
Aber auch nur, weil sie nicht wissen, wo sie das Zeug vergraben sollen. Da landet auch mal ein Cell mit "HD-Ultra-Engine"-Aufschrift im TV.
(del)
2009-11-20, 01:54:38
Wenn sich daraus noch sehr gute Bild-DSPs bauen lassen, dann sollen sie es ruhig machen. Ist mir lieber als wenn ein 200W Fermi mein SD-content hochskalieren sollte ;)
So grundsätzlich behämmert ist der Cell imho eh nicht, aber IBM macht daraus eben das gleiche wie aus dem PowerPC.
Wieso sollte man eine ausgewachsene cpu dort einsetzen wo Wald und Wiesen dsps oder socs wie sie zB. ti fürs video de/encoden anbietet ausreichen?
So grundsätzlich behämmert ist der Cell imho eh nicht, aber IBM macht daraus eben das gleiche wie aus dem PowerPC.
Was macht denn IBM aus dem PowerPC?
Dort wo PowerPC relevant ist, mengt man kräftig mit: http://www.heise.de/newsticker/meldung/SC09-IBM-powert-mit-Power7-863525.html
Du kannst ja wohl kaum verlangen, dass IBM noch groß in PowerPCs für Desktop-Systeme investiert. Für welche Betriebsysteme denn? Der Mac ist weggebrochen und hat sowieso nur einen kleinen Marktanteil im Vergleich zu Windows (und früher war der Marktanteil sogar noch kleiner). Es fehlt schlicht der Markt.
Von daher bin ich der Meinung, dass Windows zum Großteil bestimmt, was sich durchsetzt - auf dem Desktop. Und das ist x86.
Dort wo Windows keine Rolle spielt bzw. nicht die Bedeutung wie auf dem Desktop hat, gibt es Wettbewerb und kann sich auch eine Non-x86-Architektur eher behaupten. Siehe Power7.
(del)
2009-11-20, 03:08:41
Schrieb ich jetzt PowerPC, Power oder Power-Architektur? Deutsche Sprache kann so wunderbar exakt sein, wenn man sie versteht.
Statt "macht" hätte ich aber lieber "gemacht hat" schreiben sollen. Das stimmt.
@fdk
Ja schon recht. Wenn ich mir aber die meisten Zuspiler oder Fernseher anschaue die z.B. SD nach HD skalieren sollen, dann fehlt ihnen zu einem mehr als befriedigenden Ergebnis wohl entweder die Leistung oder die DSP-Hersteller können es weitgehend (noch) nicht besser.
Man kennt es jedenfalls auch in den Stufen gut und sehr gut. Bis ausgezeichnet. Was ein Wald&Wiesen DSP kann, das weiß ich ja. Das ist eben das Problem.
Von daher bin ich der Meinung, dass Windows zum Großteil bestimmt, was sich durchsetzt - auf dem Desktop. Und das ist x86. Sehr richtig. Wenn man sich mal die Berichterstattung über kommende ARM-Netbooks ansieht, werden die überall (von Heise vllt. mal abgesehen) fast schon als unbrauchbar bezeichnet, weil dort nie ein Desktop-Windows laufen wird. Die Masse fürchtet sich wohl vor etwas Neuem.
War mir von Anfang an klar.
Im Consumer-Bereich nie angekommen (ausser PS3 u. beknackten Türshiba-Laptops), für HPC zu speziell!
x86 ftw!
Toshiba bringt jetzt einen Cell TV in Japan raus, ein Local Dimming LCD mit 512 Zonen und Cell CPU in einer Mediabox (Cellbox).
Kann bis zu 8 HD Sender gleichzeitig aufzeichnen und vieles mehr.
http://www.youtube.com/watch?v=m2sTMLQ513M&hd=1
http://gizmodo.com/5374225/
http://www.engadget.com/2009/10/05/toshiba-details-cell-regza-lcd-tv-coming-december-to-japan/
http://s6.directupload.net/images/091120/5e8plveq.jpg (http://www.directupload.net)
"Want more? How about eight-window simultaneous multi-display, an Opera-based web browser, DLNA, and a 3TB hard disk drive, 2TB for "time-shift" recording recording up to 26 hours of programs, up to eight channels simultaneously. There's a sizable box on display, too, which seems to be where the Cell hardware is being housed."
Exxtreme
2009-11-20, 11:17:35
Öh, das gilt für die Bereiche, wo das Betriebsystem keine Rolle spielt. Auf dem Desktop hat es eine alternative Architektur sehr schwer, gegen den Marktanteil von Windows zu bestehen. Selbst wenn die ein gutes Stück besser wäre, würden die Masse der User (auf dem Desktop) das überhaupt nicht jucken.
Von daher setzt sich überhaupt nicht zwangsweise das Beste durch - auf dem Desktop wohlgemerkt.
In dem Bereich wo Cell eine Nummer war spielte Windows keine Rolle. Trotzdem mottet IBM diese Architektur weitgehend ein. Der Cell hat nämlich weit mehr Nachteile als "nur" eine Windowsinkompatibilität.
Übrigens, Windows gab es auch mal für den PPC, Alpha und MIPS. Trotzdem hat hat sich keine dieser Architakturen gegen x86 durchsetzen können. Kompatibilität zu Windows ist eben kein entscheidender Faktor.
Übrigens, Windows gab es auch mal für den PPC, Alpha und MIPS.
Aber ohne Anwendungen.
Trotzdem hat hat sich keine dieser Architakturen gegen x86 durchsetzen können. Kompatibilität zu Windows ist eben kein entscheidender Faktor.
Doch das ist sogar DER Faktor auf dem Desktop. Eine alternative Architektur hat auf dem Desktop so gut wie keine Chance wegen Windows.
Wenn morgen irgendein CPU einer alternativen Architektur erscheinen würde, der die aktuellen Intel und AMD CPUs in Grund und Boden rechnen würde, meinst du es würde sich etwas ändern? ;D
Der Masse der Leute bekäme es noch nichtmal mit.
Und die die es mitbekämen würden kurz mit der Schulter zucken und sagen mein Word, meine Spiele, meine sonstigen Anwendungen, mein Windows läuft nicht da drauf.
iDiot
2009-11-20, 11:31:50
Wenn morgen irgendein CPU einer alternativen Architektur erscheinen würde, der die aktuellen Intel und AMD CPUs in Grund und Boden rechnen würde, meinst du es würde sich etwas ändern?
Ich glaub schon.
Leider gibts die CPU aber nicht.
The_Invisible
2009-11-20, 11:48:26
Ich glaub schon.
Leider gibts die CPU aber nicht.
in welchem segment meinst du das? eine neue architektur ohne Anwendungen ist tot und selbst die portierung der wichtigsten programme würde nicht einfach so von heute auf morgen gehen. zudem kommt noch das treiberproblem, wer portiert den die alle bzw auf welchen kosten? wenn man von einem 0815 desktopsystem ausgeht quasi unmöglich.
mfg
Nicht umsonst gibt es den Begriff WinTel
Kann man auch durch Winx86. Das eine bedingt das andere...
Ich glaub schon.
Leider gibts die CPU aber nicht.
Alpha hat es seinerzeiten versucht, die gabs damals sogar bei Vobis, Win lief auch, aber die meisten Programme waren natürlich nur in x86 code, dafür gabs dann nen Emulator, wodurch das Ding im Endeffekt dann nicht schneller als ein Pentium war. War immernoch ne tolle Leistung per Emulator .. aber naja ...
BlackBirdSR
2009-11-20, 12:17:14
Das wird langsam offtpic oder? ;)#
x86/64 hat ein Eigenleben entwickelt, dem sich weder AMD/Intel noch Microsoft entziehen können. Man hats versucht... aber x86 lässt einen nicht los!
Ganon
2009-11-20, 12:39:05
Ist Offtopic gerade schlimm? Sry, will aber dazu was sagen :D
Aber mit weiter voranschreitender Software, die auf VM-Sprachen wie Java, .NET bzw. LLVM basieren, wäre ein CPU-Architekturwechsel gar nicht mal so kritisch. Aber die Umstellung an sich dauert sicher noch etwas lange, da es z.B. von LLVM afaik noch keinen direkten Windows-Port gibt. Und dann muss man auch erst mal die BWLer davon überzeugen :D
Fetza
2009-11-20, 14:23:12
Solange als Alternative nur Krüppel wie Cell ums Eck kommen...
Mich würde jetzt interessieren, was den cell zum "krüppel" macht?
Aber nicht wenn man den Cache selber (!) verwalten muss. Das muss man ja noch nichtmal bei GPUs.
Bitte was? Den lokalen Speicher der SPEs würd ich nicht als Cache bezeichnen...
Zum Thema:
Schade eigentlich, darauf zu programmieren nervt zwar, aber der Lohn der Arbeit ist gute Performance :)
_DrillSarge]I[
2009-11-20, 14:34:01
Das wird langsam offtpic oder? ;)#
x86/64 hat ein Eigenleben entwickelt, dem sich weder AMD/Intel noch Microsoft entziehen können. Man hats versucht... aber x86 lässt einen nicht los!
intel versucht das bestimmt nicht. intel ist x86 :D.
Shink
2009-11-20, 15:06:17
I[;7672631']intel versucht das bestimmt nicht. intel ist x86 :D.
Man wollte ja mal IA64 an den Endkunden bringen, in die Server ja ohnehin.
Bin auch der Meinung dass die x86-Architektur ein Hemmschuh für CPUs ist. Ich denke nicht dass Apple den Wechsel auf x86 gerne gemacht hat - oder vorhatte Leuten Hardware zu verkaufen auf die sie dann Windows installieren können. IBMs CPUs waren damals nunmal nicht die Welt im Vergleich zu Intels Core-Generation.
M$ ist wohl auch nicht besonders versessen auf x86; immerhin entwickelt man noch immer Betriebssysteme für ARM und baut seine Spielkonsole auf PowerPC-Basis.
_DrillSarge]I[
2009-11-20, 15:13:05
IA64
:facepalm: nirgendwo sonst wurde soviel geld verbrannt.
...wenigstens gibts auch lahm ausgeführtes x86 auf itaniums
;D
iDiot
2009-11-20, 15:16:21
in welchem segment meinst du das? eine neue architektur ohne Anwendungen ist tot und selbst die portierung der wichtigsten programme würde nicht einfach so von heute auf morgen gehen. zudem kommt noch das treiberproblem, wer portiert den die alle bzw auf welchen kosten? wenn man von einem 0815 desktopsystem ausgeht quasi unmöglich.
mfg
Wenn es eine Archtiektur gibt, die x86 im Desktopbereich in allen belangen überlegen ist dann wird sich diese auf die Dauer durchsetzen, daran habe ich keine Zweifel.
In Spezialfällen sind andere architekturen besser, in der Vielfalt der PC - Anwendungen jedoch pwnt ein i7 alles weg, da hilft auch kein überlegenes Konzept, die rohe Power muss ebenfalls stimmen.
Tigerchen
2009-11-20, 15:19:19
IA64 vergessen? ;)
Genau. x86 war von Anfang an nur ein Lückenbüßer. Der sollte schon recht früh durch iAPX 432 und dann durch i860 ersetzt werden. Intel selbst wollte also weg von diesem komischen Prozessor.
Heute ist eh nur noch die Oberfläche x86. Darunter verbirgt sich was ganz anderes. Ich finde wenn einer heut einen Prozessor bauen will sollte er die Möglichkeit haben diese Oberfläche zu nehmen und sein Design damit zu "verhüllen". Mir ist klar daß dem Patente entgegenstehen. Ist ein reines Gedankenspiel meinerseits.
EL_Mariachi
2009-11-20, 15:23:12
Die lassen sich sicher wieder ein völlig krankes System einfallen, um den Devs auf den Wecker zu gehen.
Vielleicht ein Cluster aus 180 dedizierten Soundprozessoren, die alle per wlan kommunizieren? Statt RAM eine interne Bluray-RW?
Sie finden sicher was lustiges. :D
muha genauso wirds passieren... :uup:
.
Exxtreme
2009-11-20, 15:49:43
Aber ohne Anwendungen.
Doch das ist sogar DER Faktor auf dem Desktop. Eine alternative Architektur hat auf dem Desktop so gut wie keine Chance wegen Windows.
Wenn morgen irgendein CPU einer alternativen Architektur erscheinen würde, der die aktuellen Intel und AMD CPUs in Grund und Boden rechnen würde, meinst du es würde sich etwas ändern? ;D
Der Masse der Leute bekäme es noch nichtmal mit.
Und die die es mitbekämen würden kurz mit der Schulter zucken und sagen mein Word, meine Spiele, meine sonstigen Anwendungen, mein Windows läuft nicht da drauf.
Microsoft hat Windows schon immer auf irgendwelche anderen CPU-Architekturen portiert. Und Legacy-Anwendungen packt man in den Emulator. Für den Alpha gab es sogar einen annehmbar schnellen. Trotzdem ist nichts draus geworden.
Ich bin mir recht sicher, daß wenn es einen CPU-Hersteller geben sollte, der es schafft mit seinen CPUs die x86-CPUs permanent zu überrunden dann setzt sich diese Architektur langfristig auch durch. Wenn man auf das P/L-Verhältnis achtet. Jetzt gibt es dafür wesentlich mehr Gelegenheiten als noch vor 10 Jahren. Java, MSIL und immer mehr Webanwendungen erlauben es. Die Software löst sich langsam aber sicher von der CPU-Architektur. Und Sachen wie RoutenplanerXYZ kann man in den Emulator packen.
Microsoft hat Windows schon immer auf irgendwelche anderen CPU-Architekturen portiert. Und Legacy-Anwendungen packt man in den Emulator. Für den Alpha gab es sogar einen annehmbar schnellen. Trotzdem ist nichts draus geworden.
Das siehst du meiner Meinung nach viel zu einfach.
Alpha war auch ein gutes Stück teuerer. Wie will man ohne Software auf die Stückzahlen der x86 CPU kommen, die vermutlich günstigere Preise erlauben bzw. Investitionen rentabler machen?
Wenn nicht massenhaft Software auf die andere Architektur portiert wird und es weiterhin x86 Systeme gibt, wird kaum jemand wechseln um dann für Mehrausgaben in einer Emulation zu arbeiten, die unter Umständen sogar langsamer noch ist. Teufelskreis.
Zur MS DOS Zeit war der 68K den x86 wohl auch deutlich überlegen, dennoch hat sich x86 durchgesetzt.
Der Windows-Faktor wiegt schwer.
Da interessiert es auch wenig, wenn andere Betriebsysteme zeitweise deutlich überlegen waren (z.B. OS/2, für das auch PowerPC-Ports angedacht waren).
Bitte was? Den lokalen Speicher der SPEs würd ich nicht als Cache bezeichnen...
Es ist das äquivalent dazu, weil es keinen Cache gibt. Große Datenmengen kann er ja wohl nicht halten.
Effektiv verwaltet man damit das Caching selbst. Auch wenn das Ding nicht so genannt wird.
Ich seh heute keinen Platz für einen anderen Ansatz für den consumermarkt. Angesichts der im Verhältnis zum Gesamtbudget an Transistoren auf einer CPU mickrigen Kosten für die x86-Kompatibilität müsste eine neue Architektur schon revolutionär in sachen Performance sein um gegen die gereiften Lösungen von AMD/Intel anzukommen. Will sagen: Ich denke nicht dass sich derzeit jemand findet, der bereit ist etliche Milliarden in eine neue Architektur mit ungewissem Erfolg/Leistung und ohne x86 support zu liefern. Zum Vergleich: ARM hatte 2006 ~250 Millionen Pfund Umsatz durch Lizenzeinnahmen für ~ 2.5 Milliarden Einheiten...
Auch die Nieschen die so ein fiktiver Hersteller nutzen könnte um r&d-Kosten anfangs wieder reinzuholen werden dank "x86 anywhere" immer dünner.
Exxtreme
2009-11-20, 17:00:25
Wenn nicht massenhaft Software auf die andere Architektur portiert wird und es weiterhin x86 Systeme gibt, wird kaum jemand wechseln um dann für Mehrausgaben in einer Emulation zu arbeiten, die unter Umständen sogar langsamer noch ist. Teufelskreis.
Die Opensource-Community schafft es alles Wichtige für mehrere Plattformen anzubieten. Und fast alles in C/C++ was ja nicht unbedingt portabel ist. Alleine Debian gibt es für 12 verschiedene Plattformen. Und in Zeiten von Java und MSIL ist das Portieren nicht mehr so das Problem.
Zur MS DOS Zeit war der 68K den x86 wohl auch deutlich überlegen, dennoch hat sich x86 durchgesetzt.
Zu 68k-Zeiten war der 68k sehr beliebt. Ich weiss jetzt nur nicht mehr ob beliebter als die x86-Plattform oder nicht. Dummerweise haben Commodore und Atari die Entwicklung verpennt und die x86-Plattform hat sie dann spürbar überholt.
Der Windows-Faktor wiegt schwer.
Da interessiert es auch wenig, wenn andere Betriebsysteme zeitweise deutlich überlegen waren (z.B. OS/2, für das auch PowerPC-Ports angedacht waren).
OS/2 hatte ebenfalls seine Macken. Z.B. war es auf damaligen Computern sehr langsam.
Die Opensource-Community schafft es alles Wichtige für mehrere Plattformen anzubieten. Und fast alles in C/C++ was ja nicht unbedingt portabel ist. Alleine Debian gibt es für 12 verschiedene Plattformen. Und in Zeiten von Java und MSIL ist das Portieren nicht mehr so das Problem.
Toll, jetzt weichst du auf OpenSource aus, obwohl von Windows die Rede war und von MS Office, Spielen und allem was dazu gehört.
Darum geht es doch. Linux und andere OpenSource Betriebsysteme sind ja auf dem Desktop so verbreitet gegenüber den 90 bis 95 % von Windows. :rolleyes:
OS/2 hatte ebenfalls seine Macken. Z.B. war es auf damaligen Computern sehr langsam.
Nur bei zuwenig RAM.
OS/2 hatte ebenfalls seine Macken. Z.B. war es auf damaligen Computern sehr langsam.Also mit 8 MB RAM lief 2.1 damals tadellos ;-)
Danach brachte IBM mit der 3.0er Version eine Optimierung auf 4 MB RAM, aber das war dann egal, weil inzwischen die RAM Preise um ~50% oder mehr abgeschmolzen waren.
Aquaschaf
2009-11-20, 18:27:07
LLVM
LLVM ist keine VM-Sprache ;)
Es ist das äquivalent dazu, weil es keinen Cache gibt. Große Datenmengen kann er ja wohl nicht halten.
Effektiv verwaltet man damit das Caching selbst. Auch wenn das Ding nicht so genannt wird.
Wenn du das so betrachtest, dann gilt für GPUs ja genau das selbe. Das was z.B. bei Nvidia 'local memory' heißt ist dann auch nichts anderes als ein manuell verwalteter Cache.
Ganon
2009-11-20, 22:10:23
LLVM ist keine VM-Sprache ;)
LLVM ist ein Compilersystem, das mehrere Sprachen in eine VM packt ;) Egal ob C, C++, ObjC, Java, Fortran, Python oder sonst was. Wird alles LLVM-Bitcode, der dann auf jeder CPU laufen kann, ohne neues kompilieren. ;)
LLVM ist ein Compilersystem, das mehrere Sprachen in eine VM packt ;) Egal ob C, C++, ObjC, Java, Fortran, Python oder sonst was. Wird alles LLVM-Bitcode, der dann auf jeder CPU laufen kann, ohne neues kompilieren. ;)
Dazu gibt es ja einen Thread: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7505679#post7505679
Aquaschaf
2009-11-21, 00:57:54
Wird alles LLVM-Bitcode, der dann auf jeder CPU laufen kann, ohne neues kompilieren. ;)
LLVM ist eine Zwischensprache. Erst einmal läuft die auf gar keiner CPU, ohne einen weiteren Kompilierschritt der daraus Maschinensprache fabriziert. Und ich würde sie nicht als "VM-Sprache" bezeichnen weil sie nicht dazu gedacht ist direkt ausgeführt zu werden, bzw. interpretiert zu werden. Es ist keine Sprache für eine abstrakte Stackmaschine wie Java Bytecode oder CIL. LLVM wird auch bei Nvidia als Zwischensprache für Cuda/OpenCL eingesetzt, beispielsweise.
Legolas
2009-11-21, 13:00:28
LLVM ist ein Compilersystem, das mehrere Sprachen in eine VM packt ;) Egal ob C, C++, ObjC, Java, Fortran, Python oder sonst was. Wird alles LLVM-Bitcode, der dann auf jeder CPU laufen kann, ohne neues kompilieren. ;)
LLVM Bitcode an sich ist erstmal genauso plattform(un)abhängig wie C/C++ Code.
Demirug
2009-11-21, 13:30:24
LLVM Bitcode an sich ist erstmal genauso plattform(un)abhängig wie C/C++ Code.
Ich würde ihn als unabhängiger einstufen da seine einfachere Struktur weniger Spielraum für Interpretationen lässt. C++ ist bei großen Projekten nur auf dem Papier Plattformunabhängig. In der Regel benötigt man eine Unmenge an Präprozessor Konstrukten um den Code an die Eigenheiten der verschiedenen Compiler anzupassen.
Legolas
2009-11-21, 13:37:12
Ich würde ihn als unabhängiger einstufen da seine einfachere Struktur weniger Spielraum für Interpretationen lässt. C++ ist bei großen Projekten nur auf dem Papier Plattformunabhängig. In der Regel benötigt man eine Unmenge an Präprozessor Konstrukten um den Code an die Eigenheiten der verschiedenen Compiler anzupassen.
Gut, das ist dann Praxis vs. Theorie, wenn Compiler nicht 100% spezifikationskonform sind. LLVM ist eben auch genau einmal implementiert.
Allerdings sind so Sachen wie plattformabhängige Typen wie z.B. int in C/C++ auch im LLVM Bitcode noch plattformabhängig.
LLVM wird auch bei Nvidia als Zwischensprache für Cuda/OpenCL eingesetzt, beispielsweise.
Hast du da grad ne passende Quelle dafür?
Aquaschaf
2009-11-21, 14:24:00
Hast du da grad ne passende Quelle dafür?
http://llvm.org/devmtg/2009-10/Grover_PLANG.pdf
http://llvm.org/devmtg/2009-10/Grover_PLANG.pdf
Ah ok.
Das hatte sich schon so angehört, als ob Nvidia LLVM statt PTX auch für den GPU Pfad benutzt.
Hätte mich jetzt echt gewundert. :)
Ganon
2009-11-21, 15:29:44
LLVM ist eine Zwischensprache. Erst einmal läuft die auf gar keiner CPU, ohne einen weiteren Kompilierschritt der daraus Maschinensprache fabriziert.
Eben darum geht es ja. Würden alle Anwendungen als LLVM-Bytecode ausgeliefert werden (also quasi die .bc-Dateien) dann wäre ein Umstieg auf eine andere Architektur wesentlich leichter, als wenn alle Anwendungen als x86-Binary ausgeliefert werden.
Nur darum ging es mir. Das das zumindest für x86, PowerPC und ARM funktioniert zeigt Apple beim OpenGL-Stack von OS X.
Und wie sieht das mit den Eigenarten einer CPU-Architektur aus, z.B. spezieller SSE-Code?
Aquaschaf
2009-11-21, 15:52:25
Eben darum geht es ja. Würden alle Anwendungen als LLVM-Bytecode ausgeliefert werden (also quasi die .bc-Dateien) dann wäre ein Umstieg auf eine andere Architektur wesentlich leichter, als wenn alle Anwendungen als x86-Binary ausgeliefert werden.
Ich glaube wir reden etwas aneinander vorbei ;) Worauf ich hinaus wollte: LLVM ist nicht explizit dafür gedacht zur Interpretation oder JIT-Kompilierung verwendet zu werden, sondern eher als Infrastruktur für vollständige Kompilierung (clang, oder das CPU-Backend für PTX von Nvidia z.B.).
Der aufwändige Teil beim Kompilieren ist das was nach der Transformation in die Zwischensprache geschieht. D.h. wenn du LLVM-Code auslieferst, dann darf jeder Benutzer den zeitaufwändig kompilieren.. außer du gibst dich mit ineffizienteren JIT-Kompilaten zufrieden. Und dann bringt dich das auch nicht weiter als es jetzt schon Java- und .net-Anwendungen tun. Die OpenGL-Geschichte bei OS X ist ein Spezialfall, dort geht es ja nur um relativ kleine Mengen von Code.
Und wie sieht das mit den Eigenarten einer CPU-Architektur aus, z.B. spezieller SSE-Code?
LLVM deckt ziemlich alle Features von CPUs ab.
Ganon
2009-11-21, 16:07:36
Der aufwändige Teil beim Kompilieren ist das was nach der Transformation in die Zwischensprache geschieht. D.h. wenn du LLVM-Code auslieferst, dann darf jeder Benutzer den zeitaufwändig kompilieren.. außer du gibst dich mit ineffizienteren JIT-Kompilaten zufrieden.
Der JIT ist gar nicht so schlecht bei LLVM, er ist nur noch etwas speicherhungrig und CPU-lastig. Und das stückweise kompilieren wäre auch gar nicht mehr so kritisch, sollte man es nutzen. Da das nicht heute passieren würde, wäre auf den CPUs der nächsten Generation das ein Kinderspiel.
Genauso werden ja meist .NET-Anwendungen (z.B. Paint.NET) erst mal "kompiliert", nach der Installation.
Und wie gesagt, wir reden ja nicht von heute, sondern eher über die Zukunft. Der ganze zeitaufwändige Kram wie Parsen ist doch bei dem LLVM-Bitcode nicht mehr in dem Aufwand nötig. Darum ist der JIT auch gar nicht mal so langsam. Zumindest ist der SciMark2 Wert bei JIT nicht viel tiefer, als der kompilierte.
Und das mit dem JIT meine ich auch nur, um C und C++ etwas "CPU-Unabhängiger" zu kriegen. Also quasi für "älteren" Code.
Aquaschaf
2009-11-21, 16:29:08
Der ganze zeitaufwändige Kram wie Parsen ist doch bei dem LLVM-Bitcode nicht mehr in dem Aufwand nötig. Darum ist der JIT auch gar nicht mal so langsam. Zumindest ist der SciMark2 Wert bei JIT nicht viel tiefer, als der kompilierte.
Die Optimierungsphase ist am zeitaufwändigsten. JIT-Kompilierung ist schnell, weil dort an der Optimierung gespart wird. Bzw. ist die Kausalität umgekehrt: der Code wird weniger optimiert um die Kompilierzeit zu verringern.
Übrigens, Windows gab es auch mal für den PPC, Alpha und MIPS. Trotzdem hat hat sich keine dieser Architakturen gegen x86 durchsetzen können. Kompatibilität zu Windows ist eben kein entscheidender Faktor.(hust) Zu dem Zeitpunkt wollte keiner der Nutzer dieser Architekturen Windows haben.
Ganon
2009-11-21, 16:48:06
Die Optimierungsphase ist am zeitaufwändigsten. JIT-Kompilierung ist schnell, weil dort an der Optimierung gespart wird.
Kannst ja gerne mal mit SciMark oder anderen Sachen testen. Soooo langsam oder unoptimal ist der JIT nicht ;)
Es ist das äquivalent dazu, weil es keinen Cache gibt. Große Datenmengen kann er ja wohl nicht halten.
Effektiv verwaltet man damit das Caching selbst. Auch wenn das Ding nicht so genannt wird.
Eigenltich kann eine SPE nichts mit dem Hauptspeicher des Cell anfangen, die arbeitet immer mit ihrem local storage. Caches sind nach Definition eigentlich Zwischenspeicher, das passt hier nicht so ganz.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.