Stirbt Intel den Nokiatod?

[stscon]

Irgendwie scheint Intel links und rechts überholt zu werden (AMD+Auftragsfertiger, MacOS on ARM?, Windows on ARM?, kein Standbein mehr im Smartphone/Tabletsektor) und außer mit Aktionismus können sie nicht richtig reagieren. Im Moment leben sie noch von ihrem guten Namen, aber wie lange noch?



1 mal bearbeitet, zuletzt am 17.04.19 10:13 durch stscon.

[blackbirdone]

Arm CPUs sind langsam. Sehr langsam. Da braucht sich Intel oder Amd keine Sorgen machen. Das Windows und Mac auf Arm laufen, heist nicht das irgendwas anderes darauf läuft. Das Apple auf Arm wechseln will stört niemand, die Kisten sind jetzt schon maßlos überteuert für die geringe Leistung die sie bieten. Da fällt das kaum auf.

Also ist wohl noch genug Luft, aber Konkurrenz belebt das Geschäft.

[InFlames]

blackbirdone schrieb:
--------------------------------------------------------------------------------
> Arm CPUs sind langsam. Sehr langsam.

Nur wenn man die single Core Performance betrachtet.
Wenn man den kompletten Leistungsverbrauch schaut hat ARM die Nase vorn!

https://blog.cloudflare.com/arm-takes-wing/

Natürlich auch vom Einsatzzweck abhängig. Ein Wundermittel für alles gibt es nicht.

[/mecki78]

blackbirdone schrieb:
--------------------------------------------------------------------------------
> Arm CPUs sind langsam. Sehr langsam.

Wer erzählt denn so einen Unfug? Ich meine, außer du hier im Forum?

https://postimg.cc/f3QQWjft
https://postimg.cc/V5Zy0cFc
https://postimg.cc/hXxNYQRS

Das Surface Pro 6 hat mindestens eine 1,6 GHz Intel Mobile Quad-Core i5-8250U (mit Turbo bis zu 3,6GHz) oder besser als CPU.

Das Dell XPS 13 sogar eine 1,8 GHz Mobile Quad-Core i7-8550U (mit Turbo bis 4GHz).

Und das Apple MacBook Pro 13 hat auch mindestens eine 2,3 GHz Dual-Core i5 (mit Turbo bis zu 3,6GHz). oder besser.

Das iPad Pro, das in jedem Benchmark deutlich gewonnen hat, hat eine 2,26 GHz Dual-Core 64-bit ARMv8-A CPU.

Am Mobilmarkt hat ARM bereits heute die Nase vorne in Sachen Performance und am Desktop Markt werden sie dieses oder nächstes Jahr bereits im Mittelklassensegment vorbeiziehen:

https://postimg.cc/9zwdjdzH

ARM CPUs, die Desktop i5 schlagen gibt es bereits heute zu kaufen, i3 schlagen sie schon lange. Fraglich wie lange sich Intel nur mit i7 über Wasser halten kann.

Dazu hat ARM noch den Vorteil, dass er eben sehr wenig Strom braucht und aufgrund seiner Einfachheit leichter strukturell zu verkleinern ist. Heutige CPUs werden kaum noch viel schneller durch Frequenzzuwachs. Am einfachsten lässt sich heute die Performance über mehr Cores steigern:

https://postimg.cc/KRTLVBQp

Die Frequenz (grün) hat kaum groß zugelegt in den letzten Jahren. Auch die Performance pro Core (blau) steigt immer langsamer. Dennoch nimmt die Anzahl der Transistoren weiter zu (orange) und zwar deswegen, weil die Anzahl der logischen (und auch physischen) Kerne immer weiter zunimmt (schwarz). Denn lassen sich Rechenaufgaben parallelisieren, dann nimmt die Performance durch mehr Kerne auch weiter zu.

Und hier ist es halt so, dass wenn ein CPU insgesamt max. 40 Watt verbrauchen soll und du 8 echte Kerne möchtest, dann darf jeder Kern max. nur 5 Watt verbrauchen und das ist mit x86 praktisch nicht zu machen, denn ein x86 Kern, der nur 5 Watt verbraucht, der bringt keine Leistung. Mit ARM ist das möglich, denn ein ARM Kern mit 5 Watt bringt bereits ordentlich viel Leistung.

