Nicht täuschen lassen. Das ist nichts anderes als bisherige Lösungen. GCD ist das Frontend, nichts anderes als eine Bibliothek, das OS/der Thread Scheduler ist das Backend. Was ist der Unterschied zu bisherigen Systemen? Exakt, es gibt keinen wirklichen.
Apple macht halt nur eine PR Geschichte daraus.
Doch, man hat den Vorteil, dass man nicht explizit auf eine festen Anzahl Threads hinprogrammieren muss, sondern einfach angibt dass Codeblock xy "concurrent" abgearbeitet werden kann, und der GCD verteilt das dann auf die 1,2,3,4,5 .... X Kerne, je nachdem wieviel man hat. Genaueres siehe unten.
Und der Witz an einer nativen Executable ist, dass Bytecode bzw JIT theoretisch optimaler und ggf schneller ist, da der Compiler für das jeweilige System übersetzen kann.
(...)
Nur, von dieser Theorie ist die Realität immer noch weit entfernt.
Äh wie jetzt ? Native Exec. ist doch was anderes als Bytecode / JIT ? Bitte umformulieren, verstehe nicht, was Du sagen willst. Willst Du vielleicht sagen:
Und der Witz an Bytecode bzw JIT ist, dass es theoretisch optimaler und ggf schneller als eine nativen Executable ist, das der Compiler für das jeweilige System übersetzen kann.
(...)
Nur, von dieser Theorie ist die Realität immer noch weit entfernt.
? Das würde ich verstehen. Aber keine Ahnung obs stimmt ^^
Was denn für Flexibilität? Du vergleichst zwei vollkommen verschiedene Sachen, ILP und TLP. Das eine wird das andere nicht ersetzen können. Genauso wenig wie das eine flexibler ist als das andere.
Ich hab noch nie was von ILP und TLP geschrieben. Wenn Dus unbedingt haben möchtest, bitte gerne
:
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. Man muss die Sachen nicht wie bisher streng in genau X Threads aufteilen, sondern in ab- und unabhängige Blöcke. Ob aus diesen Blöcken dann 1,2,3,4 ....100 Threads werden, das entscheidet das AppleOS, abhängig von der vorhandenen Hardware.
Both Mac OS X and iPhone OS adopt a more asynchronous approach to the execution of concurrent tasks than is traditionally found in thread-based systems and applications. Rather than creating threads directly, applications need only define specific tasks and then let the system perform them. By letting the system manage the threads, applications gain a level of scalability not possible with raw threads. Application developers also gain a simpler and more efficient programming model.
Concurrency Programming Guide: Introduction
Ich dachte, SSE und Co. wären überflüssig? Jetzt nutzt es der Compiler doch?
Ausserdem, was ist daran jetzt neu? Das gibt es schon seit Urzeiten, Stichwort Interpretersprachen.
Äh natürlich wird SSE usw. genutzt ... nur muss sich der Programmierer nicht damit herumschlagen. War bei bisherigen Hochsprachen & Compiler zwar auch schon fast so, aber mit dem LLVM wird einem gleich die optimale Lösung für das jeweilige System compiliert. Bisher wurde der Einfachheit halber meistens nur auf SSE2 optimiert (oder nur 386er x86), SSE3 oder gar 4 liegen oft brach, ausser bei handgestrickten Spezialprogrammen. Wäre mit LLVM anders. Schau Dir vielleicht mal das OpenGL Beispiel im unten verlinkten PDF an. Da haben die gewisse CodeTeile in der IR gelassen. Falls das System jetzt eine potente GPU hat, wird die beackert, wenn nicht, wird automatisch CPU Code für die Emulation generiert. Gibts sowas schon ?
Mit "wegfallen des Gedöns" im ersten Post meinte ich, dass sich ein Entwickler nun überhaupt keine Gedanken mehr über das Zielsystem machen muss. Hinten kommt natürlich SSE/AVX/OpenCL etc. pp Code raus, aber diese ganze Optimierung wird in eine Black Box gesteckt, die ihm nichts mehr angeht, auch ARM anstatt X86 wäre möglich - Assembler Gurus natürlich ausgenommen ;-)
Klingt jetzt erstmal nach JAVA, aber LLVM ist mehr, siehe PDF.
Das Teil jetzt Interpreter zu nennen ist auch nicht richtig, LLVM ist eher die eierlegende Wollmilchsau. Wenn Du magst, kannst Du das auch als static Compiler benützt, wenns denn sein muss. Aber es gibt halt auch die Option auf JIT & LTO. Reinen Interpreter Betrieb gibts dagegen nicht, das wäre doch zu lahm
Les Dir vielleicht die Präsentation hier durch, damit Du weisst, was die vorhaben, bevor wir weiter diskutieren:
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
![[TLR]Snoopy](/community/data/avatars/m/20/20196.jpg?1577437178){kind=avatar}
weil halt intel draufsteht
