Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Sucht Apple Alternativen zu ARM? Experte für RISC-V erwünscht

Möchte man einen Blick auf die mittel- und langfristigen Ideen und Ziele eines Unternehmens wie Apple werfen, gibt es hierfür drei Möglichkeiten: Einerseits versorgen Leaker Interessierte mit Informationen zu möglichen Produkten in der Zukunft, andererseits geben oftmals Patente Aufschluss über Technologien, die noch einer Realisierung harren. Bisweilen ist es auch erkenntnisreich, die Stellenausschreibungen einer näheren Begutachtung zu unterziehen: So zeigt sich beispielsweise, dass Apple neue Mitarbeiter für Fahrzeugtechnik sowie künftige Mobilfunktechnologien wie 6G sucht. Ein aktuelles Jobangebot legt nahe, dass sich der Konzern nach einer Alternative zu ARM umsieht.


Apples Abhängigkeit von ARM
Apples ARM-Prozessoren gelten gemeinhin als überaus leistungsstark – zu Recht: Die iDevices führen dank der A-Chips regelmäßig die Benchmarks an und der Umstieg auf die neue Architektur weiß auch bei Macs zu begeistern. Auch Google sei von Apples Fortschritten begeistert gewesen und arbeite nun an ARM-Chips für Chromebooks (siehe hier). Allerdings hat diese Entwicklung auch Nachteile: So begibt sich Cupertino immer mehr in die Abhängigkeit von ARM – und muss für die Prozessoren Lizenzgebühren an ARM entrichten, über deren Höhe sich beide Unternehmen ausschweigen.

Experte für RISC-V gesucht
Möglicherweise verfolgt Apple perspektivisch noch andere Pläne: Eine neue Stellenanzeige verrät, dass der Konzern einen „RISC-V High Performance Programmer“ sucht. Bei RISC-V handelt es sich um eine offene Plattform, welche es Geräteherstellern ermöglicht, eigene Chips zu bauen – im Gegensatz zu ARM-Prozessoren würden also keine Lizenzgebühren anfallen. Allerdings gilt es als unwahrscheinlich, dass die auf RISC-V basierenden Designs in naher Zukunft an ARM vorbeiziehen. Bei der Stelle gehe es darum, an innovativen RISC-V-Lösungen zu feilen und hochmoderne Routinen in Apples Produkte zu implementieren. Interessenten erwartet eine 40-Stunden-Woche in einem Büro im Apple Park.

Kommentare

andreas_g
andreas_g03.09.21 13:29
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.
+4
tocotronaut03.09.21 13:39
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...
0
Lailaps
Lailaps03.09.21 13:55
In 15 Jahren gibt’s dann den A-RISC-VII oder so ähnlich.
Her mit der Pizza-Mix
-1
antipod
antipod03.09.21 13:59
Lailaps
In 15 Jahren gibt’s dann den A-RISC-VII oder so ähnlich.

Ja... ehm... nö.
+1
karstenl
karstenl03.09.21 14:29
Apple haelt sich wohl wie immer alle Meglichkeiten offen
+1
Wellenbrett03.09.21 15:23
andreas_g
...
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.
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.
+2
Mecki
Mecki03.09.21 15:27
Allerdings gilt es als unwahrscheinlich, dass die auf RISC-V basierenden Designs in naher Zukunft an ARM vorbeiziehen.


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:
+13
andreas_g
andreas_g03.09.21 15:39
@Mecki: Sehr interessant, danke dafür!
+1
Robby55503.09.21 15:43
Vielleicht ist RISC-V eher was für den Apple Serverpark. Auf welche Hardware laufen denn die aktuellen Dienste wie iCloud, Music, ATV+ usw. ?
+1
Mecki
Mecki03.09.21 16:18
Robby555
Vielleicht ist RISC-V eher was für den Apple Serverpark.
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.
+3
Robby55503.09.21 16:25
Mecki
Robby555
Vielleicht ist RISC-V eher was für den Apple Serverpark.
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).

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.
0
Michael Lang aus Rieder03.09.21 16:32
Hier hatt Apple ja früher immer ein Design von PowerVR lizenziert, bis sie angefangen haben selber GPUs zu entwickeln.

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?
0
Mecki
Mecki03.09.21 17:00
Michael Lang aus Rieder
So weit ich weiss basieren die immer noch auf dem (tile basierten) PowerVR Design.
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.
+3
gfhfkgfhfk03.09.21 18:32
Mecki
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.
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.
Mecki
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).
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.
0
Mecki
Mecki03.09.21 19:45
gfhfkgfhfk
Das wäre eher schlecht, da dadurch die Sprungvorhersage beim out-of-order Design komplizierter wird
Also das sieht diese ehemalige ARM Ingenieurin anders, die RISC-V sogar eine deutlich schlechtere Branch Prediction bescheinigt als anderen Architekturen:
x86 und ARM sind halt alte Designs
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."
128Bit Register ersetzen keine SIMD Einheiten
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?
+1
subjore04.09.21 09:45
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.
0
Wellenbrett04.09.21 12:14
andreas_g
@Mecki: Sehr interessant, danke dafür!
Ja, danke auch von mir, Mecki ! Fachlich toll erörtert!
0
AppleUser2013
AppleUser201304.09.21 19:55
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...
0
gfhfkgfhfk05.09.21 09:12
Mecki
Also das sieht diese ehemalige ARM Ingenieurin anders, die RISC-V sogar eine deutlich schlechtere Branch Prediction bescheinigt als anderen Architekturen:
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
// readstruct.c
#include <stddef.h>

