Apple OS Features: Grand Central Dispatch & LLVM:Nur alter Wein in neuen Schläuchen?

[Opteron]

Apple OS Features: Grand Central Dispatch & LLVM:Nur alter Wein in neuen Schläuchen?

Ich lager hier mal die OT Diskussion aus, die ich und mr.dude in der CPU Sektion angefangen haben:
http://www.hardwareluxx.de/community/14430808-post453.html

Vielleicht kann ja noch jemand zu dem Diskurs beitragen, jeder mit sinnvollen Kommentaren ist herzlich willkommen

Apple OS ist zwar kein freies Betriebssystem, aber die Dinge um die es hier geht sind OpenSource, von daher hoffe ich das richtige Unterforum gefunden zu haben ;-)

------------------------------

Nochmal, das ist bei bisherigen Lösungen nicht anders.

Wieso können dann die ganzen dual Core Applikationen nicht automatisch von 4 oder mehr Kernen profitieren ?

Oder die QuadCore Spiele nicht von 6 Kernen oder SMT ?
Das ist alles fest auf X Threads programmiert.

Ja, kannst du so umformulieren, wenn du das besser verstehst. Der Punkt war der theoretische und reale Unterschied zwischen nativen Executables und Bytecode/JIT.

Ok, passt dann

Zitat von Opteron
Um TLP muss sich der Programmierer kümmern, ILP besorgt der (JIT) Compiler. Ist so - bleibt so - auch bei Apple, nur dass die Auf- und Verteilung flexibler ist.

Nein, ist sie nicht. Glaub es mir einfach. Sie ist komplexer, ja, aber nicht flexibler. Da kannst du von mir aus noch so viele Zitate von der Apple Seite posten, das ist einfach nur PR Gewäsch. Apple erfindet das Rad nicht neu. Sie nutzen einfach nur Sachen, die es schon lange gibt. Sie kommen jetzt halt nur mit einer eigenen, proprietären Lösung, zugeschnitten auf Apples OS. Mehr ist es nicht.

Das steht und fällt jetzt mit dem ersten Punkt oben. Gibts jetzt überall einen freien Threadpool, oder nicht ? Muss ich jetzt starr genau auf X Threads programmieren, oder kann ich das einfach in einen Threadsack werfen, der dann vom OS auf die vorhandenen Resourcen verteilt wird ?

Ich glaubs Dir gerne, dass es sowas schon gab. Aber dann will ich wissen, wo, also Beispiele, und/oder wieso das bei Windows bisher keiner gemacht hat.


Zu SSE/AVX etc.pp:

Ich sagte ja, das ist nicht neu und gibt es schon seit Urzeiten, Stichwort Interpretersprachen. Liest du eigentlich, was ich schreibe?

Jo, les ich, aber ein Interpreter ist doch was anderes, das wäre viel zu lahm, schrieb ich doch auch, das hast Du sicher gelesen
Aber gut - wenn Du damit die Grundlage meinst, dass man sich bei nem Interpreter auch keine Gedanken über das Zielsys machen muss. Gestehe ich Dir den Punkt unter Wiederwillen zu. Widerwillen deshalb, da es nach meiner Meinung ungefähr so ist einen Doppeldecker von 1919 mit einem Düsenjet zu vergleichen. Ja beides sind Flugzeuge ... Punkt an Dich ;-)

Ja, das nennt sich OpenCL und läuft nicht nur auf Apples OS.

Jo OpenCL geht in die gleiche Richtung, aber der Pferdefuß steckt mal wieder im Detail, man braucht nen CPU Treiber, wenn man OpenCL Code auf der CPU ausführen will. Hab Intel beim P3D Themenabend danach gefragt, ob sie einen OpenCL x86 Treiber planen, der Typ hat mich fast ausgelacht.
Ist aber schon mehr als 1 Jahr her - möglich das sich was geändert hat.

Nvidia wird sich auf alle Fälle hüten sowas zu machen, nach deren Philosophie soll ja alles im CUDA Core laufen, bleibt nur AMD, die haben CPU & GPU Treiber.
Per LLVM könnte Apple dem ganzen Wirrwar aber ein einheitliches Interface geben. Eventuell auf einem AMD System OpenCL Code für CPU+GPU generieren, auf einem Intel + nVidia Sys. x86 Code + OpenCL (nur für die GPU).
Eventuell wäre das auch für AMD performanter, aber das soll nur als Beispiel herhalten.

Ganz gewiss nicht. Eine Sprache ist immer mehr als eine VM. Oder meinst du mit LLVM vielmehr "LLVM Compiler System"? Das mag mehr als eine einzelne Sprache sein. Sagt nur überhaupt nichts aus. C und Java ist auch mehr als Java alleine.

Was LLVM ist, und über was ich die ganze Zeit rede steht auf llvm.org:

Low Level Virtual Machine (LLVM) is:

• A compilation strategy
• A virtual instruction set
• A compiler infrastructure

Mit einer klassischen VM á la VMware hat das wenig zu tun, beschwer Dich bei den Entwicklern über die Namensgebung, wenn Du magst ;-)

Hast du dir denn das PDF mal durchgelesen? Dort wird doch deutlich, was ich bereits sagte. Apples LLVM basiert auf den Prinzipien eines stinknormalen Interpreters. Neu ist daran nun wirklich nichts. Ausser, dass man dafür nicht selbst eine Programmiersprache spezifiziert, sondern als Quelle bereits existierende nutzt. Wer's braucht. Ich sehe darin wenig Sinn.

