Ganz abwegig ist das ja nicht. Beispielsweise hat Apple fast zeitgleich mit dem Intel-Switch die Expertise zu sich geholt, die über die A-Prozessoren schlussendlich auch zur jetzigen M-Reihe an Prozessoren geführt hat (PA-Semi).
Es wäre vorstellbar, dass in einer zukünftigen Gerätekategorie oder vielleicht auch in einer bestehenden Kategorie irgendwann erste spezialisierte RISC-V-Prozessoren auftauchen, die dann Schritt für Schritt in andere Kategorien Einzug halten. So ein Prozess dauert lange Zeit. Somit ist die Stellenanzeige aus meiner Sicht nicht als Zeichen für eine baldige Abkehr von ARM zu verstehen.

Seid ihr sicher, dass Apple Lizenzgebühren bezahlt und nicht eine grundlegende "Lebenslange" Lizenz für die ARM Prozessordesigns besitzt?
Immerhin wurde ARM von Apple und Acorn gegründet...

Wenn dann bezahlen sie bestimmt nur ein paar dollar pro chip...

In 15 Jahren gibt’s dann den A-RISC-VII oder so ähnlich.

Ja... ehm... nö.

Apple haelt sich wohl wie immer alle Meglichkeiten offen

Dem stimme ich voll und ganz zu.
Es muss für Apple zudem auch sehr verlockend sein, keine Lizenzgebühren für ARM zahlen zu müssen und unabhängig von aktuellen oder zukünftigen ARM-Übernahme(-versuchen) zu sein.

Gut, sind jetzt nicht die neusten Chips hier, aber man beachte, dass der ARM Cortex A9 3.71 Punkte und der ARM Cortex A15 4.72 Punkte erreicht hat. Nun, der SweRV, ein RISV-V CPU Design, erreichte damals in einer Simulation 4.9 Punkte (siehe rechts oben). Simulationen sind nicht exakt, aber die Leistung realer CPUs ist in Simulationen heute sehr gut vorhersagbar. Vergleicht man später die Leistung gebauter CPUs so entspricht die in etwas dem, was man durch die Simulationen vorher ermittelt hatte, daher wird heute gar keine CPU jemals gefertigt, wenn deren Leistung schon in der Simulation nicht passt. Ist die simulierte Leistung zu gering, dann wird das Design erst einmal weiter am Reißbrett verbessert. Und wie man hier sieht, hat RISC-V sehr wohl das Potential zeitnah ARM Konkurrenz zu machen.

Vom theoretischen Design halte ich RISC-V definitiv für überlegen, auch wenn hier ein paar fachliche Fehler gemacht wurden, da man beim Design nicht unbedingt berücksichtigt hat, wie Software aktuell funktioniert. Zugegeben, dass sie so arbeitet liegt natürlich auch daran, dass existierende CPU Architekturen die Entwicklung von Compiler und Programmiersprachen beeinflusst haben, aber nicht alles was bisherige Architekturen gemacht haben war an sich schlecht oder verkehrt. Hier hätten sich die RISC-V Erfinder ruhig etwas mehr von bestehenden Architekturen "inspirieren lassen" dürfen. Dass z.B. sowohl ARM als auch x86 Speicherzugriffe mit Displacement erlaubt hat einen ganz einfachen Grund: Damit lassen sich viele Array Zugriffe mit nur einer Instruktion statt mit drei Instruktionen durchführen und solche Zugriffe macht Software eben verdammt häufig. Gerade dann wenn man etwas sowohl bei ARM als auch bei x86 findet, trotz der ansonsten großen Unterschiede der Architekturen, spricht vieles dafür, dass auch in neue Architekturen aufzunehmen.

Bezogen auf die Rechenleistung pro Watt liegt RISC-V sogar weit vorne:

Daher denke ich, dass Apple hier mit den Gedanken spielt, ggf. RISC-V für die Apple Watch zu nutzen (was viel längere Batterielaufzeiten zur Folge hätte) und ggf. einen RISC-V Coprozessor in die anderen Geräte zu verbauen, der bestimmte Aufgaben im Hintergrund übernimmt, wenn man nicht viel Rechenkraft braucht und lieber mehr Strom sparen möchte.