> Das Windows und Mac auf Arm laufen, heist nicht das irgendwas anderes darauf läuft.

Es heißt aber auch nicht, dass es nicht dort läuft. Es gibt heute sehr gute CPU-cross-compiler, die aus Maschinencode für eine CPU Maschinencode für eine andere CPU machen können. Das muss nur genau einmal passieren, danach läuft der Code mit nativer Geschwindigkeit, fast so als wäre er gleich für diese CPU gebaut worden. So etwas kann man problemlos in ein Betriebssystem bauen. Apps wie QEMU emulieren damit CPUs in fast nativer Geschwindigkeit.

Noch dazu spielt CPU Maschinencode eine immer unwichtigere Rolle in der App Entwicklung. Immer mehr Apps nutzen intern Sprachen wie JavaScript (alle Apps die auf node.js basieren z.B.), was angesichts von immer besser werdenden JIT Compilern für JS und ergänzenden Technologien wie asm.js und WebAssembly von der Performance her kaum mehr von nativen Apps zu unterscheiden ist (C/C++ lässt sich direkt in WebAssembly kompilieren).

Hier, versuch das mal mit Firefox oder Chrome:

http://example.qt.io/qt-webassembly/widgets/richtext/textedit/textedit.html

Das ist einfach C++ Code, der nach WebAssembly kompiliert wurde. Firefox und Chrome beherrschen WebAssembly schon recht gut. Erst der Browser macht aus WebAssembly dann CPU Maschinencode. Sogar 3D Beschleunigung steht zur Verfügung:

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

Diese Technologie steht noch am Anfang, wird aber bald auf vielen Webseiten Einzug halten, da man damit ein komplette App, die nicht für das Web geschrieben wurde, in eine Webseite einbetten kann. Natürlich kann man damit auch Apps lokal im System laufen lassen.

Windows Apps, die in C# oder VB.NET geschrieben sind werden sowieso erst durch das System in CPU Code umgewandelt. Die meisten neuen Apps für Windows sind UWP Apps und UWP Apps sind entweder in C++, C#, Microsoft Visual Basic oder JavaScript geschrieben. Außer wenn du C++ nimmst sind solche Apps automatisch CPU neutral. Allerdings eine UWP C++ App für eine andere CPU zu brauen ist eine Sache von wenigen Minuten, da das UWP Framework plattformneutral ist.

Und Apple verlangt auch schon lange, dass alle Apps in deren Stores Bitcode beinhalten müssen. Bitcode ist eine Zwischensprache, aus der sich CPU Anweisungen für beliebige CPUs erstellen lassen und zwar serverseitig, sprich, liegt Apple eine App in x86 und Bitcode vor und ein Mac Nutzer will dieses App für seinen ARM Mac laden, dann kann Apple aus dem Bitcode ARM CPU Maschinencode erzeugen und den ausliefern. Das müssen sie auch nicht jedes mal machen, sondern nur genau einmal, das Ergebnis können sie ja dann cachen. Sprich, das können sie auch vorab schon machen und dann kann sich der Server beliebig viel Zeit bei der Umwandlung lassen, z.B. um den Code gut zu optimieren.

Dieser wird nicht schlechter sein als nativer ARM Code, denn Apple nutzt überall das Clang Compiler Framework und dieses wandelt immer zuerst den Source Code (egal ob C, ObjC, C++ oder Swift) in Bitcode um, um dann den Bitcode zu optimieren und am Ende CPU Maschinencode daraus zu erzeugen. Der Vorteil hierbei ist, dass man immer den gleichen Optimierungscode verwenden kann, egal was die Ausgangssprache mal war. Sprich, der x86 Code, der bei Apple liegt, der wurde genauso erstellt, nur dort hat der Entwickler die Umwandlung von Bitcode in CPU Code auf seinen Rechner durchgeführt. Da er aber den Bitcode mit zu Apple hochgeladen hat, kann Apple jederzeit neuen CPU Code daraus erstellen, auch für andere CPUs.

Dein hier beschriebenes Problem wurde also schon lange gelöst, du hast die Lösung nur verschlafen.

/Mecki