struct MyStruct {
        int a;
        int b;
        size_t c;
};

int get_int (struct MyStruct* p) {
        return pb;
}
daraus macht der Aarch64 Crosscompiler
        .arch armv8-a
        .file   "readstruct.c"
        .text
        .align  2
        .p2align 4,,11
        .global get_int
        .type   get_int, %function
get_int:
.LFB0:
        .cfi_startproc
        ldr     w0, [x0, 4]
        ret
        .cfi_endproc
.LFE0:
        .size   get_int, .-get_int
        .ident  "GCC: (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0"
        .section        .note.GNU-stack,"",@progbits
und der RISC-V Crosscompiler
        .file   "readstruct.c"
        .option pic
        .text
        .align  1
        .globl  get_int
        .type   get_int, @function
get_int:
        lw      a0,4(a0)
        ret
        .size   get_int, .-get_int
        .ident  "GCC: (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0"
        .section        .note.GNU-stack,"",@progbits
Das ist ein Nullsummenspiel.
Viel interessanter ist dann etwas realistischer Code
// norm.c
#include <stddef.h>
#include <math.h>

double norm (const double* const vec, const size_t size) {
    double n = 0.0;

    for (size_t i = 0; i < size; ++i) {
        n += vec[i] * vec[i];
    }

    n = sqrt(n);

    return n;
}
Der wird dann für Aarch64 zu
    .arch armv8-a
    .file   "norm.c"
    .text
    .align  2
    .p2align 4,,11
    .global norm
    .type   norm, %function
norm:
.LFB0:
    .cfi_startproc
    movi    d0, #0
    cbz x1, .L2
    add x1, x0, x1, lsl 3
    .p2align 3,,7
.L3:
    ldr d1, [x0], 8
    fmadd   d0, d1, d1, d0
    cmp x1, x0
    bne .L3
    fcmp    d0, #0.0
    bpl .L2
    b   sqrt
    .p2align 2,,3
.L2:
    fsqrt   d0, d0
    ret
    .cfi_endproc
.LFE0:
    .size   norm, .-norm
    .ident  "GCC: (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0"
    .section    .note.GNU-stack,"",@progbits
und für RISC-V zu
    .file   "norm.c"
    .option pic
    .text
    .align  1
    .globl  norm
    .type   norm, @function
norm:
    fmv.d.x fa0,zero
    beq a1,zero,.L2
    slli    a1,a1,3
    add a5,a0,a1
.L3:
    fld fa5,0(a0)
    addi    a0,a0,8
    fmadd.d fa0,fa5,fa5,fa0
    bne a5,a0,.L3
    fmv.d.x fa5,zero
    frflags a4
    flt.d   a5,fa0,fa5
    fsflags a4
    bne a5,zero,.L15
.L2:
    fsqrt.d fa0,fa0
    ret
.L15:
    tail    sqrt@plt
    .size   norm, .-norm
    .ident  "GCC: (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0"
    .section    .note.GNU-stack,"",@progbits
Wo bitte ist da eine deutlich geringer Codedichte zu sehen? Wichtiger sind sichere CPU-Kerne, die keine Bugs wie etwa Meltdown oder Spectre beinhalten.
Mecki
x86 und ARM sind halt alte Designs
Und genau das sagen Experten auch über RISC-V. Zitat:
Ein früherer ARM-Entwickler sagt das. Da besteht die Gefahr, dass die Antwort nicht sonderlich neutral ausfällt.
+1
antipod
antipod06.09.21 10:41
AppleUser2013
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...

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.
0
Mecki
Mecki06.09.21 11:18
gfhfkgfhfk
Wo bitte ist da eine deutlich geringer Codedichte zu sehen?
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.
Ein früherer ARM-Entwickler sagt das.
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?
Da besteht die Gefahr, dass die Antwort nicht sonderlich neutral ausfällt.
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.
-1
antipod
antipod06.09.21 14:07
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.
0
gfhfkgfhfk07.09.21 10:23
Mecki
gfhfkgfhfk
Wo bitte ist da eine deutlich geringer Codedichte zu sehen?
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.
Deine Behauptung war, dass eine RISC Plattform mit Adressierung ohne Offset schlechter sei. Der konkrete Code zeigt das, dass das nicht der Fall ist.
Mecki
Ach ja, und GCC ist bei Codedichte und Optimierung im Allgemeinen LLVM weitgehend unterlegen.
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
    .text
    .file   "norm.c"
    .globl  norm                            // -- Begin function norm
    .p2align    2
    .type   norm,@function