Denn wer RISC-V belächelt, der darf nicht vergessen, welche Schwergewichte aktuell unter anderem die Entwicklung von RISC-V fördern und vorantreiben. Um mal ein paar Namen in den Raum zu stellen: Qualcomm, Google, IBM, Nividia, Rambus, Samsung, HP, Seagate, NXP, Western Digital und sogar Siemens ist dabei.

Vieles davon ist noch Theorie, weil RISC-V sehr Modular aufgebaut ist und einige Module noch gar nicht final verabschiedet wurden, sprich, die Architektur wird aktuell immer noch entwickelt bzw. um wichtige Komponenten erweitert , aber Unternehmen wie SiFive bauen diese CPUs bereits basierend auf den Teilen, die schon fertig sind:

@Mecki: Sehr interessant, danke dafür!

Vielleicht ist RISC-V eher was für den Apple Serverpark. Auf welche Hardware laufen denn die aktuellen Dienste wie iCloud, Music, ATV+ usw. ?

Aktuell glaube ich das eher nicht, aber was RISC-V hier zu Gute kommen könnte ist, dass man von Anfang an die Architektur auf 32, 64 und 128 bit ausgelegt hat. Server können durchaus sinnvoll von der höheren Bitbreite profitieren, die es bei anderen CPUs nur durch die Vektorerweiterungen gibt und die wiederum lassen sich nur in Spezialfällen sinnvoll auf Servern einsetzen (Spieleserver und Streaming Server z.B. aber die meisten Server in Rechenzentren profitieren nur wenig davon).

Was ich auch in Betracht gezogen habe ist GPU. Hier hatt Apple ja früher immer ein Design von PowerVR lizenziert, bis sie angefangen haben selber GPUs zu entwickeln. Über deren GPUs wird nicht viel berichtet, kaum jemand weiß wie die intern arbeiten. Und bei GPUs ist es so, dass die Geschwindigkeit pro Kern gar nicht so relevant ist, da sich GPU Operationen wunderbar parallelisieren lassen. Ein Design mit langsamen Kernen, aber davon extrem vielen, kann einem Design mit wenigen schnellen daher überlegen sein. Die Idee RISC-V auch für GPUs zu verwenden, ist nicht neu Es kann also auch sein, dass Apple einfach vor hat ihre GPU weiter zu beschleunigen, indem sie ihr ein großes Array an RISC-V Kernen bei Seite stellt, die dann Shader Code parallel abarbeiten.

Ich dachte eher an die Effizienz und somit auch an dem Stromverbrauch einer entsprechend größer Serverfarm. Wenn man sich den Benchmark so anschaut ist es schon beeindruckend was heute möglich ist. Für Spielestreaming oder andere Echtzeitanwendungen ist es weniger interessant aber als Datenserver für iClou oder für Email, Web oder ähnliche Dienste sicher eine interessante Alternative.

So weit ich weiss basieren die immer noch auf dem (tile basierten) PowerVR Design.
Da hat sich wohl nichts grundlegendes geändert. Oder weiß da wer mehr?

Tiled Rendering ist keine Erfindung von PowerVR, sie waren AFAIK nur die ersten, die dieses Verfahren in Hardware für den Massenmarkt umgesetzt haben (das Verfahren wurde 1989 als Teil der Pixel Planes 5 Architektur entwickelt, die erste PowerVR GPU kamen 1996 auf den Markt). Der Vorteil dieses Designs ist, dass die GPU keinen großen Speicher für das Rendering braucht und diese auch bei weiten nicht so schnell angebunden sein muss. Ideal also für Systeme, bei denen die GPU gar keinen eigenen Speicher besitzt, sondern sich am System RAM bedient, welches bei weiten nicht so schnell wie dedizierter GPU Speicher angebunden ist.