[bofhl]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> blackbirdone schrieb:
> ---------------------------------------------------------------------------
> -----
> > Arm CPUs sind langsam. Sehr langsam.
>
> Wer erzählt denn so einen Unfug? Ich meine, außer du hier im Forum?
>
> postimg.cc
> postimg.cc
> postimg.cc
>
> Das Surface Pro 6 hat mindestens eine 1,6 GHz Intel Mobile Quad-Core
> i5-8250U (mit Turbo bis zu 3,6GHz) oder besser als CPU.
>
> Das Dell XPS 13 sogar eine 1,8 GHz Mobile Quad-Core i7-8550U (mit Turbo bis
> 4GHz).
>
> Und das Apple MacBook Pro 13 hat auch mindestens eine 2,3 GHz Dual-Core i5
> (mit Turbo bis zu 3,6GHz). oder besser.
>
> Das iPad Pro, das in jedem Benchmark deutlich gewonnen hat, hat eine 2,26
> GHz Dual-Core 64-bit ARMv8-A CPU.
>
> Am Mobilmarkt hat ARM bereits heute die Nase vorne in Sachen Performance
> und am Desktop Markt werden sie dieses oder nächstes Jahr bereits im
> Mittelklassensegment vorbeiziehen:
>
> postimg.cc
>
> ARM CPUs, die Desktop i5 schlagen gibt es bereits heute zu kaufen, i3
> schlagen sie schon lange. Fraglich wie lange sich Intel nur mit i7 über
> Wasser halten kann.
>
> Dazu hat ARM noch den Vorteil, dass er eben sehr wenig Strom braucht und
> aufgrund seiner Einfachheit leichter strukturell zu verkleinern ist.
> Heutige CPUs werden kaum noch viel schneller durch Frequenzzuwachs. Am
> einfachsten lässt sich heute die Performance über mehr Cores steigern:
>
> postimg.cc
>
> Die Frequenz (grün) hat kaum groß zugelegt in den letzten Jahren. Auch die
> Performance pro Core (blau) steigt immer langsamer. Dennoch nimmt die
> Anzahl der Transistoren weiter zu (orange) und zwar deswegen, weil die
> Anzahl der logischen (und auch physischen) Kerne immer weiter zunimmt
> (schwarz). Denn lassen sich Rechenaufgaben parallelisieren, dann nimmt die
> Performance durch mehr Kerne auch weiter zu.
>
> Und hier ist es halt so, dass wenn ein CPU insgesamt max. 40 Watt
> verbrauchen soll und du 8 echte Kerne möchtest, dann darf jeder Kern max.
> nur 5 Watt verbrauchen und das ist mit x86 praktisch nicht zu machen, denn
> ein x86 Kern, der nur 5 Watt verbraucht, der bringt keine Leistung. Mit ARM
> ist das möglich, denn ein ARM Kern mit 5 Watt bringt bereits ordentlich
> viel Leistung.
>
> > Das Windows und Mac auf Arm laufen, heist nicht das irgendwas anderes
> darauf läuft.
>
> Es heißt aber auch nicht, dass es nicht dort läuft. Es gibt heute sehr gute
> CPU-cross-compiler, die aus Maschinencode für eine CPU Maschinencode für
> eine andere CPU machen können. Das muss nur genau einmal passieren, danach
> läuft der Code mit nativer Geschwindigkeit, fast so als wäre er gleich für
> diese CPU gebaut worden. So etwas kann man problemlos in ein Betriebssystem
> bauen. Apps wie QEMU emulieren damit CPUs in fast nativer Geschwindigkeit.
>
> Noch dazu spielt CPU Maschinencode eine immer unwichtigere Rolle in der App
> Entwicklung. Immer mehr Apps nutzen intern Sprachen wie JavaScript (alle
> Apps die auf node.js basieren z.B.), was angesichts von immer besser
> werdenden JIT Compilern für JS und ergänzenden Technologien wie asm.js und
> WebAssembly von der Performance her kaum mehr von nativen Apps zu
> unterscheiden ist (C/C++ lässt sich direkt in WebAssembly kompilieren).
>
> Hier, versuch das mal mit Firefox oder Chrome:
>
> example.qt.io
>
> Das ist einfach C++ Code, der nach WebAssembly kompiliert wurde. Firefox
> und Chrome beherrschen WebAssembly schon recht gut. Erst der Browser macht
> aus WebAssembly dann CPU Maschinencode. Sogar 3D Beschleunigung steht zur
> Verfügung:
>
> s3.amazonaws.com
>
> Diese Technologie steht noch am Anfang, wird aber bald auf vielen Webseiten
> Einzug halten, da man damit ein komplette App, die nicht für das Web
> geschrieben wurde, in eine Webseite einbetten kann. Natürlich kann man
> damit auch Apps lokal im System laufen lassen.
>
> Windows Apps, die in C# oder VB.NET geschrieben sind werden sowieso erst
> durch das System in CPU Code umgewandelt. Die meisten neuen Apps für
> Windows sind UWP Apps und UWP Apps sind entweder in C++, C#, Microsoft
> Visual Basic oder JavaScript geschrieben. Außer wenn du C++ nimmst sind
> solche Apps automatisch CPU neutral. Allerdings eine UWP C++ App für eine
> andere CPU zu brauen ist eine Sache von wenigen Minuten, da das UWP
> Framework plattformneutral ist.

