gruffi schrieb:
Aktuelle Multithreading Betriebssysteme arbeiten mit Zeitscheiben, wie du vielleicht weisst. Jeder Thread bekommt eine gewisse CPU Zeit, unter Windows typisch 20 ms, nach denen geswitched wird. Man nennt das ganze auch Thread Slicing. Und egal ob ein Thread nun weiter läuft, weil eben die Hardware mehrere Threads unterstützt, oder erstmal aussetzen muss (und auch nicht über LOS und 200 Euro einstecken darf), die OS Logik fürs Switching läuft immer. Und das kostet Ressourcen, mehr oder weniger.
Und das tut Intel mit seiner x86 Philosophie leider auch.
Das dazwischen werd ich versuchen sein lassen, sind wir einfach anderer Ansicht. Und dass ATIs und nVidias Karten nichts mit SIMD zu tun und deswegen sich auch nicht drum kümmern müssen will jetzt auch nicht anfangen zu erklären. Aber die beiden Quotes da oben zusammen sagen mir einfach, dass du x86 einfach als das Gleiche siehst egal wo und wofür eingesetzt, wenn x86 dann OS -> Pre-emption -> Time-Slicing. Fest in Stein gehauen.
Das hat niemand auch nur ansatzweise in dieser Form behauptet. Schon mal daran gedacht, dass du hier völlig überreagierst und Aussagen unterbewusst misinterpretierst?
Mag sein, dass ich v.a. überreagiere (und versuche runterzukommen), aber wenn ich die Aussage mit "Intel sieht Probleme beim aufwendigen Threadswitching" in Kombination mit "Larrabee ist durch zwangsweise Parallesierung auf Softwarethread-Ebene langsam" unterbewusst misinterpretiere, dann tuts mir leid.
[edit2] Um das ganz klar zu stellen: ich sehe auch derbe Probleme wenn ständig geswitcht wird, das ist klar [/edit]
Ich behaupte einfach, dass Larrabee eben nicht in jedem Fall Timeslicing betreibt, v.a. weil Intel selber gesagt hat, dass man _keinen_ Threadscheduler vorgibt - man ist frei seinen eigenen zu schreiben. Vielleicht hast du das verpasst? Und nur so als Hinweis: wo kein Timeslice-Scheduler da ist, auch kein ständiges Switching, oder irr ich mich da? Und allein durch die Tatsache, dass man einen eigenen schreiben kann, wirds wohl kaum der Scheduler vom OS sein, der das alles handhabt? Und überhaupt OS.. wenn, dann ists der Treiber von Larrabee der das macht, und da Intel ja offensichtlich weiss, dass es ein Problem ist, wird wohl alles dafür getan werden, dass möglichst nicht geswitcht wird (jaja ich weiss.. Kristallkugel, man weiss es nicht, und bei Intel arbeiten sowieso nur Idioten). Steht btw auch alles im Paper oben - und weitere Infos auch auf den Talk-Slides von GDC 2009 und Siggraph 2008.
Mag sein dass ich mich selber zu wenig mit OpenCL (dafür mit CUDA, und so viel anders wirds nicht sein, da nVdia mächtig Input gegeben hat) beschäftigt habe, aber du mind. eben so wenig mit Larrabee. Du solltest v.a. von der Timeslice Idee wegkommen - und dann nochmals neutral drüber nachdenken, wie man gewisse Aufgaben effizient Parallisieren kann. V.A. kannst du auch nicht alles in das OpenCL-Korsett zwängen und meinen dann sei alles schnell und parallelisiert. Nichts gibts geschenkt, auch in deinem OpenCL-Paradies kannst du nicht alles parallel berechnen, die grundsätzlich gleichen Probleme und Fragen bleiben. Wenn ein Algorithmus nicht inherent parallelisierbar ist, dann bleibt das auch mit OpenCL so - und falls es das ist, kannst du das auf beide Modelle abbilden, glaub mir. Welches einem besser gefällt, darüber wollen wir nicht streiten. Aber dann ist das eine nicht wirklich schlechter als das Andere - ausser dem Vorteil, dass OpenCL auch sonst überall drauf läuft - aber dazu weiter unten mehr.
Einfach eine Frage noch: Wozu wenn nicht für Codecs und z.B. Photoshop oder Rendering (ganz Allgemein lineare Algebra-lastige Algorithmen) willst du denn GPUs oder LRB einsetzen? Da gelten leicht andere Paradigmen und Ideologien als in den schönen heilen Software-Engineering-Welt, wo man ganz bewusst auf low-level performancemässig optimale Tricks und Hacks verzichtet, weil das algorithmische Optimum ausreicht.
Ich bin vollkommen dafür, dass man im Allgemeinen die gängigen SE-Prinzipien einhält - ich will keine Börsensoftware oder geschweige denn Flugzeugkontrollsoftware die möglichst noch von Hand in Assembler (oder in C oder C++) geschrieben wurde damit sie möglichst schnell läuft, wirklich nicht, hallo Fehler, hallo Abstürze (nicht nur vom Programm...). Sie soll fehlerfrei sein, möglichst typensicher, möglichst standardkonform, am besten so konstruiert, das sie beweisbar korrekt ist (auch möglich mit bestimmten Sprachen) - und v.a. auch portabel und pflegeleicht.
Nur bin ich der Meinung, dass gewisse Sachen, wenn du maximale Performance willst, wirklich nur im Weg stehen, und bewusst darauf verzichtet werden muss, weil man eben sonst schnell einmal mit einer 1 Teraflop/s Karte auf 50 Gigaflop/s rumtümpelt (Zahlen frei erfunden und entsprechen nicht den Tatsachen, ich hab keine Kristallkugel, will nur mein Argument unterstreichen, der tatsächliche Unterschied kann auch, wenn ich mich irre = 0 sein! Aber um ein echtes Beispiel zu erwähnen: die angesprochenen GPU-real-time Raytracer wie weiter oben glaub angesprochen die auf nVidia GPUs laufen, sind zwar sauschnell verglichen mit einem Raytracer der auf der CPU läuft, weil die rohe Leistung der GPU halt extrem viel höher ist, aber wenn man die Effizienz vergleicht, siehts dann sehr schnell, sehr mies aus für den GPU-Tracer - eine Folge davon, dass GPUs eben nicht zum generellen Rechnen gedacht sind, und wenn man sich dann vorstellt, du nimmst die CPU-Platform, und gibst der die gleiche Leistung wie der GPU - hossa...).
Nun noch zur Portabilität von OpenCL: Ich sage auch nicht, dass OpenCL eine schlechte Idee ist, wenn du genau die gleiche Software wie du auf Larrabee laufen lässt auch auf einem 1GHz ARM laufen lassen willst, bloss frag ich mich, ob da wirklich so viel Sinn dahinter steckt? Wir reden hier nicht von Bürosoftware sondern aufwendingen Physiksimulationen oder sowas - ansonsten wie ich schon geschrieben hab, nimmst wohl kaum ne Maschine wie ne GT200 oder Larrabee...
Ich berechne keine Wettervorhersage auf einem iPhone, nur weil ich Standard-C/OpenCL geschrieben hab und der Compiler mir das kompiliert, und die Software am Ende sogar drauf läuft.
Ich kanns dann doch nicht sein lassen, auf einige Zwischenquotes zu reagieren:
Zum Thema Portierbarkeit auf x86-Larrabee:
Du solltest nicht so viel in ungelegte Eier interpretieren. Ich glaube nicht, dass man Anwendungen mit weniger Aufwand Larrabee tauglich machen können wird.
Ungelegte Eier stimmt halt einfach nicht - Intel hat die Intrinsics schon lange vorgestellt und ein Headerfile mit der skalaren Implementation aller Befehle online gestellt, du kannst also heute schon deine Anwendungen für Larrabee compilieren - sie laufen halt einfach langsam auf der CPU. Ist jeder frei sich ein Bild zu machen. Die Meinungen hierdrüber können auch wieder auseinander gehen, aber Bemerkungen von wegen man weiss nichts und blubb stimmen nicht mehr so Ganz, Intel ist mit vielem rausgerückt.
Erstmal ist OpenCL nicht GPU exklusiv. Wieso habe ich das Gefühl, dass du dich noch nicht wirklich damit befasst hast? Und zweitens, diese Mechanismen sind nichts neues und kennt man bereits von APIs wie OpenGL oder DirectX Graphics.
Hab ich was von exklusiv geschrieben? Nein, ich sage nur, dass OpenCL einen riesen Spagat machen muss zwischen 2 Welten, die komplett anders aussehen (eben WEIL das Modell für GPU und CPU völlig versteckt funktionieren muss...), dass hier grössere und kleinere Kompromisse in Freiheit für den Programmierer und Anpassung auf die jeweilige Platform nötig sind wirst ja wohl nicht bestreiten? Du kannst einfach keine Kugel durch ein quadratisches Loch pressen ohne etwas abzuschleifen.
Deswegen behaupt ich, einfach frei aus der Luft gegriffen, dass OpenCL für eine GPU vielleicht das Optimum rausholt, weil da eh Kompromisse am Programmierungsmodell gemacht werden müssen (siehe CUDA, und bitte Vergleich OpenCL nicht mit OpenGL oder DirectX, das disqualifiziert dich sofort...), aber nicht unbedingt für eine dermassen vielfältig einsetzbares Modell wie x86. Das war meine Grundaussage, warum man sich überhaupt x86 auf Larrabee antun soll, ich sehe da ne Möglichkeit, einbisschen (und um zu spekulieren sag ich: nicht nur einbisschen...) mehr Performance rauszudrücken als mit OpenCL - auf Kosten der Portierbarkeit natürlich.
Aber ich rede wieder von OpenCL vs x86 - worüber ich eigentlich nicht wollte -.-
Mach dir mal keine Sorgen, ich habe genug mit SSE programmiert. Und noch mehr mit Assembler. Deshalb weiss ich zu schätzen, wenn mir benötigte Funktionalität High-Level bereitgestellt wird. Und glaube es mir oder auch nicht, das wirst du irgendwann auch.
Wenn ich SSE in die Hand nehme und ich auch noch C++ haben darf, kommt um alles zuerst einmal eine Wrapperklasse (alles inline, damit keine Performance-Einbussen entstehen) und ich schreib danach keinen einzigen Intrinsic irgendwo sonst im Programm-Code. Ich finds auch schade, dass dafür keine direkte Unterstützung in der Sprache mitgeliefert wird, aber ich heul dem nicht hinterher. Genau so wie du nicht hinterher heulst, dass kein Compiler keinen einzigen C-Standard komplett implementiert.
Natürlich schätze ich heute schon die Vorteile von High-Level-Sprachen - wenn ich nicht grad eine Methode hab, deren Ausführung ohne Optimierungen 1h dauert und mit low-level-Optimierungen auf einen Zwanzigstel runtergebracht werden könnte. Wie gesagt, für Herr Büroklammer braucht man keinen Larrabee, um ein Bild in Photoshop zu laden auch nicht, aber wenn's dann ums Filtern geht, könnt man sich doch mal überlegen, ob man nicht bisschen weiter unten versucht Performance rauszudrücken, nicht wahr?
[edit3]
Und grundsätzlich kommts mir vor, dass du hier einen Krieg gegen x86 im Allgemeinen fährst, am liebsten würdest du RISCs in jedem PC sehen schätz ich, wohl deswegen auch die vielen Erwähnungen von ARM usw. Damit verfehlst du aber die Diskussion wie ich finde, ansonsten darfst du gerne im Gedanken Larrabee mit RISC-Kernen vorstellen, Threading usw trifft da dann genau so zu.
Ich weiss einfach nicht, warum du dich so fest an die GPUs klammerst, da du ja schon mal gar nie auf denen programmiert hast und mir erzählen willst, wie angenehm das ist? Weil offensichtlich ist ein allgemeines Modell wirklich nur Kacke und man nimmt sich lieber ein enges Korsett und muss zuerst mal seine ganze Anstrengung darauf konzentrieren, sein Problem da reinzubringen anstatt sich direkt Gedanken zu machen, wie man das Problem mit dem Programmierungsmodell optimal angeht.
Aber ja, ich höre auf nachzuhaken. Was ich hören wollte hab ich gehört - nämlich dass das Threading kein Problem sein _muss_. Und genau deswegen bin ich überhaupt angesprungen - von wegen es bräuchte einen Zusatzlayer und alles sei eh nur Marketing und überhaupt.
Wie auf einer Folie schon stand "lack of restrictions on Larrabee can be somewhat bewildering".
). Deswegen wärs auch cool, dass man dann tatsächlich die Leistung mit ähnlich schnellen Grafikkarten vergleicht, wenn man die Architektur vergleichen will, da sind wir uns schon einig? Ausserdem dacht ich, dass man die 2 TFLOPS mit LRB nicht erreichen wird, eher "über 1 TFLOPS" was wohl weiter weg von 2 ist. Ob das wirtschaftlich korrektes Denken ist, weil LRB tritt zwangsläufig gegen diese neuen Karten an, bezweifle ich, aber mir gehts echt nicht darum...
