Vous avez sans doute déjà entendu parler de ARM, les petites puces qui colonisent nos téléphones. Mais qu’en est-il de RISC-V ?
Le RISC-V n’étant pas propriétaire, le niveau d’investissment nécessaire pour atteindre la même performance et qualité que l’architecture ARM serait colossale avec un risque (sans jeu de mot) sur sa soutenabilité.
L’article ne mentionne pas le procès ouvert entre Qualcomm (la source de l’article) et ARM qui lui réclame plusieurs milliards. Qualcomm (mauvais payeur ?) a donc tout intérêt à « casser » le business de son ancien partenaire…
Et Google fait toujours tout pour ne pas payer les autres tout en les obligeant à le faire…
3 « J'aime »
Le RISC-V n’étant pas propriétaire, le niveau d’investissment nécessaire pour atteindre la même performance et qualité que l’architecture ARM serait colossale avec un risque (sans jeu de mot) sur sa soutenabilité.
Alors, oui et non.
Il faut comprendre que ce qui est « open » dans Risc V, c’est le jeu d’instruction.
Et ça intéresse les plus gros acteurs qui n’en ont plus rien à faire d’acheter les design de puces ARM parce qu’ils ont assez d’ingénieurs compétents pour concevoir leur propre processeurs et apporter leurs optimisations.
Il est assez compréhensible que ceux qui conçoivent leur propre design n’ont pas envie de payer juste pour être compatible avec un jeu d’instruction.
Bah ça parle déjà en milliards pour les royalties. Donc, en mettre quelques uns dans le développement du risc-v pour ensuite être libéré, c’est évidemment un bon calcul. Je suis quasi certain que dans moins d’un an, on en aura déjà dans nos téléphones et raspberry pi like
1 « J'aime »
Ah oui ? Et pourquoi ?
En performances, les puces RISC sont déjà au niveau de beaucoup d’ARMs :
As depicted in the illustration, ARM’s Cortex-A78 marginally outpaces the SiFive’s P670 (using RISC-V) in peak single-thread performance. Despite the Cortex-A78’s supremacy in raw performance, the P670 boasts twice the compute density compared to it. Hence, SiFive’s P670 processor yields comparable peak single-thread performance to Cortex-A78, considering its chip being physically half the size of its rival.It’s noteworthy that the Cortex-A78 was introduced in December 2020 through the Vivo X60 and X60 Pro, while the P670 was recently unveiled on November 1, 2022, indicating a nearly two-year disparity in research and development. ARM’s latest processors now operate on the ARMv9 ISA, a substantial improvement over the Cortex-A78’s ARMv8. Notably, ARMv9 processors offer around 30% higher performance and are 50% more energy-efficient.
In terms of pure performance, ARM processors maintain their lead. However, SiFive’s P670, with its double compute density over Cortex-A78, positions RISC-V processors advantageously for wearable technologies that thrive on compact processors.
2 « J'aime »
« moins gourmands en énergie que les processeurs Intel, que l’on trouve dans nos PC » => Il n’y a pas qu’Intel dans nos PC…
2 « J'aime »
L’année prochaine, une carte mère de desktop a été annoncée avec un proc RISC-V.
De plus, le pilote AMDGPU a été porté dans les dernières versions de Linux sur l’architecture RISC-V … en français, on va pouvoir mettre les dernières Radeon sur des machines RISC-V 
3 « J'aime »
EN-FIN !
RISC-V est une ISA (Instructions Set Architecture) ouverte, dont le but est d’offrir un jeu d’instructions moderne adapté aux technologies récentes.
3 « J'aime »
la bonne phrase aurait probablement du être X86 à la place d’intel
3 « J'aime »
Pourquoi ne pas mettre processeurs X86 plutôt que processeurs Intel? Je sais, ce n’est qu’un détail.
2 « J'aime »
Cela existe déjà en tant que Raspberry Pi like.
Ces processeurs ARM, qui sont plus simples et moins gourmands en énergie que les processeurs Intel
Là tu sais que t’as affaire à un spécialiste qui rédige l’article… 
1 « J'aime »
Les plus jeunes ne s’en souviennent pas mais peros j’avais fait mon doctorat sur une machine Acorn Risc Machine 5000
PS: Attention, l’acronyme est ARM mais le proc était bien de type RISC
1 « J'aime »
Oui, de type RISC, comme tous les CPU ARM, car le ARM actuel, c’est bien Acorn Risc Machine. Et Acorn Risc Machine n’a rien à voir avec RISC-V (qui est un projet universitaire à la base).
RISC « tout court », c’est juste une grande famille de processseurs : Reduced Instruction Set Computer. Dedans, il y a les CPU ARM, les Power d’IBM, les Sparc de Sun, les RISC-V, et bien d’autres… Ils ont en commun le principe d’avoir un jeu d’instruction relativement simple, avec peu de modes d’adressage différents. Par contre bien qu’ils soient tous de la même famille, ils ont chacun leur propre jeu d’instruction, et sont donc totalement incompatibles entre eux.
Ça s’oppose à l’autre grande famille (et il y a des familles plus petites aussi, comme les VLIW), les CISC, Complex Instruction Set Computer. En CISC, on trouve principalement les x86 aujourd’hui, mais il y en a d’autres aussi par le passé, comme les fameux Z80 et Motorola 68k.
RISC-V est donc une ISA particulière de la famille RISC, et Acorn RISC Machine n’a strictement rien à voir avec RISC-V, mais a par contre tout a voir avec ARM, dont c’est la maison mère.
À noter qu’en pratique aujourd’hui la frontière est devenue très flou : sur l’ISA externe, c’est relativement clair de déterminer qui est RISC et qui est CISC, mais en interne, quasiment tous les CPU d’aujourd’hui ont un étage de décodage/traduction/fusion qui converti le flux d’instructions de l’ISA externe en un flux d’instructions de l’ISA internet du CPU, qui peut être de type différent… Les premiers Pentium avaient par exemple une ISA interne qui était plutôt de type RISC, tandis qu’aujourd’hui les CPU sont très souvent des VLIW en interne : les instructions sont d’abord traduites en micro instructions, avec une ISA plutôt RISC, mais ces micro-instructions sont ensuite fusionnées en macro-instructions qui vont s’exécuter en parallèle, ce qui est le principe de base des VLIW… la différence étant que la fusion est du coup gérée par le processeur en interne, alors que sur un CPU VLIW c’est l’ISA externe qui est VLIW, et c’est donc le compilateur qui doit faire les fusions).
1 « J'aime »
Merci pour ces détails intéressants 
@MattS32 un grand merci pour toutes ces précisions ! ( en espérant qu’il n’y ait pas d’erreur mais j’aurais un peu de mal à vérifier )
Dans cette histoire, la migration est longue et coûteuse non ? Il faut recompiler toutes les applis qui embarquent du C/C++, Les distribuer en 2 versions, un peu comme avec Windows Mobile qui ne supportait qu’une petite partie des programmes windows.
Est-ce que ça va simplifier la fabrication de CPU pour la Chine que les US tentent de bloquer ouvertement ? On dirait qu’ils veulent une nouvelle guerre froide
Il peut y avoir une couche d’émulation, comme c’est le cas aujourd’hui par exemple sur les appareils Windows et macOS ARM, qui embarquent un émulateur x86.
Dans le cas d’une émulation ARM sur RISC-V la perte de performances serait sans doute même très inférieure à ce qu’elle est en x86 sur ARM, car émuler du RISC sur du RISC (on a grosso modo les mêmes principes « câblés » dans le CPU) est bien plus simple qu’émuler du CISC sur du RISC (il faut traduire « logiciellement » des fonctions avancées qui sont câblées dans le CPU CISC, comme les instructions complexes, les modes d’adressage parfois très alambiqués…).
1/ Sur un téléphone de 200€, la baisse de prix serait de combien d’€ ?
2/ le Risk-V qui est devenu obèse d’instructions comment peut-il encore être Risk (le Ris c’est Reduced instructions set)
3/ combien de transistors dans un CPU Risk, car l’objectif est de réduire son nombre me semble t’il ?
4/ pourquoi tout en 64bits, la plus grande partie des algo n’en ont pas besoin, il me semble ? Un octo cpu de 8bits capable de fusionner tout ou partie en 16, 32 ou 64. Ça permettrait de faire plus d’instructions par seconde
Un processeur 64 bits uniquement, ça ne veut pas dire qu’il n’est pas capable de travailler avec des opérandes plus petites. Ça veut juste dire que l’adressage mémoire est obligatoirement en 64 bits.
Mais si tu regardes la spécifications du jeu d’instructions RV64I, tu verras qu’il y a bien dedans des instructions travaillant avec des opérandes inférieures à 64 bit. Par exemple : « The SD, SW, SH, and SB instructions store 64-bit, 32-bit, 16-bit, and 8-bit
values from the low bits of register rs2 to memory respectively. ».
Pour une archi « nouvelle » qui n’est pas encore largement diffusée, ce n’est pas un problème de faire ça, puisqu’il n’y a pas d’historique logiciel compilé en 32 bits.
Et ça permet de simplifier un peu le design de la puce, puisqu’il n’y a plus besoin de gérer les différents modes.
Par contre, travailler sur des opérandes plus petites ne veut pas forcément dire en faire plus en parallèle… Un additionneur 64 bits par exemple ne peut pas traiter 8 additions 8 bits en un cycle (les retenues sur une addition « déborderaient » sur celle d’à côté), sauf a être conçu spécifiquement (donc plus complexe) pour optionnellement ne pas propager les retenues de rang multiple de 8… (c’est ce que savent faire les unités vectorielles… mais c’est probablement pas très pertinent de le faire dans une ALU de base). De même 8 additionneurs 8 bits ne peuvent pas traiter en un cycle une addition 64 bits (toujours un problème de retenue : 8 additionneurs 8 bits peuvent faire une addition 64 bits, mais l’additionneur n+1 a besoin pour son calcul de la retenue de l’additionneur n, donc il doit attendre un cycle).