Kleiner Irrtum: auch DOTNET-Applikationen und Libraries können direkt in Maschinencode umgewandelt und dmit direkt ausführbar sein! Und das mit C++ und C# etc. stimmt so auch nicht - alle DOTNET-Benutzende Sprachen verhalten sich gleich! Außer du gehst her und erstellst mit C++ reinen Maschinencode - nur benutzt du dann kein DOTNET mehr, sondern nur mehr die Platform-Libs.

> ....

[/mecki78]

Intel reitet seit Jahren ein totes Pferd. x86 hatte eigentlich schon keine Zukunft mehr, denn die Architektur ist zu komplex, zu verseucht mit Altlasten, absolut nicht mehr zeitgemäß und es ist nicht möglich fundamentale Designfehler zu beheben, ohne damit die Abwärtskompatibilität zu brechen und nicht zuletzt von dieser lebt Intel aber!

Intel selber ist diese Problem bewusst, weswegen sie ja selber x86 beerdigen wollten mit dem Itanium, der ja mit einen komplett neuen Intstruktionsset (IA-64) daher kam. Aber genau deswegen wurde er auch ein Flop.

Zum einen war er eben nicht mehr zu bestehenden x86 Code kompatible und damals war die IT Industrie noch nicht soweit, dass die CPU Architektur für Apps vernachlässigbar wurde; das galt höchstens für Java und das mochte keiner, weil es nie gut in Windows integriert war.

Zum anderen baute IA-64 auf der Idee auf, dass die CPU dumm wie Toast ist und die ganze Intelligenz im Compiler stecken soll. Grundsätzlich nicht verkehrt, denn eine dumme CPU lässt sich besser skalieren. Allerdings kann ein Compiler nur bedingt das Laufzeitverhalten von Code abschätzen bzw. es braucht aufwendiges Profiling und viele Tests, damit er das dann und das macht es schwer hier schnell mal performanten Code für so eine CPU zu erzeugen. Dumme CPUs sind schon der richtige Weg, aber der Itanium war einfach zu dumm und erwartete einfach zu viel Vorarbeit vom Compiler.

Es war AMD, die mangels alternative an x86 festhalten wollten und die daher x86_64 geschaffen haben, denn das gehört AMD, Intel hat das nur lizenziert und das mussten sie auch, weil AMD ihnen zunehmend Marktanteile abgenommen hat und sie daher wieder zu x86 zurück sind und den Intanium erst nur so nebenher laufen haben lassen, bis sie ihn eben ganz aufgegeben haben.

