Vous le savez, le projet de processeur à jeu d'instructions libre RISC-V ne date pas d'aujourd'hui. Mais, pendant longtemps, il n'y avait pas de moyen facile d'expérimenter avec un tel processeur, en général présent dans de l'embarqué plus ou moins clos ou dans des systèmes peu pratiques pour la programmation, genre tablettes. Les développeur·ses devaient donc se contenter de QEMU ou autre émulateur. Les choses changent et on voit maintenant apparaitre des cartes portant un processeur RISC-V, à un prix supportable. C'est par exemple le cas de la carte Star64, de Pine64, sortie le 4 avril (et déjà toute vendue, il faut attendre le prochain lot).
Évidemment, on peut faire tourner Linux sur cette carte (autrement, je n'oserais même pas en parler ici). Mais attention : tout cela est encore bien expérimental. Aucun des systèmes d'exploitation à noyau Linux habituels ne peut être installé tel quel et facilement. Il faut bricoler un peu et compter sur des volontaires qui fabriquent des images toutes prêtes, ou faire ces images vous-même si vous êtes brave. Donc, ce n'est pas comparable avec, par exemple, le Raspberry Pi : le but n'est pas de « mettre en prod' » tout de suite mais de tester et de développer.
Bon, pour aider un peu, je me suis permis de documenter comment j'ai fait pour démarrer la carte.
Notons aussi que j'ai bien parlé de « processeur à jeu d'instructions libre ». Cela ne veut pas dire que vous aurez les plans du processeur, ni que tous les composants sur la carte soient libres. Mais c'est au moins une bonne étape vers un monde moins dépendant d'Intel et d'ARM.
Journal Une nouvelle carte à processeur RISC-V : la Star64
30
avr.
2023
# Paf
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Premier vote, un -1. Il y a des gens qui n'aiment pas le RISC-V, on dirait.
[^] # Re: Paf
Posté par gUI (Mastodon) . Évalué à 7. Dernière modification le 30 avril 2023 à 20:46.
… ou qui ne t'aiment pas :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Paf
Posté par dj_ (site web personnel) . Évalué à 5.
Peut être une personne qui préfère Stars 80
[^] # Re: Paf
Posté par Micromy (site web personnel) . Évalué à 10.
Ou alors c'est le problème des gros doigts sur ordinophone non RISC V… entrée de suivi sur le sujet des erreurs de pertinentage
[^] # Re: Paf
Posté par flagos . Évalué à 7.
T'es un petit nouveau ici non ? Je sais pas quoi te dire, faudrait penser a proposer du contenu de qualité. /s
[^] # Re: Paf
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 02 mai 2023 à 12:17.
On avait dit qu’on devait être plus bienveillants envers les petits nouveaux non ? Ton message eut gagné à être complété par un sympathique « bisou » pour faire montre de bienveillance et atténuer les dégâts d’une première note négative.
Plus sérieusement, vu la note actuelle du journal, je soupçonne fortement l’effet dévastateur « gros doigt ».
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Paf
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
"Premier vote, un -1"
Linuxfr, c'était mieux avant.
# Achat carte
Posté par Cyprien (site web personnel) . Évalué à 4.
Tu pourrais nous en dire un peu plus sur ton achat ? (Prix, boutique, délai…)
[^] # Re: Achat carte
Posté par Arkem . Évalué à 8.
Si ça peut t'aider, voici la page officielle.
Je ne connais pas le niveau de disponibilité de la carte de Pine64, mais la société qui produit le SOC vend une carte très similaire, et je n'ai pas attendu très longtemps pour recevoir la mienne (moins d'un mois). Je n'ai pas encore eu le temps de bien la tester, mais ça se présente bien à première vue avec l'image expérimentale de Debian. Reste à voir ce que vaudra le suivi du produit…
En tout cas, ça fait plaisir de voir arriver des cartes RISC-V avec les fonctionnalités essentielles d'un PC et à un prix très abordable pour découvrir ce processeur.
[^] # Re: Achat carte
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 9.
Arkem a rappelé que le lien vers la boutique était dans le journal. En euros, ça m'a coûté 75,29 € avec la livraison (de mémoire, ça a pris moins d'une semaine).
# Performance
Posté par tata . Évalué à 4.
À performances égales, qu'est-ce qui est le moins énergivore ? Un processeur Intel, AMD, RISC-V ou PowerPC ?
[^] # Re: Performance
Posté par gUI (Mastodon) . Évalué à 5.
La légende dit que c'est tout sauf Intel, mais quand je vois un cloud à grande majorité Intel et quand on connaît l'importance de la facture d'électricité j'ai comme une doute…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 01 mai 2023 à 11:54.
En terme d'efficacité énergétique pure, le x86(-64) est souvent assez mauvais comparé à d'autres architectures, surtout dars ses implémentations classiques (les gros CPU d'ordinateurs ou de serveurs avec les tonnes d'extensions du jeu d'instructions).
Mais en terme de puissance pure, on arrive à en faire des processeurs extrêmement puissants. Ajoute à ça que c'est un peu "le jeu d'instructions par défaut" pour les ordinateurs et serveurs, donc que la compatibilité est très bonne et que tu n'as pas de problème de cross-compilation pendant le développement (sauf si tu développes en langage compilé directement pour le processeur sur un Mac moderne), et ça explique pourquoi malgré tout on a encore énormément de serveurs, même cloud, en x86(-64). Même si on trouve du cloud en ARM assez facilement maintenant, tout comme des puces ARM franchement puissantes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par gUI (Mastodon) . Évalué à 8.
Justement, des sources ? Je vois souvent du ARM low perf bien meilleur en matière de conso que du x86 high perf, mais pour comparer ce qui est comparable… c'est compliqué !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Performance
Posté par Micromy (site web personnel) . Évalué à 5. Dernière modification le 01 mai 2023 à 17:06.
En cherchant un peu chez Phoronix j'ai trouvé un bench entre un Ampere Altra, un Intel Xeon et un AMD Epyc aux perfs proches datant de décembre 2020 lien.
Globalement celui à utiliser pour vos grillades cet été est l'Epyc. L'Altra et le Xeon sont assez proches en conso, tous les 2 à seulement 60% de la conso de L'AMD.
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Pour les serveurs je pensais à ce test, ou à toutes les offres réellement disponibles, notamment les offres ARM chez Scaleway. Ça c’est les récentes, les anciennes – avec lesquelles Scaleway s’est lancé – étaient notoirement moins puissantes que du x86 type Intel Xeon (côté AMD il n’y avait pas encore d’EPYC et les Opteron étaient obsolètes). Amazon a aussi sorti un processeur pour serveur cloud orienté performances dont la seconde itération a des capacités comparables au x86 mais c’est du spécifique Amazon, je ne crois pas qu’on ait d’informations sur la consommation électrique – et on a encore moins d’analyse indépendante de ce point de vue.
Cela dit tu mets le doigt sur un détail important : historiquement, les CPU ARM sont surtout des CPU orientés consommation (très basse puissance, ou « performance » mais pour appareils mobiles donc avec une consommation tout de même assez réduite), et les CPU x86 sont orienté performance avec quelques gammes (Intel Atom/Avoton par exemple) qui étaient des brouettes qui se faisaient éclater dans tous les tests. C’est moins vrai aujourd’hui, en particulier avec l’arrivée d’ARM dans du matériel haute performance (serveurs – cf le processeur d’Amazon – ou les processeurs des Mac). Le fait qu’on trouve aussi une architecture type big.LITTLE (cœurs haute efficacité et haute performance au sein d’un même CPU) en ARM et en x86 complique encore plus la comparaison.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Cela dit, aujourd’hui, dans les processeurs « à grande disponibilité » (ce qu’on trouve dans le matériel qu’on a chez soi, ou dans un fournisseur de cloud quelconque – et pas seulement l’un d’entre eux) on a encore souvent le choix entre du x86 très performant (surtout en terme de performance par cœur) mais consommateur (en terme de puissance par ~instruction), et de l’ARM plus efficace énergétiquement mais moins performant.
(La limite de temps d’édition est vraiment trop courte, et le message d’erreur vraiment pas terrible)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 02 mai 2023 à 08:36.
C'est le "plus efficace énergétiquement" que je commence à mettre en doute à force de l'entendre partout, mais de jamais le "voir".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Performance
Posté par flagos . Évalué à 4.
J'ai aucun chiffre a donner, mais ma femme possède le mac M1: le processeur est plutot puissant (sur le laptop du boulot j'ai un bon petit Ryzen 7, ca m'a l'air équivalent) mais malgré tout fanless et la batterie dure… longtemps !
Il me semble qu'il y a quand même un écart de consommation sur architecture ARM.
[^] # Re: Performance
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Le problème, c'est que la réponse va dépendre du processeur, pas uniquement du jeu d'instructions (même si, a priori, un jeu RISC est plus efficace énergétiquement). Et c'est encore plus complexe pour le RISC-V, qui a, en raison de son caractère libre, un grand nombre de mises en œuvres très différentes.
[^] # Re: Performance
Posté par gUI (Mastodon) . Évalué à 7. Dernière modification le 02 mai 2023 à 10:10.
Alors de ce que j'ai compris du RISC vs CISC… ça va aussi dépendre du compilateur. Le RISC est fait d'instructions simples dont le but ultime est de tourner en 1 cycle d'horloge, là où le CISC s'autorise des instructions complexes qui peuvent en prendre des dizaines. Mais évidemment, point de magie, il faudra enchaîner plusieurs instructions RISC pour faire l'équivalent d'une instruction CISC, et c'est là où le compilo peut pas mal aider.
Après, il y a belle lurette que les processeurs x86 ont l'équivalent quasi mot pour mot des instructions RISC, et que ces instructions sont largement optimisées au niveau silicium, et privilégiées par les compilos modernes.
Bref, je pense qu'il faut essayer de sortir des clichés qui datent de plusieurs décennies et réévaluer la situation à la fois avec des ARM modernes (qui sont de plus en plus puissants comme le dit SpaceFox) et les x86 modernes qui se sont adaptés en cherchant le low power (la mobilité ayant définitivement changé la donne).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9.
Et encore, ça c’est l’explication simple. En réalité, plus aucun processeur x86 n’implémente ses instructions directement en dur dans le silicium mais via un microcode (plus proche du RISC) non utilisable directement par l’utilisateur et qui peut être patché. D’ailleurs, c’était l’un des problèmes des Intel Atom : certaines instructions x86 étaient codées en dur ou correspondant à des instructions microcodées efficaces sur les CPU standards, mais étaient microcodées avec de longues séries d’instructions inefficaces (mais peu consommatrices) sur les Atom, qui devenaient très mauvais dans certaines tâches bien précises. Inversement, nos CPU de bureau/serveur modernes ont des tonnes d’instructions vectorielles complexes très optimisées (et potentiellement très consommatrices, comme AVX512. On ajoute à ça les phénomènes de cache et surtout les pipelines internes aux CPU, les moteurs d’exécution dans le désordre et on peut avoir une efficacité globale supérieure à une instruction par cycle d’horloge.
Quoi qu’il en soit, parler de RISC ou de CISC aujourd’hui n’a plus vraiment de sens, sauf peut-être pour désigner la taille d’un jeu d’instruction précis. Surtout, ça n’a plus aucun lien avec la complexité réelle d’un CPU physique, ni avec son éventuelle efficacité énergétique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par krumtrash . Évalué à 6.
Confirmé par ce site spécialisé : https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/
[^] # Re: Performance
Posté par volts . Évalué à 6.
En revanche, si on s'amuse à transposer les grandes familles d'architecture sur des puces reprogrammables de type FPGA, il y a moyen de mesurer plus objectivement la consommation d'énergie sur les différentes implémentations de RISC-V et celles des autres, non ?
Ce projet remarqué par le fabriquant bulgare Olimex m'a l'air intéressant pour préparer un banc de test sur les différentes implémentations.
[^] # Re: Performance
Posté par Selso (site web personnel) . Évalué à 1.
Ca vaut ce que ca vaut mais j'ai eu l'opportunité de me pencher sur la question lorsque j'ai voulu implémenter un petit serveur avec un zotac AMD vs un macbook pro 2009 (intel). J'ai utilise un de ces watmetres avec prise mural.
Sans rien faire niveau conso le macbook faisait mieux.
J'ai ensuite installé TLP sur le zotac et forcé le mode batterie pour arriver dans les même conditions de consommation.
L'optimisation de la consommation est loin de se concentrer sur le CPU, preuve en est cette page ArchWiki sur le sujet.
Mais dans ces essais j'ai trouvé beaucoup de réponse côté Intel. J'en ai déduis que ce n'était pas un critère différenciant AMD / Intel.
Le mieux classé pour moi serait ARM, cela expliquerait pourquoi c'est l'architecture la plus utilisée dans les mobiles et embarqué ;).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.