MujamiVice schrieb:
Auf Windows laufen zu viele alte und zu spezielle Anwendungen. Früher od. später wird es Microsoft wohl packen müssen einen SW od. HW x86 auf ARM Umsetzer/Emulator zu bauen um bei mobilen Geräten mithalten zu können.
Einen Emulator gibt es bereits, wobei das ja eher eine Just-in-Time-Translation ist, die Hardware wird ja nicht emuliert, sondern auf Byte-Ebene umgewandelt.
Aber ja, das primäre Problem bei Windows ist die Tatsache, dass eigentlich bis Windows 8 regelrechter Wildwuchs herrschte. Hat man dann mit der WinRT-API versucht zu begegnen, aber auch jetzt existiert die Win32-API als Alternative und dort liegen auch die Probleme.
Programme, die auf C# und Co sowie WinRT aufbauen, kann man recht einfach für ARM fit machen, die Win32-Programme weniger.
Reinheitsgebot schrieb:
Die Frage ist sowohl für Windows, als auch für Linux und Apple, wie effektiv der Arm Prozessor gegenüber x86 Prozessor ist, bezogen auf die gleiche Leistung verglichen mit Verbrauch.
AArch64 hat hier gegenüber x86 einen Vorteil: Die Umwandlung von "RISC" zu µOPS für die Kerne ist einfacher, dazu kommt, dass ARM ein relativ einheitliches Register-Design hat, bei x86 musst du zwischen x86-32 und x86-64 unterscheiden.
In den Extensions kommen dann gerne sehr viele Register bei x86 dazu, sodass sich das durchaus ausgleicht.
Vom "Design" her, ist RISC "einfacher" aufgebaut, was leichte Vorteile bei der Effizient bringt. Ansonsten hängt aber die Leistungsaufnahme auch bei ARM-Kernen von der Breite sowie Tiefe der CPU ab. Und auch hier ist ARM wieder an manchen Stellen besser aufgestellt, weil man früh schon in ARM wusste, dass Kopiervorgänge in den CPU-ALUs auch Energie benötigen - hohe Zahl an Register.
ARM merkt man halt an vielen Ecken und Enden an, dass hier ein Design entwickelt wurde, dass auf den Erfahrungen mit komplexen CISC-Designs wie dem x86 oder eben auch Motorola 68k aufbaut und entsprechend angepasst wurde um dessen Schwächen und Probleme zu umgehen.
Da aber viele der Ansätze aus den 80er und frühen 90er auch heute bei x86 Einzug halten, kann man recht vereinfacht sagen: Die reinen CPU-Kerne - sofern sie die gleichen Eckdaten haben - bewegen sich bei beiden Designs auf einem ähnlichen Level mit leichten Vorteilen für ARM.
Bei beiden Designs im "Hochleistungsbereich" sieht man zu dem sehr ähnliche Entwicklungen - Apple M1 mit aktuellen Zen3 als auch eben IceLake/Rocket Lake verglichen. Nur bei den Caches gehts ein paar andere Wege. Sie setzte aber alle auf möglichst breite Designs, die man versucht durch eine eine entsprechende Cache-Strutur zu versorgen, sodass immer genug Befehle da sind, auch wenn man mal auf Daten wartet.
Rein von der fiktiven "Leistung" bewegen sich hier auch die aktuellen Designs auf dem gleichen Level. Auch die Möglichkeiten der Architekturen sind über weite Bereiche sich ähnlich, sei es AES-Verschlüsselung, SIMD, FMA und Co.
Primäre Unterschiede bestehen aktuell bei der Breite der SIMD. ARM nutzt in der Regel die Neon, 128Bit. Hat aber die SVE mit bis zu 2048Bit-Breite für SIMD. AMD ist jetzt bei 256Bit pro SIMD, Intel 256Bit - 512Bit. (AVX, AVX2, AVX512). Apple kompensiert die Breite über die Anzahl der SIMD-ALUs.
Bei modernen CPUs ist die Software dadurch weit wichtiger und wie diese mit den Ressourcen umgehen kann. Der Compiler-Bau hat in den letzten Jahren massiv an bedeutung gewonnen, aber auch der allgemeine Software-Stack.
Aber auch hier hat "ARM" einen Vorteil für Apple: Die SVE ist sehr flexibel, da man in Software einen entsprechenden Vektor aufbauen kann, die CPU dann aber bei der Ausführung entscheiden kann, wie es den Vektor zerlegt und auf die FPUs verteil. Intel ist mit AVX512 da zum Teil an die breite gebunden. Um bei Intel die maximale Rechenleistung herauszuholen, benötigt man bei AVX512 2 Vektoren je 16 Werte. AVX1 und 2 "nur" 8 Werte und bei SSE/Neon sind es gar nur 4 Werte und je nach Szenario ist es halt einfacher kleine Vektoren zu füllen.
Sollte Apple - was in den Gerüchten kursiert - SVE umsetzten für die nächste M-Generation, könnten sie zum Beispiel 4 * 128 Bit oder eben 2 * 256Bit oder gar einmal 1*512 Bit auf den vier ALUs berechnen, ohne dass es Probleme gibt.
Lange rede kurzer Sinn: ARM wird immer leichte Vorteile bei der Energie aufnahme haben, aber der primäre Vorteil für ARM bei Apple ist der Software-Stack, der hier viele Leistungsreserven heraus holt.