Das Problem ist, dass bei x86 schon lange keine große Performancesteigerung mehr drinnen ist, außer eben durch "Tricks". Mit Tricks meine ich, dass man z.B. einfach mehre Cores nimmt, wenn sich ein Core alleine nicht weiter steigern lässt, so sind die Multi-Core CPUs geboren. Oder das man virtuelle Cores einführt (Hyper Threading), um die Auslastung der einzelnen Teile der CPU zu steigern. Oder man eben immer mehr Berechnungen auf Verdacht im Voraus durchführt. Letzteres hat uns dann so tolle Dinge wie Spectre und Meltdown beschert, denn bei diesen Tricks um die Geschwindigkeit doch noch irgendwie zu steigern blieb halt die Sicherheit immer mehr auf der Strecke. Außerdem verpasst Intel x86 immer wieder Erweiterungen, die zwar aktuell sinnvoll sind (z.B. kann x86 in Hardware AES-128 verschlüsseln), aber die in einem CPU Instruktionssatz nichts verloren haben (in ein paar Jahren heißt es AES-128 ist nicht mehr zeitgemäß und dann nutzt neue Software nicht mehr davon, aber Intel kann es auch nie entfernen, weil sonst alte Software bricht - total Schwachsinn!)

Von diesen Problem ist aber ARM aktuell noch weit entfernt. ARM ist deutlich weniger komplex aufgebaut, die CPU Instruktionen sind durchdachter und weniger gewachsen, man muss keine komischen Altlasten mitschleppen und obwohl ARM auch schon ein alter Befehlssatz ist, passt er viel mehr zu heutiger Software als x86, denn im Gegensatz zu x86 ist es deutlich aufwendiger ARM Instruktionen von Hand zu schreiben, aber wer bitte macht das auch groß? Heute wird Software immer in einer high-level Sprache geschrieben und ein Compiler tut sich mit ARM leichter als mit x86. x86 wurde von Intel so gebaut, dass man hier zur Not auch recht schönen Assembler Code von Hand für schreiben kann, so ganz ohne Compiler, was so um 1978 herum vielleicht noch wichtig gewesen sein mag, aber heute keinen Menschen mehr interessiert. Deswegen ist x86 vergleichsweise high-levelig (CISC).

Auch hier behilft sich Intel seit Jahren, dass sie CISC in eine Art micro-RISC zerlegen und dann das intern ausführen, aber auch das ist nicht optimal und funktioniert nicht so gut, wie wenn gleich RISC Anweisungen von außen kommen. Dies hat nur dazu geführt, dass die CPUs von Intel mittlerweile komplexe Gesamtsysteme sind, so eine Art Mini-PC im PC. Man kann die nicht mal mehr einfach mit Strom versorgen und die funktionieren, nein, die müssen gebootet werden und brauchen sein Bootsystem drum herum, weswegen es die IntelME gibt, die noch bevor das BIOS (UEFI) ausgeführt wird, die CPU booten muss, denn erst dann kann ja ein BIOS auf dieser CPU ausgeführt werden. Da aber auch die IntelME eine CPU braucht, auf der sie läuft, haben Intel Boards in der Northbridge eine kleine Zweit-CPU (das wissen die meisten gar nicht), mit der das System bootet und dann erst mal die Primär-CPU hochbringt.

Die Frage ist, wie lange Intel dieses tote Pferd noch weiter antreiben kann, denn während bei x86 die Performance immer langsamer zunimmt, zieht halt ARM mit Schallgeschwindigkeit außen vorbei:

https://postimg.cc/9zwdjdzH

Und sobald erst einmal Software grundsätzlich immer auf jeder CPU laufen kann, und da sind wir heute zum großen Teil schon angekommen, fällt auch das "Abwärtskompatibilität"-Argument weg und spätestens wenn das komplett weg fällt, wird das Intel das Genick brechen, wenn sie dann nicht eine x86 Alternative aus den Hut zaubern, die deutlich besser als das ist, was die Konkurrenz liefert.

/Mecki

[/mecki78]

bofhl schrieb:
--------------------------------------------------------------------------------
> auch DOTNET-Applikationen und Libraries können direkt in
> Maschinencode umgewandelt und dmit direkt ausführbar sein!

.NET ist ein Framework, dessen Nutzung aber optional und unabhängig von der gewählten Sprache ist, und basiert immer auf der CLR.:

https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/DotNet.svg/360px-DotNet.svg.png

Zitat:
Programs written for .NET Framework execute in a software environment (in contrast to a hardware environment) named the Common Language Runtime (CLR). The CLR is an application virtual machine that provides services such as security, memory management, and exception handling.
https://en.wikipedia.org/wiki/.NET_Framework

