Hands-on mit RTX Spark: Von KI-Nutzung, über kreative Workloads bis hin zum Gaming

[HWL News Bot]

Nach der offiziellen Vorstellung von RTX Spark gleich zu Beginn der Messe konnten wir uns heute etwas ausgiebiger mit NVIDIAs ARM-Chip mit starker Blackwell-GPU für Windows beschäftigen. NVIDIA machte dabei noch einmal deutlich, dass der GB10 Grace Blackwell Superchip, der im DGX Spark steckt, zwar technisch identisch zum N1X für RTX Spark sei, es sich aber nicht um den gleichen Chip handelt.
... weiterlesen

 

[Liesel Weppen]

Prism arbeitet als Software-Emulator und übersetzt x86- bzw. x64-Code zur Laufzeit in ARM64-Befehle. Dabei werden Programmbereiche nicht einfach byteweise "nachgebaut", sondern als Blöcke per Just-in-Time-Kompilierung umgewandelt, zwischengespeichert und bei erneutem Aufruf wiederverwendet, damit die Leistung nicht jedes Mal von vorn leidet.

Also wenn man x86-Befehle (also quasi Assembler?) on-the-fly in Blöcken "umkompilieren" kann, warum kann man dann nicht gleich vorab ganze Binaries einmalig "umkompilieren" und diese dann direkt ausführen? So hätte man den zusätzlich Leistungsaufwand statt "nur manchmal" sogar nur einmalig.
Man könnte sogar komplette Anwendungen nur einmal "umkompilieren" und dann sogar auf andere Geräte übertragen, so das diese dort überhaupt nichtmehr "kompilieren" müssen.

Ist das eine komplette Neuentwicklung? Apple hat da doch auch was? Rosetta oder so?

 

[HansBohne]

Das müssten aber die Lizenzinhaber der Software machen - und wenn das nicht alle machen bräuchte man die on the fly Lösung trotzdem.

Und evtl unterscheidet sich der Code auch von ARM zu ARM CPU je nachdem was die an HW mitbringt, wenn man für die CPU optimal umsetzen will.

 

[DragonTear]

Also wenn man x86-Befehle (also quasi Assembler?) on-the-fly in Blöcken "umkompilieren" kann, warum kann man dann nicht gleich vorab ganze Binaries einmalig "umkompilieren" und diese dann direkt ausführen? So hätte man den zusätzlich Leistungsaufwand statt "nur manchmal" sogar nur einmalig.
Man könnte sogar komplette Anwendungen nur einmal "umkompilieren" und dann sogar auf andere Geräte übertragen, so das diese dort überhaupt nichtmehr "kompilieren" müssen.

JIT Compilierung hat durchaus gewisse Vorteile bzw. macht manches einfacher.
Nicht umsonst setzt unter anderem Java seit jeher drauf.
Da kannst du viel Lesestoff zu finden.

 

[Liesel Weppen]

Nicht umsonst setzt unter anderem Java seit jeher drauf.

Java ist ein anderer Anwendungsfall. Da war hardwareunabhängigkeit von Anfang an Ziel und zwar indem man die Grätsche zwischen Interpreter- und Kompiler-Sprachen gemacht hat.
Man kompiliert Sourcecode quasi "vor" in Bytecode. Bei der Ausführung wird der Bytecode nochmal JIT für die darunterliegende Hardware kompiliert. Der Bytecode ist dabei aber natürlich darauf ausgelegt, das man genau das eben machen kann/muss. Die darunterliegende Hardware kann vielfältig sein. Von x86 über PowerPC bis hin zu ARM, MIPS oder sonstwas.

In diesem Anwendungsfall wird aber ein Kompilat für einen konkrete andere Platform, nämlich x86, versucht auf wiederrum genau eine konkrete andere Platform, nämlich ARM, umzukompilieren. Hier ist Platformunabhängigkeit überhaupt nicht das Ziel. Und das ürprüngliche x86-Kompilat ist auch überhaupt nicht darauf ausgelegt nochmal uminterpretiert zu werden. Das ist ausschließlich für x86 ausgelegt und vom (ursprünglichen) Kompiler auch schon auf genau diese Platform optimiert.

Java erzeugt also bewusst platformunabhängigen Bytecode und braucht dementsprechend zur Ausführung ein Java Runtime Environment (JRE) für die jeweilig konkrete Hardwareplatform. Deswegen macht JIT bei Java Sinn. Man kann übrigens Java auch direkt "fertig" zu z.B. nativem x86-Maschinencode kompilieren. Dann braucht man auf der Zielplatform auch kein JRE mehr, aber dieses Binary läuft dann natürlich nur noch auf x86-Hardware, aber dafür ohne den Performanceverlust durch die JIT-Kompilation.

Und genau das war meine Frage oben: Hier geht es nicht um Platformunabhängigkeit. Warum kompiliert man ein x86-Binary also nicht gleich einmalig komplett um und benutzt dann direkt das darauf erzeugte ARM-Binary?

Ja, Performancetechnisch ist das wahrscheinlich immernoch schlechter als den Source direkt für ARM zu kompilieren (falls er so geschrieben wurde, das das überhaupt geht, womit wir wieder bei dem Java-Ansatz wären), aber den Source hat man in den meisten Fällen einfach nicht, das x86-Binary aber schon.