Es macht also durchaus Sinn, dass Apple dieses Verfahren beibehalten hat. Nicht zuletzt auch deswegen, da alle Software und Treiber, die sie bis zum Wechsel geschrieben hatten ja auf dieses Verfahren hin optimiert worden ist. Grundsätzlich hat das Verfahren nur zwei Nachteile: Dreiecke müssen mehrfach gezeichnet werden, wenn sie in mehreren Tiles sichtbar sind und bestimmte Effekte, die sich auf das gerenderte Bild als ganzes auswirken, sind schwierig zu implementieren (zumindest dann, wenn man die Tile-Grenzen nicht erkennen soll im fertigen Bild). Ersteres ist aber umso weniger ein Problem je detaillierter die 3D Modelle werden, denn umso kleiner werden auch die Dreiecke und letzteres ist ein Problem für denjenigen, der den Treiber bzw. die Grafik-API implementieren muss, nicht aber für den Anwendungsentwickler.

Das wäre eher schlecht, da dadurch die Sprungvorhersage beim out-of-order Design komplizierter wird und man mehr Probleme im Design bekommen kann – siehe Meltdown und Spectre. x86 und ARM sind halt alte Designs, d.h. zu einer Zeit entstanden als der Speicherzugriff ohne große Latenz erfolgte. Mittlerweile ist die Latenz beim Speicherzugriff groß, und nur im L1 Cache kann man relativ problemlos auf Daten zugreifen. Für alles andere spielt der Unterschied gar keine Rolle mehr, weil man so lange auf die Daten wartet, dass der problemlos deutlich mehr Befehle (es vergehen da zum Teil tausende Taktzyklen) ausgeführt werden könnten.
128Bit Register ersetzen keine SIMD Einheiten, sondern erlauben 128Bit Arithmetik und Adressoperationen. Das wird z.B. beim Mapping von Dateien ins RAM zu einem Thema, weil man mit 64Bit nur 16EiB=16384PiB ansprechen kann und es bereits Storage Systeme mit etlichen PiBs gibt, und in HPC Server hat man ganz schnell zehntausende Platten verbaut. Da ist nicht mehr viel Luft nach oben, und man braucht 128Bit Adressen.

Also das sieht diese ehemalige ARM Ingenieurin anders, die RISC-V sogar eine deutlich schlechtere Branch Prediction bescheinigt als anderen Architekturen:
Und genau das sagen Experten auch über RISC-V. Zitat:

"Design flaws. RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. Between some rookie mistakes like few addressing modes (register churn, code density) and blowing out the encoding space. However, despite its flaws, it’s poised to take over embedded and possibly beyond anyways – worse truly is better."
Und wo bitte hatte ich das behauptet? Ich hatte geschrieben, dass Server von 128 Bit Registern profitieren können, diese aber bei den anderen Architekturen nur für SIMD Anweisungen vorhanden sind und diese SIMD Anweisungen nur für wenige Spezialanwendungen am Server interessant sind, aber die meisten Server nicht von ihnen profitieren können. Was genau glaubst du jetzt bitte daran korrigiert zu haben?

Apple verbaut im iPhone sehr viele kleine Chips. Vermutlich wollen sie erstmal spezielle Chips auf RISC-V umstellen. Auf Nvidia Grafikkarten gibt es z.B. auch ARM Prozessoren.

Ja, danke auch von mir, Mecki ! Fachlich toll erörtert!

Soll NVidia doch endlich Arm kaufen, damit es
im besten Falle wieder GPU Treiber für Macos gibt...als Gegenleistung für die Nutzung der Arm Architektur durch Apple...

Ich habe mir das durchgelesen (der Code wird tatsächlich so generiert) und einige kleine Tests selbst gemacht, und da sieht die Codegenerierung für Aarch64 oder Intel64 nicht besser aus.

Aus diesem Code
daraus macht der Aarch64 Crosscompiler
und der RISC-V Crosscompiler
Das ist ein Nullsummenspiel.
Viel interessanter ist dann etwas realistischer Code
Der wird dann für Aarch64 zu
und für RISC-V zu
Wo bitte ist da eine deutlich geringer Codedichte zu sehen? Wichtiger sind sichere CPU-Kerne, die keine Bugs wie etwa Meltdown oder Spectre beinhalten.
Ein früherer ARM-Entwickler sagt das. Da besteht die Gefahr, dass die Antwort nicht sonderlich neutral ausfällt.

