LLVM=Bytecode

[native client]

LLVM erzeugt Bytecode. Der ist dann wie inzwischen üblich, auch portabel.

Das hätte im Bericht noch stehen können.
LLVM ist so cool, das laut wikipedia.de bei Apple damit fehlende Hardwarefähigkeiten bei opengl ausgebügelt werden.

Sowas wollte ich schon immer: Im letzten Schritt, erst bevor das .exe ausgeführt wird, wird es an die aktuelle CPU, CPU_Features, L2/L1/L3-Cache und vielleicht sogar Problemgröße optimiert.
Compiler sind heutzutage schnell genug dafür. 95% des Codes ist eh oft nur GUI und Schnickschnack.
Wenn man das immer und überall macht, flutscht halt alles im OS besser. Miese Viren_Checker-Engines oder cpu-lastige MP3-Encoder werden davon nicht notwendig schneller. Aber halt der ganze "Normalo"-Rest. Und ipad/iphone-Anwendungen sind oft sehr "normalo" und holen nur Daten und stellen sie dar.

[CocoaProggbär]

Das hat nichts mit cool sein zu tun. LLVM kann unter OSX mittlerweile mit C-LANG den kompletten gcc ersetzen. Die Kompilate sind schneller erstellt und der Code ist performanter.

Mit einem Unterschied: LLVM ist eben extrem low level, wie der Name schon sagt. Ein GC ist beispielsweise nicht mit drin.

Neben C-Lang sind auch andere Module in Arbeit. Apple soll angeblich an einer Ruby-Implementierung arbeiten, die direkt LLVM-Bytecode erzeugen kann.

[smirg0l]

Interessante Idee, aber hast schon mal ein größeres Projekt kompiliert? Ein kompletter Build kann durchaus eine ganze Weile dauern...

[CocoaProggbär]

Falsch. LLVM/Clang kompiliert deutlich schneller als gcc.

[ein typ]

> Falsch. LLVM/Clang kompiliert deutlich schneller als gcc.

naja, falsch ists nicht direkt.
wenn gcc 10 stunden compiliert und via llvm 3, dann sind 3h trotzdem ne lange Zeit ;)

[klo]

soweit ich das verstanden hab meinte er es soll alles auser die GUI compiliert werden und somit der part der programms der rechenintensiv ist und der wäre in vielen fällen wirklich schnell zu compilieren

[gfdgd]

es dürfte wohl auch noch nen unterschied machen, ob man von quellcode oder bytecode aus zu maschienencode compiliert.

[.....................a.....................]

Von .exe in Assembla konvertieren macht auch der Loader.
Ausser bei statischen Exe-Files, welche keine einzige Library shared nutzen (busybox).

Also hampelt nicht herum nur weil der Loader jetzt ein wenig mehr machen muss. Wenn mans einmal in assembla konvertiert hat, kann man es ja auch speichern und im Folgenden darauf verzichten, weil man ja das .exe.assembla-File noch da liegen hat. Man kann allerdings auch .profiling-Informationen sammeln und gelegentlich oder bei stärkerer Nutzung das bytecode-exe beim nächsten Mal entsprechend optimierter auf .assembla/maschinenCode konvertieren.
Öfter genutzte Software wird dann schneller, weil die dazulernt. Eine Software, die auf bestimmte Grafikauflösungen optimiert ist, läuft halt schneller. Weil sie gelernt hat, wie groß die Bilder von der eigenen Digitalkamera sind.
D.h. die Verzweigungen werden optimiert angelegt so das der Code möglichst optimiert durchlaufen wird. Das lernt man natürlich erst, wenn die Software genutzt wird und man profiled.
JIT-Optimierungen gehen natürlich auch.