norm:                                   // @norm
    .cfi_startproc
// %bb.0:
    fmov    d0, xzr
    cbz x1, .LBB0_2
.LBB0_1:                                // =>This Inner Loop Header: Depth=1
    ldr d1, [x0], #8
    subs    x1, x1, #1                      // =1
    fmul    d1, d1, d1
    fadd    d0, d0, d1
    b.ne    .LBB0_1
.LBB0_2:
    fsqrt   d1, d0
    fcmp    d1, d1
    b.vs    .LBB0_4
// %bb.3:
    mov v0.16b, v1.16b
    ret
.LBB0_4:
    b   sqrt
.Lfunc_end0:
    .size   norm, .Lfunc_end0-norm
    .cfi_endproc
                                        // -- End function
    .ident  "Ubuntu clang version 12.0.0-3ubuntu1~20.04.3"
    .section    ".note.GNU-stack","",@progbits
    .addrsig
Der GCC 9.3.0 zauber daraus
        .arch armv8-a
        .file   "norm.c"
        .text
        .align  2
        .p2align 3,,7
        .global norm
        .type   norm, %function
norm:
.LFB0:
        .cfi_startproc
        stp     x29, x30, [sp, -32]!
        .cfi_def_cfa_offset 32
        .cfi_offset 29, -32
        .cfi_offset 30, -24
        mov     x29, sp
        str     d8, [sp, 16]
        .cfi_offset 72, -16
        cbz     x1, .L4
        movi    d0, #0
        add     x1, x0, x1, lsl 3
        .p2align 3,,7
.L3:
        ldr     d1, [x0], 8
        fmadd   d0, d1, d1, d0
        cmp     x1, x0
        bne     .L3
        fsqrt   d8, d0
        fcmp    d0, #0.0
        bmi     .L8
.L1:
        fmov    d0, d8
        ldr     d8, [sp, 16]
        ldp     x29, x30, [sp], 32
        .cfi_remember_state
        .cfi_restore 30
        .cfi_restore 29
        .cfi_restore 72
        .cfi_def_cfa_offset 0
        ret
        .p2align 2,,3
.L4:
        .cfi_restore_state
        movi    d8, #0
        fmov    d0, d8
        ldr     d8, [sp, 16]
        ldp     x29, x30, [sp], 32
        .cfi_remember_state
        .cfi_restore 30
        .cfi_restore 29
        .cfi_restore 72
        .cfi_def_cfa_offset 0
        ret
.L8:
        .cfi_restore_state
        bl      sqrt
        b       .L1
        .cfi_endproc
.LFE0:
        .size   norm, .-norm
        .ident  "GCC: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0"
        .section        .note.GNU-stack,"",@progbits
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.
norm.o-pgi:     file format elf64-littleaarch64


Disassembly of section .text:

0000000000000000 <norm>:
   0:    b40000c1     cbz    x1, 18 <norm+0x18>
   4:    f100103f     cmp    x1, #0x4
   8:    540000ea     b.ge    24 <norm+0x24>  // b.tcont
   c:    9e6703e0     fmov    d0, xzr
  10:    aa1f03e9     mov    x9, xzr
  14:    14000013     b    60 <norm+0x60>
  18:    9e6703e0     fmov    d0, xzr
  1c:    1e61c000     fsqrt    d0, d0
  20:    d65f03c0     ret
  24:    6f00e400     movi    v0.2d, #0x0
  28:    aa0103e8     mov    x8, x1
  2c:    aa0003e9     mov    x9, x0
  30:    acc10921     ldp    q1, q2, [x9], #32
  34:    d1000d0a     sub    x10, x8, #0x3
  38:    d1001108     sub    x8, x8, #0x4
  3c:    f100115f     cmp    x10, #0x4
  40:    4e61cc20     fmla    v0.2d, v1.2d, v1.2d
  44:    4e62cc40     fmla    v0.2d, v2.2d, v2.2d
  48:    54ffff4c     b.gt    30 <norm+0x30>
  4c:    4e180401     dup    v1.2d, v0.d[1]
  50:    4e61d400     fadd    v0.2d, v0.2d, v1.2d
  54:    b4000128     cbz    x8, 78 <norm+0x78>
  58:    927ef429     and    x9, x1, #0xfffffffffffffffc
  5c:    aa0803e1     mov    x1, x8
  60:    8b090c08     add    x8, x0, x9, lsl #3
  64:    fc408501     ldr    d1, [x8], #8
  68:    1f410020     fmadd    d0, d1, d1, d0
  6c:    d1000421     sub    x1, x1, #0x1
  70:    f100003f     cmp    x1, #0x0
  74:    54ffff8c     b.gt    64 <norm+0x64>
  78:    1e61c000     fsqrt    d0, d0
  7c:    d65f03c0     ret
Mecki
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.
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.
Mecki
Wie kommst du darauf?
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.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.