hmm.. bin ziemlich sicher, dass das es Nvidia darum erst mal nicht geht. Das wäre im besten Fall das i-Tüpfelchen oben drauf. Aber bis dahin ist Apple wohl längst auf RISC-V.

Du vergleichst hier RISC-V mit anderen Architekturen, das habe ich aber nicht getan. Ich habe RISC-V wie es ist mit RISC-V wie es hätte sein können verglichen. Die Tatsache, dass RISC-V nicht schlechter ist als andere Architekturen heißt nicht, dass es besser als diese ist. Und nur darum ging es auch in den von mir verlinkten Kritiken. Diese sagen nicht das RISC-V grundsätzliche schlechter ist, sie sagen, dass RISC-V Fehler anderer Architekturen wiederholt hat, obwohl man aus heutiger Sicht weiß, dass das Fehler waren und wenn man einen brandneue Architektur entwickelt, dann sollte man Fehler der Vergangenheit vermeiden und nicht wiederholen.

Ach ja, und GCC ist bei Codedichte und Optimierung im Allgemeinen LLVM weitgehend unterlegen. Und selbst wenn du LLVM verwendet hättest, kannst du keine Schlüsse über die Qualität einer CPU Architektur ziehen, indem du schaust welchen Code irgend x-beliebiger Compiler dafür erzeugt, denn vielleicht ist der Compiler einfach nur schlecht oder unterstützt die Architektur einfach nur schlecht. Hier geht es um die Frage, was der kleinste Code wäre, den ein Compiler hätte erstellen können.
Also jemand mit hoher fachlicher Qualifikation, der sich bei diesem Thema garantiert besser auskennt als du, oder an welcher CPU Architektur hast du so bisher beruflich gearbeitet?
Wie kommst du darauf? Gerade Ex-Arbeitgeber und deren Produkte werden doch häufig von ehemaligen Mitarbeitern kritisiert und sie hat nirgendwo behauptet, dass ARM das alles besser macht oder die ARM Architektur nicht auch gravierende Fehler aufweist. Sogar im Gegenteil: Ein paar ihrer Kritikpunkte waren doch, dass RISC-V Fehler kopiert hat und da waren auch ARM Fehler dabei.

Vielleicht plant Apple künftig neue Afterburner-Karten (siehe Mac Pro 2019 Afterburner Card) auf RISC-V Basis.
Was genau hat Apple dort eigentlich verbaut? Habe auf die Schnelle keine Infos finden können. Offenbar hat sich niemand daran gemacht, die Karte auseinander zu nehmen.

Deine Behauptung war, dass eine RISC Plattform mit Adressierung ohne Offset schlechter sei. Der konkrete Code zeigt das, dass das nicht der Fall ist.
Das war einmal, und zuletzt für GCC 9 gültig. Ab Version 10 erzeugt der GCC sehr viel besseren Code, und besseren Code als clang.

Der Code für norm.c von clang
Der GCC 9.3.0 zauber daraus
Für den PGI Compiler habe ich den objdump Output genommen, da der PGI Compiler massenweise Zeugs in den Assembler Source packt, die nachher ohnehin herausfallen.
Mich interessiert dieses herum theoretisieren nicht, da man seit Itanium weiß, dass ein theoretisch gutes Design der Praxis extrem schlecht sein. Assembler wird jedenfalls fast nicht mehr programmiert, so dass die erzielbare Qualität der Compiler hier der wesentliche Faktor ist. Wenn nun Compiler für RISC-V vergleichbar guten Code generieren, dann ist das für die Praxis relevant.
Weil der konkrete Code zeigt, dass seine Aussagen nicht zutreffend sind. Der Rest seines langen Sermons kritisiert unter anderem die Möglichkeit von 128Bit Adressräumen. UNIX/Linux limitiert die Größe von memory mapped files auf den Adressraum, und bei manch einer HPC-Anwendung läuft man hier bereits Gefahr, dass 64Bit nicht ausreichend sind.