Es hat niemand behauptet, dass nicht zusätzliche Entsicklungsarbeit von Nöten ist, um Programme speziell auf den vielen kleinen CPU-Kernen zum Laufen zu bringen.
Doch, die ganzen Larrabee Fans, die das was Intel ihnen auftischt, ohne größere Fragen, schlucken.
Aber Fakt ist - bzw. laut dem, was Intel sagt - dass Larrabee x86-Code verarbeiten kann.
1. Fakt ist gar nichts! Nur das der Larrabee nicht so super toll wird, wie Intel uns das einreden wollte.
2. Intel sagt viel wenn der Tag lang ist, denen solltest nicht weiter trauen als sie schmeißen kannst.
3. Wenn der Larrabee so super duper toll ist, warum gibts dann noch keine Performance Werte im Netz??
Vielleicht weil Intel die nicht leaken lassen hat, weil man sich damit blamieren würde??
Es wäre also möglich, dass Programme wie Vue, Cinema4D oder andere grafische Anwendungen beim Rendering sofort an Geschwindigkeit zulegen. Vorausgesetzt, dass Windows Larrabee auch als viele CPUs verwalten kann, sonst hat das ganze wenig Sinn.
Nein, wäre es nicht!
Du solltest dir mal anschauen, wie die 'x86 CPUs' im Larrabee aufgebaut sind!
Das sind bestenfalls 486er mit modernem Befelssatz, nicht mehr.
Also gerad mal 'ne pipeline, kein Out of order Execution, Branch Prediction und ähnliche nette Dinge, also eher sowas wie der Atom.
Von daher kannst davon ausgehen, das ein Nehalem den Larrabee sowas von platt macht, das kannst dir nicht vorstellen, zumindest bei 'normalem' x86 Code...
Zumal das eine ja eine GP-CPU ist, das andere ein Stream Prozessor wie der Cell.
OpenCL ist für reine Grafikkarten gedacht bzw. bisher gibt es keine anderen Komponenten (z.B. Soundkarten... *gg*), die mit OpenCL etwas anfangen können, auch keine CPUs.
Wenn du keine Ahnung von etwas hast, solltest vorher nachschauen, wozu gibt es denn
Wikipedia?!
Und hast du schon mal überlegt, warum OpenCL Open
Computing Language heißt?!
Um mal Wikipedia zu zitieren:
Wikipedia.de schrieb:
OpenCL (Open Computing Language) ist eine Programmierplattform für CPUs, GPUs und DSPs
uups?!
Oder Heise:
Heise News schrieb:
Die OpenCL-Spezifikation erwähnt aber ausdrücklich auch andere Prozessoren und Co-Prozessoren, etwa die Cell Broadband Engine oder Digitale Signalprozessoren (DSPs) – sowohl die Cell-Entwickler IBM und Sony als auch DSP-Marktführer Texas Instruments waren an der OpenCL-Spezifikation beteiligt.
Du siehst, OpenCL ist nicht nur für Grafikkarten, auch wenn es auf CUDA basiert, das ist eher was universelles, wo man jedes Stück Hardware mit nutzen kann, das rechnen kann.
Wenn man also von Larrabee redet, ist die Frage, ob man es in Verbindung mit OpenCL oder doch lieber normalem x86-Code bringen sollte.
Wenn man vom Larrabee redet, sollte man das als Grafikkarte tun, entsprechend OpenCL, zumal kein normaler Mensch auf die Idee kommen würde, ausschließlich für dieses Teil zu programmieren.
Da muss es schon 'nen dicken Scheck von Intel geben, um jemanden davon zu überzeugen.
Erwähnte ich schon, das die Möglichkeiten von OpenCL unendlich sind, die Marktdurchdringung vom Larrabee momentan 0 ist?!
Oh und Cells kann man auch mit OpenCL ansprechen - braucht nur einen Treiber von IBM...
Dazu noch die GraKas von nVidia und AMD...
Wenn, wie schon beschrieben, Larrabee nativen bisher vorhanden Code direkt verarbeiten kann, sollte man logischer Weise in x86 schreiben, da LB mehr CPU als GPU ist - halt eine CPU mit Texturierungseinheiten und was ebend dazugehört. Wenn durch die Schnittstelle bei LB Programmieraufwand von Nöten ist, muss man abwägen, wie viel es ist und ob es sich rentiert.
1. Ist der Larrabee eben nicht mehr CPU sondern GPU, das ist nur Intel Propaganda.
2. Ist das 'ne GPU und zwar sowas von.
3. Wird man, wie schon erwähnt, auf das setzen, was am weitesten verbreitet ist und das ist nun mal OpenCL.
Wenn man x86 CPU schreibt, dann setzt man hier auch 'normale' CPUs voraus, die sind weitaus schneller als das GPU Teil von Intel, was spricht jetzt dafür, ein Programm, das
komplett neu geschrieben werden muss, statt in OpenCL für den Larrabee umzuschreiben??
Mir fällt da irgendwie nichts ein, siehe oben.
Zumal noch abzuwarten ist, ob die x86 Einheiten überhaupt nutzbar sind bzw wie die funktionieren und so weiter.
Weil wenn man die einfach so rein klatscht, könnts ganz blöde Auswirkungen auf den Betrieb mit WIndows haben, was zur Folge hat, das Programme entweder gar nicht mehr oder ziemlich lahm laufen...
Zudem sollte man sich fragen, ob es für Entwickler, die mehr als nur reine CPUs benötigen, von Vorteil ist, wenn sie auf OpenCL setzen und die Rechenpower GPUs nutzen oder doch lieber ihrer jetzt schon vorhandenen Code zusätzlich abwandeln und umstrukturieren, um ihn auf LB zum Laufen zu bringen. Welches der beiden Verfahren besser ist, hängt ganz stark vom Einsatzgebiet ab und nicht von der Schnittstelle selber.
Das hier ist nur Intel Propaganda, sorry.
Aber nochmal: Welchen Sinn hat es, ein Programm für etwas zu schreiben, das nicht existiert, dessen Erfolg zweifelhaft ist?
Statt für eine offene Schnittstelle zu schreiben, die von allen Herstellern von Prozessoren verwendet werden könnte?!
Richtig, keinen Sinn macht das, hier wird man auf OpenCL setzen, da kannst auch im 3eck rotieren, das wird einfach so kommen, allein schon aufgrund der Verbreitung von OpenCL kompatibler Hardware!
Denn eine GPU ist kein Allheilmittel und kann nicht alle Aufgaben der CPU übernehmen - jedenfalls nicht in annähernd vergleichbarer Geschwindigkeit. CPU und GPU haben ihre Aufgabenfelder, weshalb es sehr gut möglich ist, dass man einen Vorteil auch aus LB ziehen kann.
1. Aber der LRB ist ein Allheilmittel?!
2. Und wie kommst du jetzt auf die Idee, das eine simpelste In-Order x86 CPU auch nur ansatzweise z.B. einem Athlon das Wasser reichen kann?
Welche Fakten veranlassen dich zu dieser Annahme??
Was am Ende dabei herauskommt, ist natürlich eine andere Geschichte, aber darüber braucht man hier nicht zu diskutieren, da man hier das Produkt und die Reaktion der Entwickler abwarten muss.
Doch, muss man, oder willst jetzt erstmal die Diskussion über die Performance und andere Nachteile dieses Teils abwürgen??
Weil kommt ja von Intel, muss gut sein??
Und zu diesem Sachverhalt hab ich schon mehr als genug geschrieben, die Entwickler schauen halt, was es bringt, wie groß ist die Basis und wenn die Basis dafür nicht vorhanden ist, lässt man es halt einfach sein, PUNKT.
Außer natürlich man wird geschmiert, dann schauts anders aus...
Noch eine Frage an die Allgemeinheit: Hat man bisher überhaupt etwas dazu verlauten lassen, ob LB OpenCl und/oder DirectX10 (besser 11) beherrscht?
Natürlich wird das Teil D3D10 beherrschen, ev. gar D3D11, das ist im Netz auch bekannt.
Welchen Sinn sollte es denn haben, eine Grafikkarte zu entwickeln, die nicht elementar wichtige Funktionen beherrscht??
Edit: Laut deinen Argumenten dürften Entickler auch nicht auf Nvidias Cuda setzen und trotzdem gibt es nicht nur Physx-Spiele, sondern auch cuda-basierte Anwendungen, die daraus ihren Vorteil ziehen. Und selbst die Tatsache, dass vielleicht gerade einmal 50 % aller PCs (mit Grafikkarten) überhaupt in der Lage wären Cuda zu nutzen, wird auf diese Technologie gesetzt. Hier wurde auch nicht auf OpenCL und DirectX 11 gewartet, sondern die vorhandene Technologie genutzt. Also wird es sicherlich auch Anwendungen geben, die zukünftig und vielleicht ausschließlich auf LB setzen werden. Es hängt halt, wie schon gesagt, stark vom Einsatzgebiet ab, was sich lohnt und was nicht.
Nein, denn für Cuda Programme ist eine (nicht gerade kleine) Basis vorhanden, so ziemlich alles ab der Geforce 8 Serie kann CUDA Code ausführen, das ist schon 'ne ganze Menge!
Außerdem soll OpenCL auf Cuda basieren, so dass die Möglichkeit besteht, CUDA Code in OpenCL Code 'umzuformatieren'...
Dennoch lass ich mich überraschen, was deren LB kann und wozu es zu gebrauchen ist. Was von Intels Wahrheiten am Ende übrig ist, werden wir ja sehen.
Deshalb eher als Anwendungsgebiet GPGPU oder CPU dank x86.
Bin mal gespannt, wie groß der wirklich wird.