Ich finds schön flexibel
Interpreter für alle Sprachen für die es ein Front-End gibt plus Compilierung auf alle Zielsysteme von denen es ein Back-End gibt, wer will kann auch einen Zwischenschritt mit JIT compiles gehen. Verschiedene Sprachen kann man auch mixen (cross-language linking). Ist doch alles ganz hübsch.
Die einzelnen Bauteile mag es schon vor Urzeiten gegeben haben, aber das alles schön an einem Platz und zentral in einem OS genützt - nicht.

ciao

Alex

 

[mr.dude]

Wieso können dann die ganzen dual Core Applikationen nicht automatisch von 4 oder mehr Kernen profitieren ?

Das ist mit einem Satz nicht zu beantworten. Dafür kann es unterschiedliche Gründe geben. Du willst vermutlich auf den expliziten Software Support hinaus. Und dieser ist bei GCD genauso notwendig. Von nichts kommt nichts.

Das ist alles fest auf X Threads programmiert.

Nein. Hier geht es eher um die Unterschiede von Multitasking und Partitionierung.

Das steht und fällt jetzt mit dem ersten Punkt oben. Gibts jetzt überall einen freien Threadpool, oder nicht ? Muss ich jetzt starr genau auf X Threads programmieren, oder kann ich das einfach in einen Threadsack werfen, der dann vom OS auf die vorhandenen Resourcen verteilt wird ?

Ja, kannst du. Und zwar seit es Multitasking Betriebssysteme gibt. Runtimes für spezielle Frameworks, wie eben OpenCL, machen das dann auch noch dynamischer für verschiedene Arten von Prozessoren. Ob du OpenCL oder was auch immer nun noch direkt ins Betriebssystem integrierst, ist dabei irrelevant. Das ändert für den Entwickler nichts. Abgesehen davon, dass er dann uU eine andere Schnittstelle nutzt. Und ob der Thread Scheduler ggf durch Dritte, eben durch die angesprochenen Runtimes, neu strukturiert und umgeschrieben wird, oder von den OS Leuten selbst, ist genauso unerheblich. Mir war das anfänglich auch nicht bewusst, aber zumindest unter Windows ist das alles machbar. Scheinbar wurde es mittlerweile sogar stark vereinfacht. Einen Einstieg in die Materie findest du hier. Unter Linux ist sicherlich ähnliches möglich.

Jo, les ich, aber ein Interpreter ist doch was anderes, das wäre viel zu lahm, schrieb ich doch auch, das hast Du sicher gelesen

Vorsicht, Interpretersprachen haben sich im Laufe der Zeit stark gewandelt. Darunter fallen auch jene, die zB auf Bytecode basieren. Die Zeiten für reine Interpreter (BASIC etc) sind auch schon länger vorbei. Das sind heutzutage maximal noch Randnotizen.

Jo OpenCL geht in die gleiche Richtung, aber der Pferdefuß steckt mal wieder im Detail, man braucht nen CPU Treiber, wenn man OpenCL Code auf der CPU ausführen will. Hab Intel beim P3D Themenabend danach gefragt, ob sie einen OpenCL x86 Treiber planen, der Typ hat mich fast ausgelacht.
Ist aber schon mehr als 1 Jahr her - möglich das sich was geändert hat.

Nvidia wird sich auf alle Fälle hüten sowas zu machen, nach deren Philosophie soll ja alles im CUDA Core laufen, bleibt nur AMD, die haben CPU & GPU Treiber.
Per LLVM könnte Apple dem ganzen Wirrwar aber ein einheitliches Interface geben. Eventuell auf einem AMD System OpenCL Code für CPU+GPU generieren, auf einem Intel + nVidia Sys. x86 Code + OpenCL (nur für die GPU).

Und dafür sollen dann kein Treiber bzw hardwareseitigier Support notwendig sein? Es geht doch nicht um Hardware, sondern um Plattformen. OpenCL ist dafür spezifiziert, auf jeder Plattform lauffähig zu sein, unabhängig von Hardware und Betriebssystem. Was macht Apple nun anders? Genau, sie streichen einfach die Betriebssystemoffenheit. Und das soll jetzt besser sein oder wie du sagst, flexibler? Irgendwie habe ich das Gefühl, du willst mich veräppeln.

Was LLVM ist, und über was ich die ganze Zeit rede steht auf llvm.org

Das mag ja sein. Nur scheinst du den Inhalt nicht wirklich umfassend zu verstehen. Hand auf Herz, da liege ich doch nicht ganz falsch, oder?

Mit einer klassischen VM á la VMware hat das wenig zu tun

Davon rede ich auch gar nicht. Eine "klassische VM", bezogen auf das Thema, ist eher sowas wie die JVM. Und Apples LLVM ist im Prinzip nichts anderes. Was die gröbsten Unterschiede sind, hatte ich ja schon genannt.

Ich finds schön flexibel

Ja, das mag aber daran liegen, dass du dafür nicht programmieren musst. Aus Sicht eines Entwicklers sehe ich das eher mit Skepsis. Für Programmierer ist die Sprache, deren Funktionalität und Support entscheidend. Und nicht das, was Apple hier veranstaltet. Vereinfachungen sehe ich jedenfalls keine. Im Gegenteil, ich befürchte eher Nachteile (mangelhafter Support, Fehleranfälligkeit, hoher Wartungsaufwand, etc).

Verschiedene Sprachen kann man auch mixen (cross-language linking).

Ich kann dir schon jetzt verraten, dass das, bis auf ganz wenige Ausnahmen, ziemlicher Murks und ziemlich ineffizient werden würde. Und gemessen am Aufwand totaler Irrsinn.