Code für die CLR ist nie Code für eine bestimmte CPU. Allerdings anders als bei Java, wo Bytecode primär dazu gedacht war interpretiert zu werden und man erst hinterher JIT Compiler dafür gebaut hat, war CLR von Anfang an dafür entworfen worden, dass die Instruktionen vorab in CPU gewandelt werden, siehe auch

https://en.wikipedia.org/wiki/Common_Language_Runtime

Einen Interpreter für CIL Code zu schreiben ist zwar natürlich nicht unmöglich, aber er wird eine sehr miese Performance haben und man wird schnell merken, dass der Arbeitsaufwand um ein vielfaches höher ist als eine Java Bytecode Interpreter zu schreiben.

Umgekehrt tut sich ein JIT Compiler in Java schwer vernünftigen CPU Code zu erzeugen. Nicht umsonst hat SUN damals das JIT Konzept über den Haufen geworfen und mit dem HotSpot Compiler einen Hybrid aus Interpreter und JIT Compiler gebaut. Der Vorteil hier ist, dass jeglicher Code immer erst einmal ausgeführt wird, bevor der JIT Compiler ihm umbaut und er somit Erkenntnisse durch die Ausführung aus dem Code gewinnen kann, die sich so nur durch das Betrachten von Bytecode nicht gewinnen lassen könnten, denn Bytecode ist eben für einfache Interpreter und schnelle Interpretation optimiert.

Genau hier unterschiedet sich aber CIL, da es deutlich mehr und vor allem deutlich komplexere Instruktionen kennt. Schlecht für Interpreter, gut für Compiler, denn das hilft Compilern viel besseren Code für die jeweilige CPU erzeugen zu können.

> alle DOTNET-Benutzende Sprachen verhalten sich gleich!

C++ ist aber keine .NET Sprache. Die Sprache, die du meinst, heißt C++/CLI (ausgeschrieben heißt die C++ modified for Common Language Infrastructure) und ist eine Eigenkreation von Microsoft, die halt einfach den C++ Sprachsyntax übernommen hat, aber letztlich etwas völlig eigenständiges darstellt:

https://en.wikipedia.org/wiki/C%2B%2B/CLI

Sie wurde von Microsofts Haus und Hof Standatisierungsbehörde Ecma als ECMA-372 standardisiert, während C++ durch die ISO standardisiert wird. Microsoft liebt die Ecma, weil die standardisieren jeden Kack, wenn man dafür zahlt, anders als die ISO oder die IETF, die nur noch lachen, wenn Microsoft wieder mit irgendeinen Mist um die Ecke kommt, der die Welt nicht interessiert.

Nicht zu verwechseln mit C++/CX, was auch eine eigene Sprache von Microsoft ist, basierend auf dem C++ Standard mit ähnlichen Syntax wie C++/CLI, aber statt CIL Code und dem .NET Framework wurde hier nativer Code und die Windows Runtime genutzt:

https://en.wikipedia.org/wiki/C%2B%2B/CX

C++/CX ist aber veraltet, der Nachfolger heißt C++/WinRT, wurde mit Windows 10 eingeführt, und setzt wieder auf ganz normales C++. C++/WinRT ist lediglich ein Library, um die Windows 10 Runtime von C++ aus zu nutzen, ohne dabei die Sprache zu verändern, sprich, hier kommt ganz normales ISO-C++ zum Einsatz, da ISO-C++ schon länger alles das bietet, was Microsoft damals in C++ vermisste und warum sie überhaupt C++/CX geschaffen haben:

https://en.wikipedia.org/wiki/C%2B%2B/WinRT

Um aber wieder zum Thema zurück zu kommen: Schreibst du deinen Code in C++/CLI, dann läuft das Ergebnis bereits heute auf jeder CPU, weil dann läuft das so:

https://upload.wikimedia.org/wikipedia/commons/thumb/6/6f/CLR_diag.svg/640px-CLR_diag.svg.png

Nutzt du C++/CX oder C++/WinRT, dann ist dein Code direkt für eine bestimmte CPU, müsste man dann nur ein Compiler Setting ändern und einmal neu bauen um den gleichen Code für eine andere CPU zu bekommen, denn in der Regel ist C++ die CPU Architektur egal, man muss höchstens dafür sorgen, dass sich der Code nicht auf ein bestimmtes Endian verlässt.

/Mecki