Journal Le début de la fin pour Intel ?

Posté par Ontologia (site web personnel) le 31 août 2020 à 22:45. Licence CC By‑SA.

Étiquettes :

août

2020

Sommaire

Apple a récemment officiellement annoncé ce qui se tramait depuis longtemps : les Macbook vont passer sur architecture ARM. Vous allez me dire que vous vous en fichez, puisqu'Apple cédéméchan çapucépalibre.
Mais des signaux plus ou moins faibles indiquent ça et là qu'Intel est mal barré.
Exposé des faits

1. Apple lâche Intel, mais on le savait

Les rumeurs sur le lâchage d'Intel par Apple bruissait depuis longtemps. Qui plus est, l'utilisation de plus en plus fréquente de leur propres puces ARM sur les segments les plus bénéficiaires de marché pour la pomme indiquait le chemin.
Depuis l'officialisation, on a appris que le mouvement est venu d'en bas. En effet, dû à des gros bugs chez Intel SkyLake, les ingénieurs d'Apple ont eu envie de switcher : ils trouvaient autant de bugs que les ingénieurs d'Intel. C'est balo… Et ça la fout mal quand même. Ça me rappelle une appli développée par une SSII.
Ce sont eux qui ont frais pression sur la direction, en mode "c'est plus possible". Ils ont finalement eu gain de cause.
Ce switch ne va pas changer grand chose pour Intel en terme de carnet de commande : les CPU du Mac équivalent à à peine 12% du marché PC voire moins. Le gros des marges d'Intel, ce sont les datacenters avec un marché qui s’agrandit chaque année (+40% en un an).

D'après Jean-Louis Gassée, ancien de la firme à Wozniak, c'est mal barré pour Intel, car si les précédentes tentatives de Switch par Microsoft ce sont soldées par un échec, celle-ci est de loin bien mieux préparée. Car c'est essentiellement l'émulation x86 sur ARM qui pose problème : Microsoft comme Apple use de cet artifice pour faire marcher les applis x86 sur des machines ARM. Mais dans le cas de la surface X, que Microsoft a mis sur le marché, j'ai un peu de mal à comprendre pourquoi ils n'ont pas tout simplement recompilé la suite Office, qui était affreusement lente à cause de l'émulation. Car c'était en effet une émulation du type JIT, et c'est de là que leurs problèmes sont venus.
De son côté le switch pommesque, préparé de longue date, et l'"émulation" d'applis x86_64 sur ARM, Rosetta 2, a l'air d'avoir d'excellentes performances.. Pour une raison simple : c'est un compilateur, pas un JIT.
Quelques benchmarks agitent le landerneau et laissent à penser que même via Rosetta 2, les performances ne seront pas horribles : on se retrouve au coude à coude avec un Macbook Air.
Qui plus est, les Mac pourront exécuter toutes les applis de l'écosystème Apple, iPhone compris.

Apple a pris le temps de maitriser son architecture ARM tranquillement et d'avoir des apps qui fonctionne sur son système, comme les apps sont dans l'écrasante majorité développées avec Xcode, une simple recompilation suffira.
Je pense que c'est cela qui assurera leur succès.

2. François PiedNoël : How to fix Intel ?

Ancien "Performance Guru OF Chipzilla" aka ingénieur principal d'Intel, un français qui a participé et conçues toutes les archis Intel x86 de 1997 à 2017 pense qu'Intel va dans le mur résumé ici vidéo là
Plusieurs éléments ressortent de sa passionnante présentation d'une heure avec son accent français à couper au couteau :

L'AVX512 est une mauvaise idée, il prend 10% du die pour rien, car très peu utilisé. Cette approche ultra-vectorielle a perdu contre celles des GPU. En même temps quand on voit la gueule des instructions, on comprend, je préfère me prendre la tête à coder du GPU. J'ajouterai qu'avec des langages comme Futhark, la palanquée de libs existante pour les GPU, le match est perdu d'avance. Autant réserver 10% du die à mettre un petit GPU pour exécuter de l'OpenCL…. Qui plus est l'AVX512 est décliné partout, des processeurs pour portables à ceux des datacenters. Il y a fortement à parier qu'il n'est jamais utilisé.
Utiliser AVX512 dans des puces grand publics, portable en particulier là où il n'est que rarement utilisé est stupide en terme de rendement énergétique
Linus a déclaré, avec son franc-parler habituel : « J'espère que l'AVX512 mourra d'une mort douloureuse, et qu'Intel commencera à régler les vrais problèmes au lieu d'essayer de créer des instructions magiques pour ensuite créer des standards sur lesquels ils pourront se reposer »
Intel réduit ses fréquences d'horloge à cause d'AVX512 (voir plus loin)
Les dirigeants d'Intel ne sont plus des ingénieurs mais des MBAs, d'après Piednoël, ils ne comprennent plus rien au marché. Les employés sont démotivés.
Pendant qu'Intel a été occupé à acheter des startups, AMD a eu le temps de progresser, et les derniers Ryzen sont excellent.
Intel ne se fait pas défoncer par AMD à cause des capacités limitées d'AMD en production, dépendant qu'ils sont de TSMC
Skylake a été conçu pour le monothread puis ensuite amélioré pour le multicoeur au fur et à mesure.

J'ajoute que AMD, ayant les archis Radeon à disposition peuvent vraiment faire du mix CPU/GPU, même s'ils sont à la traine derrière NVidia.

2.1. Un petit point sur AVX512

Quand on creuse un peu, on se rend compte que l'AVX512 n'est pas anodin pour le processeur, l'utiliser l'oblige à changer de fréquence et de voltage
C'est bien expliqué ici (traduction libre) :

On paie un coût pour [l'AVX512] dans le sens où la fréquence baisse si on exécute beaucoup de code AVX[…] Le problème avec les horloges AVX2 / AVX512 avec Intel n'est pas le fait qu'elles doivent cadencer plus bas pour les utiliser (pour du code AVX pur, traiter plus de données mais à une vitesse d'horloge inférieure en vaut toujours la peine !), C'est que le processeur doivent cadencer plus bas préventivement pour de telles instructions, et doit rester à cette fréquence inférieure pendant un certain temps. Cela signifie que le code qui s'exécute de temps en temps avec quelques instructions AVX mélangées avec beaucoup de code entier doit exécuter l'ensemble du programme à des fréquences inférieures.
En revanche, AMD gère l'alimentation de sa puce à partir d'un énorme MIMCAP (Metal Insulator Metal capacitor NDR) intégré à la puce, ce qui signifie qu'ils ont une marge pour pouvoir commencer à exécuter des instructions extrêmement gourmandes en énergie, et ne synchroniser de manière réactive que si cela est réellement nécessaire. Et gère le changement de fréquence à la baisse et la hausse avec une granularité beaucoup plus fine, et de manière beaucoup plus réactive.

Ceci est constaté avec des Benchs montrant qu'AVX2 a tendance à faire baisser les perfs générales du processeur quand on l'utilise conjointement avec autre chose.

3. Lakefield : porte de sortie ?

Intel essaie tout de même de trouver sa voie : les MBAs dirigeant la boite ont décidés de se concentrer sur l'architecture Lakefield qui est une application big.LITTLE d'ARM : des cœurs orienté perfs à côté de cœurs orienté économie d'énergie (issu des architectures Atom). Avec cette nouvelle architecture, Intel inaugure avec ce processeur le passage à la 3D sur la gravure : 12x12x1mm (!) d'épaisseur.
Il possède pas mal de features qu'on trouve sur des processeurs ARM pour mobile : Wifi/4G intégrée, GPU avec gestion d'écrans (4) 4K, gestion de caméras, fréquence variant de 0,8Ghz à 2,8Ghz, et il comportera aussi… sa propre RAM.
L'histoire ne nous dis pas s'il y a AVX512 ;-)
Tout cela va être empilé sur un die, permettant d'éviter une carte mère complète.

4. La fin de la nécessité du Out of Order ?

C'est une conviction que j'ai depuis longtemps : les incantations vaudou sur le code alors les compilateurs sont capable parfaitement capables d'optimiser eux-même le code (ceux qui me connaissent de longue date ici connaissent mon passé à ce propos) vont forcément disparaitre un jour, et plus que les avancées de GCC, du Intel C Compiler, c'est surtout Clang à mon sens, qui est en train de tuer la nécessité de tuer le Out Of Order : les compilateurs deviennent assez malin, on a assez de puissance de calcul pour optimiser au mieux le code et précalculer les dépendances read-after-write.
C'est aussi l'avis de F. Piednoel, qui partage cette opinion lorsque je la lui ai exposé.
À moins que tous les sites codées en NodeJS sauvent Intel ? X-D
Mais peut-être certains d'entre vous auront des avis divergents sur ce point, ça m'intéresse ;-)

Bref, m'est impression que les x86 d'Intel, descendant directs des archis Pentium, consomment énormément de transistors à descendre les IPC à moins de 1, avec le out of order, les multiples unités d'exécutions, les multiples niveaux de pipelines qui ont conduit à l'échec du Pentium 4 (20 étages !). Or tout cela, avec la progression des compilateurs va devenir de plus en plus inutile. Intel y a cru pourtant, avec Itanium, mais c'était trop tôt, et l'archi état trop complexe (VLIW)

Conclusion

A l'heure où les IPC sont autour et en dessous de 1 depuis longtemps, quel point de salut en dehors du massivement multi-coeur ?
Est-ce qu'ARM va tous nous bouffer ? Enfin celui à qui il va appartenir (NVidia ?)
Comment Intel va t-il se sortir de ce guêpier ? Sachant que pour le marché des datacenters, avec la fin de la nécessité du out of order, qu'auront-ils à offrir face à AMD ?

# Out of order

Posté par pulkomandy (site web personnel, Mastodon) le 31 août 2020 à 23:37. Évalué à 10.

Pour l'exécution out of order, faire l'ordonnancement dans le compilateur fonctionne bien quand on cible un cpu spécifique. Le problème, c'est que le code ainsi optimisé ne sera peut-être pas optimal sur une autre architecture (nouvelle génération, puce développée par un concurrent…). C'est pour ça que le cpu se permet d'intervenir.

C'est sûr que si on réfléchit en terme d'une architecture cible stable et bien connue, plein de choses pourraient être faites complètement en statique. Par exemple on pourrait laisser le compilateur gérer lui-même la mémoire cache. Sauf que si le compilateur optimise pour 1Mo de cache et que la génération de cpu suivante en a 2Mo, ce code ne l'exploitera pas. Et du coup les gains de performance ne seront pas trop visibles.
- [^] # Re: Out of order
  
  Posté par barmic 🦦 le 31 août 2020 à 23:55. Évalué à 7.
  
  Est-ce que c'est un intérêt pour le JIT ou les contraintes de performance de compilation de JIT empêche d'avoir ce genre d'optimisation.
  
  Sinon il faut, (comme le fait android maintenant et c'est ce que peuvent proposer les distributions "sources" comme gentoo) une compilation à l'installation
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Out of order
    
    Posté par devnewton 🍺 (site web personnel) le 01 septembre 2020 à 09:32. Évalué à 9.
    
    Il faudrait du JAI (Just at install) !
    
    Avec un cache bien sûr, parce que les compilations à la Gentoo c'est bien pour chauffer en hiver, mais c'est un poil long.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Out of order
      
      Posté par claudex le 01 septembre 2020 à 09:33. Évalué à 8.
      
      Il faudrait du JAI (Just at install) !
      
      C'est ce que fait C# ou Android.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Out of order
      
      Posté par barmic 🦦 le 01 septembre 2020 à 09:45. Évalué à 5.
      
      Alors android utilise les 3 il me semble. La compilation AOT doit permettre d'alléger la compilation à l'installation.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: Out of order
        
        Posté par tao popus le 11 septembre 2020 à 10:39. Évalué à 2.
        
        Et consommé plusieurs tranches de centrales thermiques (nucléaires ou charbon) en plus, pour tous ces périphériques qui compilent fréquemment (à chaque nouvelle installation et mise à jour).
- [^] # Re: Out of order
  
  Posté par claudex le 01 septembre 2020 à 09:25. Évalué à 8.
  
  Combien de temps il faudrait entre la sortie d'un processeur et la sortie de la version du compilateur qui gère ça aussi bien de l'out of order du CPU ?
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Out of order
    
    Posté par flan (site web personnel) le 01 septembre 2020 à 19:56. Évalué à 4. Dernière modification le 01 septembre 2020 à 19:56.
    
    Le problème est surtout que ça implique d'avoir une compilation différente par version du processeur.
    - [^] # Re: Out of order
      
      Posté par groumly le 01 septembre 2020 à 23:00. Évalué à 6.
      
      Apple a imposé bitcode précisément pour cette raison. C’est horriblement documenté, donc c’est très dur de savoir ce qu’ils font précisément avec ça, mais c’est typiquement le genre de choses qu’ils pourrait faire avec, a savoir recompiler le code optimise finement pour chaque device.
      Ils optimisent déjà les bundles en ne gardant que les assets nécessaires.
      Va savoir ce qu’ils ont dans leur roadmap cpu, mais vu l’écart entre un iPhone et un Mac Pro, je serais pas surpris qu’ils ait sorti ça longtemps en avance pour l’avoir dispo sur l’intégralité du store au moment de la transition arm.
      
      Apres, ça fout complètement en l’air les dsyms, et vu la qualité risible de leur crash reporter, j’ai vraiment pas envie de l’utiliser.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Out of order
        
        Posté par pulkomandy (site web personnel, Mastodon) le 02 septembre 2020 à 20:08. Évalué à 7.
        
        En poussant les choses un peu loin dans cette direction on a Java: le compilateur (javac) traduit le code Java en bytecode complètement générique et fait assez peu d'optimisations. Et laisse la machine virtuelle se débrouiller pour optimiser les choses pour la machine sur laquelle le code s'exécute en mettant en oeuvre les stratégies appropriées: JIT ou pas, différentes possibilités de garbage collector, mise en cache du code compilé définitif, …
        
        L'inconvénient c'est qu'un code qui s'exécute très bien dans un cas peut devenir très lent dans un autre, et c'est souvent assez obscur à débugger quand il faut comprendre pourquoi.
        
        [^] # Re: Out of order
        
        Posté par bayo le 20 septembre 2020 à 17:00. Évalué à 2.
        
        C'est la tendance. Le meilleur des deux mondes. On retrouve ça dans le web avec webassembly, et sur les cartes vidéo avec SPIR-V.
        
        [^] # Re: Out of order
        
        Posté par Thomas Debesse (site web personnel) le 22 septembre 2020 à 21:41. Évalué à 5.
        
        En fait WebAssembly est mal nommé, il y a “Web” dedans parce que les premiers clients sont des gens qui font du web, ce sont eux qui poussent le plus. Il est prévu par exemple que pour Unvanquished nous passions de NaCl à Wasm pour le code du jeu qui peut-être téléchargé depuis un serveur, et qui doit donc tourner sur toutes les plate-formes supportées et dans un bac à sable. Native Client était une technologie précédent WebAssembly qui était initialement développée pour le navigateur Google Chrome, mais qui là encore, a pu servir en dehors du web.
        
        Il y a plusieurs projets comme Wasmer, Wasmtime et d’autres pour faire tourner du code WASM sur n’importe quelle machine en dehors du navigateur. Il y a même un projet pour faire tourner du code Wasm directement dans le noyau.
        
        Donc bref, mon commentaire n’enlève rien au tiens au contraire il l’appuie : c’est la tendance. Et en fait on retrouve ça plus loin que le web.
        
        ce commentaire est sous licence cc by 4 et précédentes
      - [^] # Re: Out of order
        
        Posté par Frank-N-Furter le 03 septembre 2020 à 15:59. Évalué à 2.
        
        Depuis quelques années tout ce qui est nouveau est horriblement documenté chez apple, je trouve.
        
        Depending on the time of day, the French go either way.
        
        [^] # Re: Out of order
        
        Posté par groumly le 03 septembre 2020 à 17:21. Évalué à 4.
        
        Depuis quasiment toujours en fait. C’est juste que les applis tierces ont beaucoup évolué en complexité et en finition, et plus le temps passe plus ça devient problématique.
        Mais oui, ça va en s’empirant.
        
        Pour être tout à fait honnête, ya à boire et à manger, ça dépends pas mal de la team qui a pondu le code. J’ai passé pas mal de temps sur les app clips récemment, et ça va là dessus. Enfin, sauf pour un des points les plus importants (taille max du binaire), ou il a fallu demander à WWDR à quoi elle s’appliquait.
        J’ai aussi bossé sur des trucs semi privés, et la seule doc, c’est les headers. Apple a pas une culture d’expliquer à tout le monde ce qu’il font.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Questions

Posté par barmic 🦦 le 31 août 2020 à 23:46. Évalué à 4.

j'ai un peu de mal à comprendre pourquoi ils n'ont pas tout simplement recompilé la suite Office

L'age de la base de code ? Je ne sais pas comment ils s'en sortent, mais MS Office a un historique bien plus long que la majorité des applications d'Apple.

Ensuite MS et Apple n'ont pas la même position, Apple étant dominant sur ce marché, il peu prendre le temps là où MS doit gérer un time to market plutôt court pour ce faire une place.

Apple a pris le temps de maitriser son architecture ARM tranquillement et d'avoir des apps qui fonctionne sur son système, comme les apps sont dans l'écrasante majorité développées avec Xcode, une simple recompilation suffira.

Je n'ai jamais utilisé Xcode, mais en quoi l'éditeur de code est impliqué ? Les portages ne semblent pas triviaux vu qu'Apple a annoncer vouloir aider les projets open source à faire leur portage.

Bref, m'est impression que les x86 d'Intel, descendant directs des archis Pentium, consomment énormément de transistors à descendre les IPC à moins de 1[…]

IPC chez moi c'est Inter Process Communication, chez toi ça veut dire quoi ?

Les dirigeants d'Intel ne sont plus des ingénieurs mais des MBAs, d'après Piednoël, ils ne comprennent plus rien au marché.

MBA c'est mon trigramme dans mon entreprise, mais je doute que c'est de ça dont il est question…

Un ingénieur ça connaît le marché ?

Comment Intel va t-il se sortir de ce guêpier ?

Ils ont encore de quoi tenir suffisamment longtemps pour se retourner. Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça. Intel serait déjà mort, Microsoft aussi, Apple aussi, AMD pareil, Facebook n'en parlons pas,…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Questions
  
  Posté par Ontologia (site web personnel) le 01 septembre 2020 à 00:35. Évalué à 7.
  
  IPC chez moi c'est Inter Process Communication, chez toi ça veut dire quoi ?
  
  Instruction par cycle (Instruction Per Cycle)
  
  Ils ont encore de quoi tenir suffisamment longtemps pour se retourner. Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça. Intel serait déjà mort, Microsoft aussi, Apple aussi, AMD pareil, Facebook n'en parlons pas,…
  
  Je suis comme toi, et c'est pour ça que j'ai posé la question plutôt qu'affirmer que c'était la fin pour Intel. Mais je me demande comment ils vont faire….
  
  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: Questions
  
  Posté par groumly le 01 septembre 2020 à 03:57. Évalué à 10.
  
  Les portages ne semblent pas triviaux vu qu'Apple a annoncer vouloir aider les projets open source à faire leur portage.
  
  Ca depend lesquels. Une très très grosse majorité des applis importantes sur macOS ont très peu, voir aucun, de code spécifique x86.
  Une simple recompilation et ca repart. J'en ai vu quelques un faire les coqs sur twitter a ce sujet. Et il me semble qu'un des studios de jeux (pas epic du coup…) qui était la pour la demo disait qu'ils avaient un build macOS ARM en moins de qq heures.
  
  La ou Apple a offert d'aider c'est sur le code assembleur, les changements bas niveau (me rappelle avoir vu passer des threads twitter la dessus, en gros des applis qui faisait des assomptions erronées sur certains comportements du système qui petent avec le passage a ARM). Et j'imagine aussi sur les scripts de builds.
  En gros, ca fait plus de 10 ans que tout le monde part du principe que si ca build pour macOS, c'est forcement x86, et que donc si ca build pour arm, c'est forcement pour iOS.
  Entre les #if arch(x86_64) qui veulent vraiment dire #if targetEnvironment(simulator) et les builds de script qui déterminent la platforme a partir de l'archi du CPU, ya un certain nombre de librairies multiplateformes dont les builds vont peter.
  Genre libgit2 (ou plutot, les scripts d'objective-git2 pour libgit2) est plein a craquer de ce genre de choses. J'ai deja galeré pour sortir un build catalyst (donc iOS ARM + iOS sim x86 + macOS x86) dans un xcframework, je m'approche pas de ce script pour macOS ARM.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Questions
    
    Posté par barmic 🦦 le 01 septembre 2020 à 09:15. Évalué à 4.
    
    qui déterminent la platforme a partir de l'archi du CPU
    
    Ah ! Oui effectivement je comprends mieux de quoi il s'agit. Je n'y ai pas pensé de prime abord.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Questions
    
    Posté par pulkomandy (site web personnel, Mastodon) le 01 septembre 2020 à 10:57. Évalué à 6.
    
    Je crois qu'un des problèmes est le passage de 4K à 16K pour la taille des pages mémoire du MMU. A priori on se dit que ça devrait pas être bien important pour les applications, mais en fait, beaucoup d'applis qui ont besoin d'un peu de performance ont probablement réécrit leur propre allocateur mémoire par exemple. Et c'est pas du code qu'on modifie sans faire bien attention à ce qu'on fait, en général.
    
    Et c'est probablement juste un exemple de truc qui change. C'est pas exclu que les devs d'Apple aient aussi profité de l'occasion pour supprimer plein de vieilles APIs inutiles au passage?
  - [^] # Re: Questions
    
    Posté par Ontologia (site web personnel) le 03 septembre 2020 à 01:05. Évalué à 3.
    
    En gros, ca fait plus de 10 ans que tout le monde part du principe que si ca build pour macOS, c'est forcement x86, et que donc si ca build pour arm, c'est forcement pour iOS.
    Entre les #if arch(x86_64) qui veulent vraiment dire #if targetEnvironment(simulator) et les builds de script qui déterminent la platforme a partir de l'archi du CPU, ya un certain nombre de librairies multiplateformes dont les builds vont peter.
    
    Ce qui m’inquiète un peu, c'est tout les macports et autres brew : ok, on a déjà pas mal de softs qui tournent grâce à Debian ARM, mais il va y avoir tout de même du boulot pour que tout tourne. Les contributeurs de macport vont avoir du pain sur la planche…
    
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: Questions
  
  Posté par Colin Pitrat (site web personnel) le 01 septembre 2020 à 08:56. Évalué à 0. Dernière modification le 01 septembre 2020 à 08:57.
  
  Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça.
  
  Tu ne devrais pas, toutes les entreprises que tu as cité vont bientôt mourir. Ce sera peut-être après moi et même après mes enfants. Mais à l'échelle de l'univers c'est sur, elles vont bientôt mourir.
  
  "Cela aussi passera"
  - [^] # Re: Questions
    
    Posté par Colin Pitrat (site web personnel) le 01 septembre 2020 à 09:04. Évalué à 10.
    
    Pour l'anecdote, je me souviens de discussions avec d'autres libristes il y a 15 ans qui disaient que Microsoft était bientôt mort. Les parts de marché d'IE chutaient et même si ça ne rapportait rien à MS, c'était le signe d'un changement. OpenOffice suivrait, puis Linux et les revenus de Microsoft chuteraient à une telle vitesse qu'ils n'auraient pas le temps de réagir.
    
    Les prédictions, c'est comme les promesses, ça n'engage que ceux qui y croient.
    - [^] # Re: Questions
      
      Posté par steph1978 le 01 septembre 2020 à 21:26. Évalué à 7.
      
      Ce ne sont pas tant des prédictions que des souhaits.
- [^] # Re: Questions
  
  Posté par Zenitram (site web personnel) le 01 septembre 2020 à 09:31. Évalué à 8.
  
  Je n'ai jamais utilisé Xcode, mais en quoi l'éditeur de code est impliqué ?
  
  Xcode fait pas mal de choses, y compris permettre de compiler plusieurs architectures sans se prendre la tête (en gros : un binaire unique avec plusieurs architectures) et balancer le tout sur leur AppStore. Ils ont déjà l'expérience (PowerPC à x86_64).
  Surtout, le monde a changé, et de nos jours on a de plus en plus d'outils pour gérer le multi-arch (merci les smartphones), et Intel devient un concurrent comme les autres et non plus la référence, ils vont devoir se rebouger les fesses (et non je ne dirai pas adieu à Intel, c'est souvent quand il y a de la concurrence que la boite se réveille).
  
  Les portages ne semblent pas triviaux vu qu'Apple a annoncer vouloir aider les projets open source à faire leur portage.
  
  Le portage est trivial quand tu fais du code générique ("standard", genre avec du C, C++, etc, sans coder en assembleur).
  En dehors du soucis de codage à l'arrache (genre scripts qui imaginent une seule arch, ou lancer l'assembleur x86_64 sans vérifier que c'est du x86_64) le soucis est la perf car le logiciel va basculer du code assembleur x86_64 avec optimisation (SSE est obligatoire sur x86_64, souvent utilisé) à du code générique qui n'utilise pas les fonctions d'optimisation spécifique au CPU. Rien de vraiment nouveau (pour les smartphones ARM il faut déjà remplacer le code SSE par NEON pour le calcul vectoriel) mais c'est à faire, et Apple peut d'une fournir de la doc sur l'usage de son CPU en assembleur, mais surtout payer des développeurs pour implémenter les optimisations et ainsi pouvoir afficher de jolie perfs.
- [^] # Re: Questions
  
  Posté par YBoy360 (site web personnel) le 03 septembre 2020 à 19:26. Évalué à 7. Dernière modification le 03 septembre 2020 à 19:27.
  Ils ont encore de quoi tenir suffisamment longtemps pour se retourner. Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça. Intel serait déjà mort, Microsoft aussi, Apple aussi, AMD pareil, Facebook n'en parlons pas,…
  
  C'est un peu différent dans le cas d'Intel pour 3 raisons :
  - Faire un processeur est extrêmement capitalistique, contrairement à ce que fait MS ou Facebook, un nouveau processus de fabrication coûte des milliards pour la mise en oeuvre, ne pas être à niveau aujourd'hui c'est l'être encore moins demain ;
  - Le conseil d'administration a nommé l'ancien DAF (Directeur Administratif et Financier) comme dirigeant. En général, ça fonctionne pas pour les boites hi-tech (loin de moi l'idée de dire qu'ils sont des incapables, mais je n'ai pas d'exemple de financier ayant réussi dans l'industrie) ;
  - Le DAF en question a suggéré de fabriquer des puces par TSMC, ça c'est la preuve qu'ils sont vraiment dans une passe inquiétante car le jeu d'instruction Intel implique une surconsommation de l'ordre de 30 % par rapport au jeu d'instruction ARM (désolé, pas de liens, je parle bien du jeu d'instruction, pas de l'architecture, car l'unité de décodage pour passer du CISC au RISC consomme 30 % de transitor d'un core sur le die), à processus de fabrication équivalent, ils seront derrière ARM, il tenait avant grâce à leurs supers usines.
  Enfin, concernant l'out-of-order, la prédiction de branchement, autres, ce n'est pas une spécificité d'Intel, ARM s'est mis à le faire il y a déjà un certain temps, chez Intel, les Atoms n'en dispose pas, le compilateur ne peut pas prévoir tout statiquement et les gains associés sont quand même important, alors je doute que ça disparaisse.
  - [^] # Re: Questions
    
    Posté par barmic 🦦 le 03 septembre 2020 à 19:46. Évalué à 8.
    
    Faire un processeur est extrêmement capitalistique, contrairement à ce que fait MS ou Facebook, un nouveau processus de fabrication coûte des milliards pour la mise en oeuvre, ne pas être à niveau aujourd'hui c'est l'être encore moins demain ;
    
    Pour le reste je en sais pas, mais on a annoncé la mort d'AMD une fois ou 2 aussi. Après la génération Athlon64/P4, Intel a sorti les pentium M et rapidement et Core alors qu'AMD n'a pas su gérer le passage au multicore. Il gravaient des 4 cores en désactiver 1 qui fonctionnait mal et vendaient ça comme 3 cores… Ça en dit long sur la qualité de ton processus de fabrication et ça représente des puces la marge sur la vente est largement diminuée. Et ça venait après que le P4 se soit vautré face à l'Athlon64.
    
    Ça ne coûte pas aussi chère que tu l'annonce. Sinon le Cell ne serait jamais sorti avec la PS3. Oui c'est chère quand tu pars d'une feuille blanche. Intel a déjà montré qu'ils étaient en mesure de se reprendre quand ils avaient fais de mauvais choix architecturaux (justement avec le P4 par exemple).
    
    Quand tu as les reins aussi solides qu'une boite comme Intel, il en faut beaucoup pour pouvoir dire que c'est la fin.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Questions
      
      Posté par pulkomandy (site web personnel, Mastodon) le 04 septembre 2020 à 14:27. Évalué à 6.
      
      Ce sont pas les premiers à faire ce genre de choses (désactiver les coeurs non fonctionnels). C'est le cas sur le processeur de la PlayStation 3, et c'est une solution qui est tout à fait raisonnable quand le "die" est un peu large. De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.
      
      Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.
      - [^] # Re: Questions
        
        Posté par barmic 🦦 le 04 septembre 2020 à 14:50. Évalué à 2.
        
        De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.
        
        Ça n'a rien à voir ça. C'est pour gérer de l'usure et pas des ratages en sortie d'usine. Et c'est quelque chose de parfaitement intégré, au départ de ta ligne de production tu connaît ton ratio dépense de production/prix de vente. Tu ne croise pas les doigts au moment des tests pour savoir si tu fait de la marge ou non.
        
        Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.
        
        Oui et non. Aujourd'hui tu ne trouve plus de CPU avec un nombre de cœur ésotérique (3, 7, 15 cœurs). Soit ils ne vendent plus leurs CPUs ratés (ce qui représente du coup une perte sèche, plutôt qu'une perte limitée), soit ils ont des procédés de fabrication plus fiables.
        
        Bien sûr qu'il y a des ratages. J'ai travaillé dans le test électrique chez ST, j'ai pu le voir. Mais il y a une différence entre voir des problèmes de montée en charge et réduire après production la fréquence de ton CPU (par exemple) et vendre 20% de silicium en trop. Même si dans les 2 cas tu en profite pour segmenter ton offre. De base tout cela est un réelle perte, mais ça me paraît bien plus drastique quand on parle de virer une partie du composant.
        
        Pour le cell, oui les lignes de production n'étaient pas encore chaudes (ce qui est normal).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Questions
        
        Posté par FluffyHamster le 04 septembre 2020 à 17:50. Évalué à 9.
        
        AMD ne grave qu'une et une seul puce pour les zen 1, le module zepplin à 8 coeurs. Tout les CPU du Ryzen 1300 aux Epyc 32 coeurs ont le même die, avec des coeurs désactivés et/ou des assemblage de plusieurs puces.
        Même principe pour les coeurs de zen 2 (hors module IO et APUs) qui n'ont qu'un seul die à 8 coeurs qui sort de production. Donc tu peux effectivement avoir des CPUs avec plus de 75% de silicone en trop (Il y a des epyc 8 coeurs sur 4 dies après tout. Il y a un epyc de 2e génération à 8 coeurs aussi, mais je sais pas s'il a bien les 8 dies).
        
        La différence avec ST qui gravent des petites puces sur des process maîtrisés, c'est que graver des puces gigantesques sur des process au limites de la technologie, c'est la garantie d'avoir un taux de défaut important. Il faut composer avec, splitter les puces en modules et utiliser les modules défectueux devient du bon sens.
        Ils ont cité 80% de dies pleinement fonctionnels en début de production, le reste dégradé. Sachant que même les dies pleinement fonctionnels peuvent déjà absorber des défauts dans les caches, avec de la redondance "physique" comme c'est fait habituellement dans les mémoires.
        
        C'est comme ça qu'ils sont 50% moins cher par CPU, quel que soit le CPU, malgré parfois bien plus de coeurs un process de gravure plus coûteux, quand le concurrent s'entête à graver plus d'une dizaine de variantes physiques, de 2 à 18 coeurs monolithiques.
        Après c'est eux qui le disent, il y à pas mal d'interviews ou ils expliquent la démarche.
        
        [^] # Re: Questions
        
        Posté par barmic 🦦 le 04 septembre 2020 à 18:07. Évalué à 3.
        
        Ok je trouve ça fou tout de même.
        
        Ils ont cité 80% de dies pleinement fonctionnels en début de production, le reste dégradé.
        
        Ce qui signifie qu'ils vendent un paquet de puces totalement fonctionnel au prix du milieu de gamme (en les ayants évidement configurés pour).
        
        J'ai pas de doute qu'ils ont fais leur choix de manière aussi intelligente que possible.
        
        Merci pour l'info :)
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Questions
        
        Posté par BAud (site web personnel) le 04 septembre 2020 à 23:07. Évalué à 2. Dernière modification le 04 septembre 2020 à 23:08.
        
        Ce qui signifie qu'ils vendent un paquet de puces totalement fonctionnel au prix du milieu de gamme (en les ayants évidement configurés pour).
        
        c'est ce que fait IBM avec ses CPU Power sur leurs serveurs AIX haut de gamme : tu peux activer des processeurs supplémentaires à la demande (CPU on-demand) temporairement (une seule fois, par exemple pour un besoin de performance ponctuel) ou de manière permanente.
        
        [^] # Re: Questions
        
        Posté par claudex le 05 septembre 2020 à 00:27. Évalué à 4.
        
        Ça vient de leurs mainframe où ils font ça depuis très longtemps.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Questions
        
        Posté par pulkomandy (site web personnel, Mastodon) le 06 septembre 2020 à 23:36. Évalué à 8.
        
        Il faut voir aussi que la surface du die n'est pas ce qui coûte le plus cher (en fait on sait pas trop quoi faire de toute cette place et on remplit avec des mégaoctets de mémoire cache). Les trois trucs qui empêchent de minaturiser les cpus aujourd'hui c'est le nombre de pins nécessaires pour les connecter à la carte mère, la dissipation de chaleur, et la consommation électrique qui empêche de faire des connections trop petites au moins pour l'alimentation.
        
        Ces critères définissant en gros la taille du package du cpu, autant mettre du silicium qui fait à peu près la même taille dedans. Mais ça fait grand, et plus ton silicium a de surface, plus, statistiquement, y'a de chances qu'il aie un problème quelque part (par exemple ça peut être une poussière qui passe là ou elle devrait pas).
        
        Du coup, avoir des coeurs désactivés n'est pas délirant. Y'a la place de les mettre,et une fois désactivés ils ne chauffent pas et ne consomment pas d'électricité. Et comme c'est dit dans un autre comrentaire, ça permet de lancer les premiers cpus (mettons avec 4 coeurs) puis quelques mois plus tard une fois les soucis réglés ou une fois un stock suffisant accumulé, hop, la version à 8 coeurs avec le même silicium!
        
        [^] # Re: Questions
        
        Posté par barmic 🦦 le 07 septembre 2020 à 00:27. Évalué à 6.
        
        Il faut voir aussi que la surface du die n'est pas ce qui coûte le plus cher (en fait on sait pas trop quoi faire de toute cette place et on remplit avec des mégaoctets de mémoire cache).
        
        Sur ton wafer 32" si tu sort N dice ou 25% de plus c'est quand même une légère différence, non ?
        
        Les trois trucs qui empêchent de minaturiser les cpus aujourd'hui c'est le nombre de pins nécessaires pour les connecter à la carte mère, la dissipation de chaleur, et la consommation électrique qui empêche de faire des connections trop petites au moins pour l'alimentation.
        
        Je comprends le premier point (on arrive probablement a des tailles de soudures en dessous des quels elles perdent en fiabilité), par contre les 2 points suivants je ne vois pas trop, ils sont liés à la densité et pas à la taille. Si tu as besoin de la surface de ton CPU 32 cœurs même pour refroidir 16 cœurs, ça ne doit pas très bien se passer quand tu 32 cœurs sont effectivement utilisés.
        
        Ces critères définissant en gros la taille du package du cpu, autant mettre du silicium qui fait à peu près la même taille dedans.
        
        Alors non parce que tes chaines de productions produisent moins par wafer et il y a une différence énorme entre la taille du PCB et celle du die par exemple :
        
        pour un socket de 37.5mm de côté donc 85% de surface sans die.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Questions
        
        Posté par groumly le 04 septembre 2020 à 18:12. Évalué à 5.
        
        Tu ne croise pas les doigts au moment des tests pour savoir si tu fait de la marge ou non.
        
        De ce que j’en comprends, même si c’est pas volontaire, c’est “maîtrisé” et intégré au process. Et très courant comme pratique.
        
        Apple a fait ça récemment avec leur dernier iPad, qui est le même cpu que ce qu’ils avaient dans l’iPhone sorti 9 mois avant. Leur process a évolué, et ils peuvent activer un cœur de plus.
        Ils savaient quel était le yield, ils avaient planifié un iPhone avec n-1 cœurs, savaient que le process s’améliorerait à temps pour la production de l’iPad avec n cœurs. Ça leur permet de lisser les coûts de Dev et production, et ça rallonge la durée de vie commerciale du cpu.
        A plus forte raison quand t’as une gamme qui va de 8 à 32 cœurs.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Questions
        
        Posté par Kerro le 04 septembre 2020 à 20:05. Évalué à 5.
        
        les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée
        Pareil pour les disques durs […] Pareil pour les CD et DVD […]
        
        Ça n'a rien à voir ça. C'est pour gérer de l'usure et pas des ratages en sortie d'usine
        
        Pour les mémoires NAND et les disques-durs, dans beaucoup de cas c'est fabriqué aux limites de ce qui est possible avec des tarifs hyper agressifs.
        Par exemple beaucoup de SD Cards sont truffées de trous. J'avais vu l'étendue des dégâts sur un site où un mec bidouillait en reprogrammant le micro-contrôleur dans des SD Cards. C'était du genre 80 % des cartes qu'il avait.
        Pour les disques-dur, je sais que certaines pistes sont invalidées à la sortie de l'usine car elles ne passent pas les tests. Aucun idée de la proportion de disques concernés.
        
        Pour les CD/DVD je ne connais pas.
        
        [^] # Re: Questions
        
        Posté par Ontologia (site web personnel) le 05 septembre 2020 à 00:42. Évalué à 4.
        
        Donc si je comprend bien, il se pourrait que les sdcard vendues comme "16Go" soit en fait des cartes 32, voire 64Go tellement trouées que les 3/4 ont été invalidés ?
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Questions
        
        Posté par Kerro le 05 septembre 2020 à 19:38. Évalué à 5.
        
        De mémoire, les informations qui m'ont semblé les plus fiables indiquaient jusqu'à 75 % de « trous » pour les NAND premier prix. Mémoires achetées au rabais car non utilisées par les fabricants genre Samsung. Donc effectivement 64 Gio pour faire une 16 Gio est probable.
        
        Du coup celles qui ne sont pas vendues au rabais sont les « normales », mais je ne me souviens pas du pourcentage de défauts. Ce n'était en tous cas pas zéro.
        
        Une recherche vite faite parle de rendement de 90 % chez Intel en 2018 pour produire des SSD. L'article indique également qu'une autre technologie a un rendement de 48 %, ce qui ne permet d'utiliser qu'une puce sur deux pour des SSD (j'imagine donc que les autres sont utilisées pour autre chose, sinon ils auraient peut-être tourné la phrase autrement).
        Je n'ai pas vérifié si « rendement » est le nombre de puces considérées comme valides, ou si c'est la surface utilisable.
        
        [^] # Re: Questions
        
        Posté par pulkomandy (site web personnel, Mastodon) le 06 septembre 2020 à 23:55. Évalué à 4.
        
        Ce qui est "amusant" c'est que dans une sd card le contrôleur intégré va faire les tests sur la mémoire et gérer les erreurs, donc on s'en fiche un peu d'avoir une mémoire de bonne qualité. Résultat, a capacité équivalente, une carte sd coûte moins cher qu'une puce de nand-flash toute seule (qui elle nécessite du matériel de test spécifique).
        
        Pour les CD/DVD, le principe est différent. Le but au départ est plutôt de se protéger des erreurs de lecture (poussière sur le disque, rayures, vitesse de rotation pas précise, vibrations…). Pour les cd audio, la lecture se fait en temps réel et c'est pas possible de tenter une deuxième lecture d'un secteur si la première a raté.
        
        Pour le cdrom, un niveau supplémentaire de contrôle a été ajouté, et de mémoire on arrive à presque 10% des bits utilisés pour la correction (le secteur "brut" fait 2200 octets environ, dont 2048 de données utiles et le reste pour détecter et corriger les erreurs).
        
        Et ça a permis ensuite de faire fonctionner raisonablement bien les CD-R ou les erreurs de lecture (ou même d'écriture) sont encore plus fréquentes.
        
        Avec des codes correcteurs bien choisis, on arrive à vraiment augmenter la fiabilité et à compenser les défaillances de la mémoire. Pour de la Nand-flash, par exemple, c'est pas surprenant d'avoir des garanties du genre "pas plus de 4 bits défectueux par secteur marqué 'ok', et pas plus de 0.001% de secteurs marqués 'ko' en sortie d'usine". Et avec le code correcteur approprié, ça fonctionnera très bien et l'utilisateur ne se @endra compte de rien. Les secteurs de la mémoire sont séparées en une partie "données" et une partie dite "out of band", la deuxième servant à mettre les infos pour la détection/correction d'erreurs, à marquer les blocs inutilisables, etc.
        
        Sur les SSD ça se voit qu'il y a de la marge. Par exemple un SSD de 60Go est probablement basé sur 64Go de mémoire. Et ils sont en général tous comme ça, une taille puissance de 2, moins 5 à 10% parce que c'est plein de secteurs inutilisables (bon c'est pas que pour ça, il y en a une partie pour le stockage d'infos internes du ssd aussi).
# Il bouge encore

Posté par claudex le 01 septembre 2020 à 09:23. Évalué à 10.

Quand on creuse un peu, on se rend compte que l'AVX512 n'est pas anodin pour le processeur, l'utiliser l'oblige à changer de fréquence et de voltage

Ça s'améliore avec les nouveaux processeurs, le coût est moins important https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html

La fin de la nécessité du Out of Order ?

Tout le monde faire de l'out of order (Intel, AMD, ARM, IBM…) donc, je ne suis pas sûr que ça signifie la fin d'Intel.

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# AVX512

Posté par Zenitram (site web personnel) le 01 septembre 2020 à 09:42. Évalué à 8.

C'est que le processeur doivent cadencer plus bas préventivement pour de telles instructions, et doit rester à cette fréquence inférieure pendant un certain temps.

Ne serait-ce pas un problème temporaire, des premières implémentations "time to market", qui sera corrigé à long terme?
J'ai commencé à jouer avec AVX512 et pour ce que j'ai à en faire (du bourrin, qui reste sur du AVX512 tout le temps ou presque), ça aide pas mal (x1.6 par rapport à AVX2 pour mon besoin, et je n'ai rien optimisé genre essayé d'utiliser les "mask" et plus de registres)… Sans que je puisse dire si financièrement il aurait mieux fallu ou pas pour Intel et mettre plus de coeurs.

Peut-être que c'est un pari à long terme, aussi le temps que les développeurs s'approprient l'API, que les compilos s'adaptent etc.
Ca reste très spécifique (il faut avoir l'utilité du vectoriel), mais peut-être que ce sera gagnant à long terme et un point de différenciation face à la concurrence, quand Intel aura multiplié les cœurs et saura mieux gérer la conso par rapport à la perf.

Ou ça le perdra, certes. On saura ça que plus tard…
- [^] # Re: AVX512
  
  Posté par fcartegnie le 01 septembre 2020 à 11:33. Évalué à 5.
  
  Ne serait-ce pas un problème temporaire, des premières implémentations "time to market", qui sera corrigé à long terme?
  
  La hausse de TDP faisait déjà des siennes en 2015 quand les optimisations AVX2 ont été ajoutées à x265.
  
  Avec AVX512, rien n'a changé chez Intel apparemment. On release, on fixera après.
  
  https://youtu.be/OuaMpPPBKig?t=1070
# Commentaire supprimé

Posté par FoxHP le 01 septembre 2020 à 10:05. Évalué à 0. Dernière modification le 01 septembre 2020 à 10:06.

Ce commentaire a été supprimé par l’équipe de modération.
# ce qui tue intel...

Posté par Nicolas Boulay (site web personnel) le 01 septembre 2020 à 10:20. Évalué à 10.

Faire 50 version de ses instructions n'aident pas intel. Il a fallut atteindre AMD et son archi 64 bits, pour que le SSE2 deviennent la norme standard de FPU de l'univers x86. Avoir plein de jeux d'instruction dans la nature empêche d'avoir des compilateurs qui les utilisent automatiquement, cela revient à limiter leur utilisation dans les logiciels codés en partie en assembleur, ce qui est très très limité. Il ferait mieux de faire des "levels" qui inclus totalement le niveau en dessous, au lieu de faire des clusters peu utilisé au final.

Je ne crois pas à la fin du out of order. L'Itanium est mort d'avoir cru que les compilateurs pouvaient faire le travail.

Je suis étonné que les IPC soit à 1, pour moi, il tournait autour de 3. La limitation est la lenteur de la RAM. Mais pour arriver à 3, le niveau de parallélisme est assez énorme (10 instructions en parallèle, ou plus ?)

"La première sécurité est la liberté"
- [^] # Re: ce qui tue intel...
  
  Posté par pulkomandy (site web personnel, Mastodon) le 01 septembre 2020 à 11:01. Évalué à 5.
  
  Il a fallu attendre que AMD implémente le SSE2 dans ses processeurs 64bit pour que ça devienne un standard de fait, en effet. Avant ils avaient leur propre jeu d'instruction (3dNow!). Mais je ne vois pas ce que Intel pouvait y faire. Enfin si, ils auraient pu utiliser 3dNow! au lieu d'inventer le SSE qui est arrivé après…
  - [^] # Re: ce qui tue intel...
    
    Posté par Nicolas Boulay (site web personnel) le 01 septembre 2020 à 11:40. Évalué à 8.
    
    Intel aurait pu mettre SSE2 partout, au lieu de sortir des cpu sans, et de faire autant de versions différentes.
    
    "La première sécurité est la liberté"
- [^] # Re: ce qui tue intel...
  
  Posté par Troy McClure (site web personnel) le 01 septembre 2020 à 14:22. Évalué à 10. Dernière modification le 01 septembre 2020 à 14:22.
  
  Faire 50 version de ses instructions n'aident pas intel.
  
  Totalement d'accord, et rien que pour ça je suis bien content que Intel soit en train de se prendre une grosse claque.
  
  AVX qui est sorti vers 2011 n'est toujours pas dispo sur tous les cpu vendus par intel en 2020. Ca ne simplifie la vie à personne à part à ceux qui ont beaucoup de temps à consacrer à faire différents chemins d'optimisations dans leur code en fonction du cpu.
- [^] # Re: ce qui tue intel...
  
  Posté par lasher le 02 septembre 2020 à 18:35. Évalué à 3.
  
  Euh, de ce que me disaient les ingés d'Intel, l'Itanium est surtout mort de leur incapacité à faire baisser la conso de puissance (et du coup le proc était coincé à 1,6GHz).
  
  Le compilo d'Intel était excellent à partir de ~2009 pour l'IA64.
  - [^] # Re: ce qui tue intel...
    
    Posté par Nicolas Boulay (site web personnel) le 03 septembre 2020 à 10:21. Évalué à 6.
    
    La puissance consommé était aussi directement lié à l'architecture statique : beaucoup d'instructions étaient éxecuté pour rien et la taille du code explose par rapport au x86 (Icache énorme).
    
    Ensuite, coté excellence, j'imagine que tu parles de la capacité de calcul en virgule flottante, qui est énorme sur ce cpu. Son architecture LIW est semblable à celle du plus puissant DSP de TI. Sans saut conditionnelle, il y a de quoi faire du code très rapide.
    
    "La première sécurité est la liberté"
    - [^] # Re: ce qui tue intel...
      
      Posté par lasher le 03 septembre 2020 à 13:57. Évalué à 5.
      
      Je parlais de la qualité du compilateur générant des instruction IA64. La première version était médiocre (ICC 7 je crois), et la version 9 était plutôt très bonne (utilisation des registres rotatifs pour faire du software pipelining, etc.).
      
      Concernant les aspects statiques que tu évoques, oui, complètement. L'utilisation de prédication pour faire des if-conversions, etc., était un gouffre à énergie et puissance, autant qu'une super façon d'augmenter la perf.
      
      Concernant la perf en elle-même : en flottant l'Itanium2 était super performant, mais effectivement en calcul entier, il était carrément à la ramasse. L'archi était assez « étrange » aussi : L1D (16KiB) : calculs entiers uniquement ; L2 (unifié, 256KiB)) : calculs flottants. Et un L3 avec tout plein de MiB (genre 12MiB par thread dans la version Montecito).
# AMD dans les consoles next-gen

Posté par rewind (Mastodon) le 01 septembre 2020 à 10:47. Évalué à 10.

Je rappelle aussi que Sony et MS ont tous les deux choisis AMD et son architecture Zen2 pour équiper les prochains console de salon (respectivement PS5 et Xbox series X). Ça représente des dizaines de millions d'unités sur les prochaines années (pour rappel 112 millions de PS4 et presque 90 millions pour la Xbox One).
- [^] # Re: AMD dans les consoles next-gen
  
  Posté par SpaceFox (site web personnel, Mastodon) le 01 septembre 2020 à 11:38. Évalué à 10.
  
  D’ailleurs, ils avaient déjà choisi des CPU AMD dans la génération actuelle (PS4 / Xbox One), malgré les performances catastrophiques de ces CPU (Jaguar, évolution de Bobcat, une architecture basse consommation).
  
  La connaissance libre : https://zestedesavoir.com
  - [^] # Re: AMD dans les consoles next-gen
    
    Posté par Thomas Debesse (site web personnel) le 02 septembre 2020 à 12:59. Évalué à 10. Dernière modification le 02 septembre 2020 à 13:01.
    
    Il faut y voir le succès de la feuille de route « Fusion » d’AMD marquée par le rachat d’ATI en 2006, et probablement aussi la politique d’ouverture de code et de publication de documentation qui entraîne une certaine culture d’entreprise propice à une certaine transparence avec les tiers (fussent-ils propriétaires à leur tour). Et bien sûr l’efficacité énergétique de leurs APUs, l’objectif initial de « Fusion ». AMD domine le marché des consoles de salon aussi bien sur le plan du CPU que sur le plan du GPU. J’ai lu des développeurs AMD dirent par exemple que le code des GPU AMD du noyau Linux étaient fondé sur la base d’un tronc commun pour 5 systèmes d’exploitations (d’où la difficulté, au début, de fusionner les patchs DAL/DC qui semblaient tomber du ciel en réinventant la roue).
    
    La Nintendo switch, plus mobile fait exception avec une plateforme Tegra (NVidia & ARM). Clairement, si Nvidia achète ARM cela permettrait de rentrer dans la course (AMD s’étant essayé à cette plate-forme mais n’a pas persévéré, laissant un boulevard pour ce genre d’usage).
    
    Mais pour le moment AMD règne en maître sur certains secteurs très lucratifs. J’ai lu à certains endroits que la Vega aurait été conçue pour le marché Apple, la première démonstration de raytracing s’est faite sur une PlayStation 5, etc. En tant qu’utilisateur de PC (ou joueur sur PC) on peut être victime d’un énorme biais (du genre biais de confirmation, mais à l’envers) au détriment d’AMD, AMD a très bien su construire son propre marché.
    
    Globalement, certaines personnes chez Nvidia définissent Nvidia comme une entreprise de logiciel, et les secteurs où Nvidia domine (PC gaming, calcul) sont captifs des solutions logicielles Nvidia (Pilotes propriétaires et optimisations non-documentées, CUDA, etc.), Nvidia ne libère du code que s’il renforce la captivité aux GPU Nvidia. Exemple: libération de l’API pour le un SDK NVAPI propriétaire, Nvidia Optix dans Blender, etc.
    
    Sur le plan du CPU AMD a longtemps été victime de pratique anti-concurrentielles de la part d’Intel, et il est toujours difficile de se fournir en matériel équipé d’AMD chez les grossistes visant le marché pro dès lors qu’il s’agit de serveur ou station de travail. Ça commence à lâcher prise côté serveur car il devient vraiment difficile de justifier auprès du client de ne pas vendre un produit objectivement meilleur, mais ça résiste encore beaucoup du côté des stations de travail haut de gamme (et autre ordinateur portable haut de gamme professionnel).
    
    Donc, AMD s’est positionné très efficacement sur les secteurs où le marché n’était pas verrouillé et y règne désormais en maître, tout en conservant un pied dans les marchés très verrouillés pour se permettre de les bousculer quand ils ont des produits qui font plus qu’être seulement compétitifs.
    
    ce commentaire est sous licence cc by 4 et précédentes
    - [^] # Re: AMD dans les consoles next-gen
      
      Posté par groumly le 02 septembre 2020 à 16:56. Évalué à 3.
      
      Ça commence à lâcher prise côté serveur car il devient vraiment difficile de justifier auprès du client de ne pas vendre un produit objectivement meilleur, mais ça résiste encore beaucoup du côté des stations de travail haut de gamme (et autre ordinateur portable haut de gamme professionnel).
      
      Qu’est ce que tu impliques par la?
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: AMD dans les consoles next-gen
        
        Posté par pulkomandy (site web personnel, Mastodon) le 02 septembre 2020 à 20:16. Évalué à 8.
        
        Par exemple chez Dell il n'y a aucun PC dans les gammes pro avec un CPU AMD:
        
        https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/all-amd-processors?appliedRefinements=6077 (il trouve deux Inspiron, qui n'est pas une gamme pro)
        
        Alors je sais pas si c'est un choix de Dell de ne faire que du Intel, ou si c'est Intel qui leur met la pression pour ne rien faire avec les CPUs concurrents.
      - [^] # Re: AMD dans les consoles next-gen
        
        Posté par Thomas Debesse (site web personnel) le 03 septembre 2020 à 01:48. Évalué à 10. Dernière modification le 03 septembre 2020 à 01:51.
        
        pulkomandy m’a coiffé au poteau, mais…
        
        Station de travail tour Dell Precision : Intel Core i3, i5, i7, i9, Xeon, super la diversité !
        
        Station de travail portable Dell Precision : Intel Core i3, i5 et i7, rebelote…
        
        Station de travail tour Lenovo ThinkStation : Intel Core i*, Xeon…
        
        Station de travail portable Lenovo ThinkPad : Intel Core i*, Xeon…
        
        Station de travail tour, portable, rack Fujitsu : Intel Xeon…
        
        Ordinateur pro tour, desk, HP :
        
        gamme « haute performance » : 49 produits avec CPU Intel (Core i7, i9, Xeon) et 1 avec AMD (offre économique selon HP, avec Ryzen 7 entrée de gamme),
        
        gamme « performance avancée » : 52 produits avec Intel et 6 avec AMD (4 cœurs, 4 ou 8 Go de mémoire… tout est dit),
        
        gamme « performance standard » : 21 produits avec Intel et 1 avec AMD (APU Ryzen 3)…
        
        Ordinateur portable pro HP,
        
        gamme « haute performance » : 70 produits avec CPU Intel (et 16Go de mémoire) et 4 produits avec AMD (8Go de mémoire),
        
        gamme « performance avancée » : 79 produits avec Intel et 13 avec AMD,
        
        gamme « performance standard » : 29 produits avec Intel et 6 avec AMD…
        
        On continue comme ça, ou bien ?
        
        Pour Lenovo je n’ai pas fait le tour de toutes les gammes, j’ai visé les gammes « stations de travail ». Si tu élargis à l’ensemble de l’offre Pro des portables Lenovo (comme j’ai fait pour HP parce que c’est moins segmenté), tu verras que Intel domine les offres :
        
        Thinkpad X1, Intel uniquement ;
        
        Thinkad X, Intel uniquement ;
        
        Thinkpad T, 3 Intel pour 1 AMD, celui avec AMD est un « T14s » avec un « s », c’est à dire l’offre « légère » de cette gamme, et pas un « T15 » ;
        
        Thinkpad E, 2 Intel, 2 AMD, c’est la gamme économique de l’offre portable pro de Lenovo.
        
        Si tu élargis à l’ensemble de l’offre Pro de PC de bureau Lenovo avec la série ThinkCentre, tu as :
        
        La série M, Intel ;
        
        M Tiny, Intel uniquement ;
        
        M Compact, wow, exception, 2 AMD pour 1 Intel ;
        
        M Client léger, wow, 1 AMD ;
        
        M Nano, Intel ;
        
        M Tout-en-un, Intel uniquement.
        
        Stop ou Encore ? Les configurations avec AMD dans les gammes PRO sont ultra minoritaires, voire inexistantes dans les gammes « stations de travail  », et les rares qui existes sont réservées aux offres économiques, légères, pour faire du traitement de texte ou du point de vente, et quand ça flirte avec la performance, c’est systématiquement l’entrée de gamme économique.
        
        Les offres de stations de travail professionnelles performantes sont exclusivement des offres avec Intel, pas d’AMD Ryzen 9, pas d’AMD ThreadRipper… alors qu’aucun processeur haut de gamme d’Intel n’égale les processeurs hauts de gamme d’AMD, même en luttant à 2 processeurs contre un, même en payant 2 à 4 fois plus cher…
        
        À noter que si l’on trouve plus facilement des GPU AMD que des CPU AMD dans les offres pro actuelles, l’écrasante présence d’Nvidia dans ces gammes pros est également problématique. Si je reprends l’exemple de Lenovo, malgré les récents partenariats avec Fedora et Ubuntu et le fait que tout le monde s’extasie de l’approche Open Source volontariste de Lenovo, je n’ai pas vu d’offre avec du AMD. Tu veux du Lenovo Thinkpad, tu veux du haut de gamme ? Pas le choix : Intel et Nvidia. Même pour les libristes qui ne veulent que du libre, ils auront du libre partout sauf pour le GPU.
        
        J’aime beaucoup cette réponse d’un inconnu à un autre inconnu sur Quora (oui je l’ai déjà citée) :
        
        Q: Is Apple's 2019 Mac Pro already obsolete now that AMD has released a 32-core Threadripper CPU and plans to launch a 64-core CPU soon?
        A: No, the AMD CPUs are irrelevant to the Mac Pro because the high end workstation/towers, from Apple, H-P and Dell exclusively use Intel Xeon CPUs.
        
        C’est à dire :
        
        Q : Le Mac Pro 2019 d'Apple est-il déjà obsolète maintenant qu'AMD a sorti un processeur Threadripper 32 cœurs et prévoit de lancer bientôt un processeur 64 cœurs ?
        R : Non, les processeurs d'AMD ne sont pas pertinents pour le Mac Pro car les stations de travail/tours haut de gamme, d'Apple, de H-P et de Dell utilisent exclusivement des processeurs Intel Xeon.
        
        C’est la meilleure réponse que j’ai pu lire : Le Mac Pro avec un processeur Intel n’est pas rendu obsolète par l’arrivée de l’AMD ThreadRipper parce que tu ne peux pas acheter de machine professionnelle avec un ThreadRipper chez un autre fournisseur.
        
        Le reste de la réponse évoque un cas particulier où Intel a le dessus (ceux qui ont besoin de plus de 128Go de ram), cela explique que le processeur Intel ait un marché pour ce cas très spécifique malgré ses performances nettement moindre à un prix beaucoup plus élevé, mais cela n’explique pas qu’il n’y ait aucune offre pour tous ceux qui n’ont pas besoin de plus de 128Go de ram et qui ont besoin de plus de cœurs que ce que fait Intel, ou tout simplement qui veulent plus performant pour moins cher…
        
        Qu’est ce que tu impliques par la?
        
        Je ne suppose rien, je ne suis pas devin. Je constate.
        
        Si tu cherches des méthodes malhonnêtes, de la corruption, etc. Je ne peux pas te dire pour le présent (je ne suis pas devin), pour le passé tu pourras regarder cette vidéo, avec des faits documentés et constatés (et sourcés) :
        
        AdoredTV: Intel - Anti-Competitive, Anti-Consumer, Anti-Technology
        
        Pour reprendre des éléments en vrac de la vidéo, à l’époque du Pentium III, par exemple, Intel n’avait rien à offrir pour rivaliser avec les performances de l’AMD Athlon, mais les vendeurs ne proposaient pas de configuration avec du AMD. Pareil avec les Opteron de la gamme serveur : plus performants tout en étant moins cher.
        
        Au Japon, Intel a payé Nec, Hitachy, Sony et Toshiba. Aux États-Unis, Intel a fait des contrats d’exclusivité avec Dell, Sony, Toshiba, Gateway et Hitachy (y compris des paiements en liquide). En Europe, des revendeurs allemands auraient été payés pour ne vendre que du Intel. Entre 2001 et 2005 Intel a donné 370 millions de dollars à Samsung et et Trigem à la condition que ces industriels n’achètent pas de processeur AMD. Les documents de la Commission Européenne relatifs à ces pratiques parlent de réductions cachées auprès de HP, Dell, Lenovo, NEC pour qu’ils n’achètent quasi exclusivement sinon exclusivement des processeurs Intel, et évoque des paiements directs auprès du vendeur Media Saturn, le plus gros vendeurs de PC de l’époque à l’échelle de l’Union Européenne, afin de ne se fournir qu’en ordinateurs équipés de processeurs Intel. Puis sont évoqués encore des paiements directs avec Acer, HP et Lenovo pour interrompre ou retarder la sortie de produits équipés de processeurs non-Intel. Est également cité le nom de Fujitsu.
        
        Bref, c’est l’écrasante majorité du marché qui recevait d’énormes ristournes voire des paiements directs pour écarter les concurrents d’Intel. Une entreprise qui n’aurait pas accepté la ristourne et les conditions qui vont avec aurait expérimenté de très grosses difficultés face à ses concurrents.
        
        En 2004 Dell a songé à basculer de Intel à AMD, mais Intel payait 300 millions de dollars par trimestre, soit plus d’un tiers de leurs recettes nettes sur la même durée. Alors que Dell perdait sa réputation, ses parts de marché et de l’argent à ne pas vendre de l’AMD Opteron, le patron de Dell a appelé le patron d’Intel pour lui dire qu’il était fatigué de voir Dell ne plus être vu comme un meneur et de perdre l’esprit, le cœur et le porte-monnaie de leurs clients. Après ça le patron d’Intel a envoyé un courriel en disant simplement : nous donnons plus d’un milliard de dollars par an à Dell, notre équipe juge cela suffisant pour compenser vos problèmes de compétitivité. Quand Dell a renoncé à AMD, le patron d’Intel a envoyé à un de ses collègues un courriel disant « le meilleur ami que l’argent peut acheter ». Ce trimestre-là, Dell aurait reçu 805 millions de dollars de réduction de la part d’Intel.
        
        La « Korean Fair Trade Commission » constata que les manœuvres d’Intel avaient lieu à une telle échelle qu’AMD n’aurait pas pu être compétitif sur le marché de l’OEM même en donnant ses processeurs gratuitement.
        
        Mais ça c’est le passé, je ne sais rien pour le présent. Je constate simplement que si tu veux des fournitures vendues comme « professionnelles », tu n’auras pas d’AMD, ou alors en entrée de gamme et désavantagé (moins de mémoire par exemple).
        
        Après tu peux acheter des configs gaming… En réalité les carte-mère ThreaRipper n’embarquent pas que des LEDs, mais aussi la compatibilité avec la mémoire ECC, proposent souvent des cartes réseaux 5 ou 10 GB (intégrées ou PCIe livrées avec), voire plusieurs cartes réseaux intégrées… Mais pour se le permettre en entreprise il ne faut pas être dans un environnement trop corporate et pouvoir prendre en choir soi-même le support. Si tu doit jouer au jeu de la décharge de responsabilité dans les achats ou préconisations d’achats, tu iras chez Dell ou HP ou Lenovo ou je sais pas quoi (tu as le choix) et tu auras du Intel (tu n’auras pas le choix).
        
        ce commentaire est sous licence cc by 4 et précédentes
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par eingousef le 03 septembre 2020 à 16:04. Évalué à 8.
        
        Les configurations avec AMD dans les gammes PRO sont ultra minoritaires, voire inexistantes dans les gammes « stations de travail  », et les rares qui existes sont réservées aux offres économiques, légères, pour faire du traitement de texte ou du point de vente, et quand ça flirte avec la performance, c’est systématiquement l’entrée de gamme économique.
        
        Sans vouloir contester que les manœuvres anticoncurrentielles d'Intel pèsent fortement dans la balance, est-ce que ça ne serait pas dû au rapport puissance/consommation ? Intel a toujours tenu le haut du pavé de ce côté. Pour un particulier, ce n'est pas important, on monte une grosse config avec de l'AMD et on se soucie rarement d'avoir quelques dizaines de watts en plus, mais pour une entreprise qui a de gros parcs j'imagine que chaque watt compte. Même remarque pour les GPU avec Nvidia à la place de Intel.
        
        Si je reprends l’exemple de Lenovo, malgré les récents partenariats avec Fedora et Ubuntu et le fait que tout le monde s’extasie de l’approche Open Source volontariste de Lenovo
        
        Je n'ai jamais compris comment on pouvait considérer la vente d'ordinateurs avec une distro préinstallée comme autre chose que de l'openwashing. Si l'ordinateur est vendu sans OS et que je peux installer ma distro dessus et que tout marche out-of-the-box, ok, c'est opensource-friendly. Si l'entreprise a installé elle-même sa distro en rajoutant tous les blobs qu'il faut pour que le matériel non-documenté soit reconnu…ben l'ordi n'est pas opensource-friendly, c'est juste le matos verrouillé habituel, sauf qu'à la place du windows c'est une distro blobifiée.
        
        *splash!*
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par Renault (site web personnel) le 03 septembre 2020 à 16:15. Évalué à 4.
        
        Je n'ai jamais compris comment on pouvait considérer la vente d'ordinateurs avec une distro préinstallée comme autre chose que de l'openwashing. Si l'ordinateur est vendu sans OS et que je peux installer ma distro dessus et que tout marche out-of-the-box, ok, c'est opensource-friendly. Si l'entreprise a installé elle-même sa distro en rajoutant tous les blobs qu'il faut pour que le matériel non-documenté soit reconnu…ben l'ordi n'est pas opensource-friendly, c'est juste le matos verrouillé habituel, sauf qu'à la place du windows c'est une distro blobifiée.
        
        Sauf que l'objectif est justement d'améliorer la prise en charge native de ces ordinateurs avec une Fedora native sans bouts proprio en plus. Ce qui bénéficiera à la fin à tout le monde.
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par claudex le 03 septembre 2020 à 16:24. Évalué à 5.
        
        Surtout que ça permet d'avoir un PC configuré avec les bonnes options kernel et les bons outils userspace pour que toutes les fonctionnalités soient opérationnelle. Contrairement à une installation de base d'une distribution sortie 18 mois avant la sortie du laptop.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par Thomas Debesse (site web personnel) le 03 septembre 2020 à 16:47. Évalué à 10. Dernière modification le 03 septembre 2020 à 16:48.
        
        Sans vouloir contester que les manœuvres anticoncurrentielles d'Intel pèsent fortement dans la balance, est-ce que ça ne serait pas dû au rapport puissance/consommation ? Intel a toujours tenu le haut du pavé de ce côté. Pour un particulier, ce n'est pas important, on monte une grosse config avec de l'AMD et on se soucie rarement d'avoir quelques dizaines de watts en plus, mais pour une entreprise qui a de gros parcs j'imagine que chaque watt compte. Même remarque pour les GPU avec Nvidia à la place de Intel.
        
        Je ne crois pas que ça puisse peser au poins qu’AMD soit quasiment inexistant des catalogues. Ce genre de situation entraine ordinairement une diversification des offres, au contraire.
        
        Je n'ai jamais compris comment on pouvait considérer la vente d'ordinateurs avec une distro préinstallée comme autre chose que de l'openwashing. Si l'ordinateur est vendu sans OS et que je peux installer ma distro dessus et que tout marche out-of-the-box, ok, c'est opensource-friendly. Si l'entreprise a installé elle-même sa distro en rajoutant tous les blobs qu'il faut pour que le matériel non-documenté soit reconnu…
        
        C’est précisément ce qui pique… Quand je lis des trucs sur ce rapprochement Fedora et Lenovo, c’est présenté comme la fête du libre avec un fort engagement pour upstreamer ce qui manque, pour ne pas simplement intégrer un pilote qui ne marchera plus à la prochaine mise à jour du noyau, pour utiliser une distro non-modifiée, etc. L’idée serait que Lenovo (ou toi) doit pouvoir installer une Fedora de base sans rien faire d’autre.
        
        Red Hat developers have applauded the move. Lenovo is making use of a stock Fedora Workstation installation without any vendor customizations but will be relying upon the existing Fedora/FESCo processes should any changes be needed moving forward.
        -- https://www.phoronix.com/scan.php?page=news_item&px=Lenovo-Fedora-Starts-Sale
        
        Lenovo is embracing the Linux Vendor Firmware Service (LVFS) with Fwupd for firmware updates on not only the computer itself but also onboard components.
        Christian exclaimed, "What we are doing here isn’t just a minimal hardware enablement effort, but a concerted effort to evolve Linux as a laptop operating system and doing it in a proper open source way. So this is the culmination of our work over the last few years, creating the LVFS, adding Thunderbolt support to Linux, improving fingerprint reader support in Linux, supporting HiDPI screens, supporting hidpi mice, creating the possibility of a secure desktop with Wayland […]
        -- https://www.phoronix.com/scan.php?page=news_item&px=Ecstatic-Fedora-Linux-On-Lenovo
        
        J’ai coupé brutalement, parce que jusque là c’est magique, mais les mots qui suivent immédiatement après sont :
        
        working with NVidia to ensure that Mesa and Nvidia driver can co-exist through glvnd
        
        Alors oui, au final, la Fedora sera la même si tu l’installes ou Lenovo l’installes pour toi. Mais au final la présence de la Nvidia brise tout.
        
        L’étape suivante serait que Lenovo propose un ordinateur haut de gamme avec un GPU AMD. Et là, ce sera vraiment la fête. Non seulement Nvidia ce n’est pas libre, mais en plus le pilote Nvidia pour Linux propose les performances de 2020 mais avec le même manque d’intégration qu’il y a 15 ans et des bugs vraiment bizarres.
        
        Note: pour Unvanquished j’ai testé une quarantaine de GPU avec une répartition AMD/Intel/Nvidia assez équitable, et des cartes dont les dates de sorties initiales étaient étalées entre 2006 et 2020. Avec Intel je n’ai pas rencontré de problème, avec AMD j’ai rencontré une vieille génération de carte qui avait un bug graphique corrigeable avec une simple variable d’environnement sans impact sur les performance, astuce donnée par un développeur super disponible, avec le pilote Nvidia j’ai vu des problèmes incroyables :
        
        une carte qui demande qu’un écran soit branché sur la prise VGA pour pouvoir utiliser correctement un écran sur la prise HDMI (sans pouvoir utiliser l’écran sur la prise VGA, alors que nouveau permet d’utiliser les deux écrans) ;
        
        un pilote qui se plante à la compilation des shaders, requérant de détecter ce pilote pour désactiver une fonctionnalité afin de permettre aux joueurs de jouer, le jeu a été impossible à lancer pendant des années sur cette carte/pilote jusqu’à ce que l’un d’entre-nous acquière physiquement un exemplaire ;
        
        et s’il y a deux cartes nvidia, le boot se fait sur une carte et le bureau sur une autre (il faut jongler avec le câbles selon les étapes du démarrage) ;
        
        sur un portable (Thnkpad, Haha !) il m’a fallu jouer du xorg.conf comme en l’an 2000 ;
        
        plein d’autres problèmes qui sont parfois indépendant de l’OS (comme le fait que les prises vidéos d’une station d’accueil requière une certaine configuration du BIOS qu’on ne souhaite pas nécessairement), etc. etc.
        
        Franchement, le pilote Nvidia est ignoble sous Linux, et parfois les problèmes semblent directement liés à des problèmes de conception du matériel. Les gens qui parlent de Nvidia sous Linux sont ceux qui font les bonnes pioches, les autres souffrent en silence.
        
        Peut-être qu’un jour je ferai un journal qui dénonce grave !
        
        (╯°□°)╯︵ ┻━┻
        
        ce commentaire est sous licence cc by 4 et précédentes
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par FluffyHamster le 03 septembre 2020 à 17:20. Évalué à 9.
        
        est-ce que ça ne serait pas dû au rapport puissance/consommation ?
        
        Par le passé sans doute. Maintenant les zen 2 sont beaucoup, BEAUCOUP plus efficace que les intel. Tout en étant aussi performant avec 1 Ghz de moins…
- [^] # Re: AMD dans les consoles next-gen
  
  Posté par Renault (site web personnel) le 02 septembre 2020 à 19:31. Évalué à 8.
  
  Pour le coup, difficile à dire si c'est vraiment un échec pour Intel.
  
  Ne pas oublier qu'une console de jeu (du moins Playstation et Xbox) c'est un ordinateur standardisé vendu à gros volume pour faire baisser les coûts.
  
  Les marges sur la console en elle même est très réduite voire négative suivant le volume. Les constructeurs misant sur les jeux et accessoires pour rendre l'opération rentable.
  
  Du coup cela signifie que en prévision de ces volumes les constructeurs font tirer les marges de chaque fabricant de composants vers le bas.
  
  AMD a plus besoin qu'Intel de remporter de tels marchés. AMD a besoin de liquidité et de PdM ce qu'offre ce genre de marchés même si la rentabilité n'est pas excellente, elle est suffisante. Intel a des marges plus grosses et déjà de grosses PdM, jouer à baisser les prix n'est pas tellement dans leur intérêt, cela monopoliserait des usines pour produire des puces peu rentables par rapport au reste de leur gamme.
  
  En tout cas je doute que la considération technique ait vraiment pesé dans ces choix. AMD fourni des puces capables de remplir le job comme Intel, la question fondamentale était le prix.
  - [^] # Re: AMD dans les consoles next-gen
    
    Posté par Alex G. le 03 septembre 2020 à 13:09. Évalué à 4.
    
    Mais tu ne crois pas que avoir un pied dans le monde des consoles permet de rester proche des éditeurs de jeu qui sont souvent des précurseurs de l'utilisation des CPU (et les joueurs conseillent souvent les gens autours d'eux sur le CPU à prendre pour leur PC), et donc un risque de perdre pied à long terme, au moins sur le marché grand publique ?
    - [^] # Re: AMD dans les consoles next-gen
      
      Posté par Renault (site web personnel) le 03 septembre 2020 à 13:54. Évalué à 5.
      
      Mais tu ne crois pas que avoir un pied dans le monde des consoles permet de rester proche des éditeurs de jeu qui sont souvent des précurseurs de l'utilisation des CPU
      
      Bof, les éditeurs composent de fait déjà avec plusieurs CPU ou GPU avec des architectures matérielles un peu différentes en terme de liaisons entre eux. Je ne pense pas que cela soit si fondamental que ça.
      
      (et les joueurs conseillent souvent les gens autours d'eux sur le CPU à prendre pour leur PC), et donc un risque de perdre pied à long terme, au moins sur le marché grand publique ?
      
      Les joueurs PC sont en général assez méprisants envers les consoles (absence de souris, matériel qui n'est pas à la pointe, prix des jeux ou accessoires assez chers). Ce n'est pas le même monde et cela me semble plus hermétique que ça.
      
      Je ne trouve pas non plus que les joueurs conseillent particulièrement les autres sur le matériel en terme de marques, car les besoins d'un usage bureautiques et pour les jeux sont très différents. Le prix est plus important que la performance pour des usages plus basiques.
    - [^] # Re: AMD dans les consoles next-gen
      
      Posté par Thomas Debesse (site web personnel) le 03 septembre 2020 à 15:02. Évalué à 10.
      
      Comme l’a fait remarquer Renault, du point de vue des clients finaux (les joueurs) il y a très peu d’échange entre les deux mondes, et je pourrai même dire, de porosité. Ordinairement un joueur de console ignore les composants qu’il y a dans la console.
      
      La console est toujours vue comme un produit à part, avec les mêmes mécanismes psychologies qu’on voyait avec les macs : le fait qu’on parlait de « mac ou de PC », quelqu’un pouvait te reprendre si tu parlais du PC d’un utilisateur de mac. C’est encore vrai pour ces derniers, mais l’idée universelle d’un ordinateur personnel quelque soit l’architecture ou le système d’exploitation a été mieux comprise avec le passage à Intel, la capacité d’installer Windows ou Linux sur un mac, etc.
      
      Pour les consoles, c’est toujours aussi hermétique. Les commentateurs parlent d’architecture PC et console, parlant de ces dernières un peu comme on parlait autrefois des stations dédiées telles les Silicon Graphic. Et cela faisait sens : la Nintendo 64 ayant par exemple été équipée d’une carte graphique SGI Reality et d’un processeur MIPS R4000 , les développeurs de GoldenEye ont d’ailleurs utilisé une SGI Onyx (GPU Reality 2, CPU R4000) pour le développement, sauf qu’une Onyx ça coûtait 150 000€. Les consoles était le royaume des PowerPC, MIPS et autres trucs de ce genre. Le Cell a surtout été connu pour la PlayStation 3, même s’il visait aussi les superordinateurs du top500.
      
      D’une part l’utilisateur moyen de console ignore probablement ce qu’uns un CPU et un GPU, d’autre part il y a fort à parier qu’une bonne partie d’entre eux voient l’ensemble comme un produit très différent, comme si la fabrication et la conception relevait d’un autre domaine de compétence.
      
      De ce que je vois autour de moi (mais peut-être suis-je victime d’un biais), les utilisateurs de console qui se posent des questions techniques se soucient surtout de la résolution de l’écran (et de la capacité de la console à ce sujet), de la capacité de leur disque dur externe, et de choses comme ça. Les utilisateurs de PC feraient pareil s’il n’y avait aucun choix de processeur ou de carte graphique, ils compareraient le produit fini et livré. Comme client console tu choisis entre une marque et une autre, éventuellement entre une version slim et une version gourmande de la même console, t’as pas d’autre choix : comme les clients d’Apple qui comparent surtout les macs entre eux, mais sans la porosité avec le reste du marché du PC.
      
      Ceux qui voient les consoles comme des ordinateurs personnels ne sont en général pas les joueurs eux-même. Le projet Xbox de Microsoft est basé sur le constat que Sony avait un meilleur taux de pénétration des foyers avec sa PlayStation que ne l’avait le PC traditionnel. Microsoft voyait la PlayStation comme un ordinateur familial dédié au divertissement, et ne pouvait laisser Sony rafler tout ce marché. D’où la console avec une connectivité internet, des capacités multimédia (lecture CD/DVD, rip de CD etc.), un disque dur interne, etc. Aujourd’hui une Xbox et une télé c’est comme un gros ipad tout aussi verrouillé pour s’abonner à Canal+ et Netflix.
      
      Bref, « les joueurs conseillent souvent les gens autours d'eux sur le CPU à prendre pour leur PC », non, je ne crois pas, je n’ai jamais vu ça. Je ne crois pas connaître un joueur de console qui puisse me dire spontanément ce que leur console a comme CPU.
      
      Par contre :
      
      Mais tu ne crois pas que avoir un pied dans le monde des consoles permet de rester proche des éditeurs de jeu
      
      Oui, tout à fait !
      
      qui sont souvent des précurseurs [de l'utilisation des CPU]
      
      Oui, mais pas vraiment pour les CPU (qui ne sont pas vraiment spécifiques ni avant-gardistes aujourd’hui), on le voit surtout avec les GPU et l’architecture RDNA d’AMD (voire la démo de Unreal & PlayStation 5).
      
      Pour sûr, le marché console permet à AMD de garder sa place chez les éditeurs même si les joueurs PC utilisent massivement du Nvidia. Les moteurs comme Unreal, Unigine, etc. son conçus pour plusieurs plate-formes incluant le marché du PC sous Windows avec majoritairement du Nvidia et le marché des consoles avec majoritairement du AMD.
      
      Là encore c’est assez similaire au fait que le marché Apple garantit à AMD des clients « grand public » qui utilisent le GPU pour des calculs : Apple n’intègre plus de Nvidia depuis 2019, mais Apple pourrait concurrencer AMD directement sur le terrain des GPU de bureau pour ses produits dès 2021, mais pour donner du répit à AMD il y a peu de chance de voire Apple rivaliser avec une Vega de si tôt.
      
      Cela dit, pour revenir à Intel, rien ne semble empêcher un vendeur de console de choisir une solution Intel, mais il est fort à parier que pour cela il faudrait un CPU+GPU intégré aussi performant qu’un APU Ryzen avec une Vega intégrée. Intel exprimer clairement son ambition d’entrer dans le haut de gamme du graphisme, donc à voir pour le futur. Intel pourrait aussi être choisi pour des produits moins gourmands, comme on le voit il y a convergence entre le « centre multimédia » et la console de jeu. Une machine qui permet de s’abonner à Canal+ ou Netflix et aussi de jouer à des jeux, sans viser la concurrence frontale avec la Xbox et la PlayStation sur ce terrain pourrait avoir sa place. C’est le pari que fait Atari avec son Atari VCS mais ils ont aussi fait le choix d’AMD. Mais clairement, un CPU+GPU Intel pourrait séduire pour ce type de projet. Le marché du joueur occasionnel qui perd quand même l’air de rien sa journée sur des machins monétisés sur mobile a bien ses systèmes d’exploitations et matériels spécifiques…
      
      ce commentaire est sous licence cc by 4 et précédentes
      - [^] # Re: AMD dans les consoles next-gen
        
        Posté par vv222 (site web personnel) le 03 septembre 2020 à 21:51. Évalué à 6.
        
        Ordinairement un joueur de console ignore les composants qu’il y a dans la console.
        
        Assez ironiquement, j’ai l’impression que les personnes qui s’intéressent vraiment aux composants des consoles… sont en fait les joueurs sur PC ;)
        
        [^] # Re: AMD dans les consoles next-gen
        
        Posté par devnewton 🍺 (site web personnel) le 11 septembre 2020 à 10:51. Évalué à 4.
        
        Question de compétences !
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: AMD dans les consoles next-gen
        
        Posté par Kannagichan le 24 novembre 2020 à 00:12. Évalué à 0.
        
        Rien n'a voir ,personnellement , j'ai souvent du mal à discuter avec les joueurs PC , ils connaissent en général que les composant PC (bon maintenant tout les composants consoles sont des PC).
        
        Mais je les trouvent en général moins curieux sur les architectures "exotiques" , sans parler de bonus/malus qu'apporte d'autre architectures ;)
        
        Je dirais le contraire , ce n'est pas avec l'architecture PC que tu as une bonne vision de l'informatique :)
# statique vs dynamique

Posté par reno le 01 septembre 2020 à 12:16. Évalué à 5.

Le problème est que les optimisations du compilateur fonctionne dans un monde 'statique', alors que l'utilisation de ton cache va dépendre des applications qui tournent sur le CPU: le compilateur va bien marcher pour les HPC ou il n'y a qu'une seule application qui tourne a la fois.
Sur tout le reste, à mon avis le compilateur ne peut pas être compétitif par rapport a l'OoO et aux caches "dynamiques".
- [^] # Re: statique vs dynamique
  
  Posté par Nicolas Boulay (site web personnel) le 01 septembre 2020 à 12:30. Évalué à 6.
  
  cela me rappelle les tentatives "move machine", ou l'instruction cpu se résume à lire un registre pour l'écrire dans un autre, certains sont des vrai registres, d'autres des ports d'entré vers les opérateurs. Il faut bien sûr gérer les latences "à la main" (écriture de l'adresse dans un registre, lecture de son contenu dans un autre). Si on veut rajouter une unité de calcul, il faut ajouter des registres, et donc recompiler…
  
  "La première sécurité est la liberté"
# Très intéressant mais…

Posté par Cyrille Pontvieux (site web personnel, Mastodon) le 01 septembre 2020 à 14:33. Évalué à 6.

On (Je) comprend pas tout:
- parce qu'aucune relecture n'a eu lieu avant de faire « envoi » et du coup des bouts de phrases ont été réécrites mais des bouts de l'ancienne phrase persiste. On constate ça tout du long
- certaines notions ou abréviations ne sont pas décrites. Tout le monde n'est pas expert CPU/GPU.

Après c'est ptre que j'ai juste à passer mon chemin sur ce journal ?!
- [^] # Re: Très intéressant mais…
  
  Posté par Oliver (site web personnel) le 03 septembre 2020 à 11:36. Évalué à 1.
  
  La lecture de ce journal n'est pas confortable, et une partie du lectorat est certainement frustrée de ne pas avoir tout compris.
  
  Est-ce que l'équipe modération pourrait refaire une passe ?
  
  Ou encore mieux : le remettre dans l'espace de rédaction pour y intégrer des commentaires très intéressants et le republier en dépêche ?
  
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
  - [^] # Re: Très intéressant mais…
    
    Posté par claudex le 03 septembre 2020 à 14:44. Évalué à 6.
    
    Est-ce que l'équipe modération pourrait refaire une passe ?
    
    C'est un journal, en général, l'équipe de modération ne fait que des modifications limitées sans demande de l'auteur.
    
    Ou encore mieux : le remettre dans l'espace de rédaction
    
    C'est un journal il n'y ait jamais passé
    
    republier en dépêche
    
    Perso, je n'en vois pas l'intérêt (même si j'ai apprécié le journal).
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Très intéressant mais…
      
      Posté par Ontologia (site web personnel) le 14 septembre 2020 à 19:08. Évalué à 1.
      
      republier en dépêche
      
      Perso, je n'en vois pas l'intérêt (même si j'ai apprécié le journal).
      
      De toutes façons, cette dépêche ne parlant pas de logiciel libre, elle n'aurait pas pu être acceptée…
      
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: Très intéressant mais…
        
        Posté par Tonton Th (site web personnel, Mastodon) le 28 septembre 2020 à 22:39. Évalué à 1.
        
        cette dépêche ne parlant pas de logiciel libre, elle n'aurait pas pu être acceptée…
        
        N'importe quoi…
# Typo ?

Posté par Firwen (site web personnel) le 02 septembre 2020 à 09:37. Évalué à 5.

Sauf erreur de ma part tu as un typo ici :

Ceci est constaté avec des Benchs montrant qu'AVX2 a tendance à faire baisser les perfs générales du processeur quand on l'utilise conjointement avec autre chose.

C'est AVX512 à ma connaissance qui réduit la fréquence CPU quand on l'utilise intensivement, et non AVX2 :)
# One Task One processor

Posté par Firwen (site web personnel) le 02 septembre 2020 à 10:47. Évalué à 10.

Très bon article, sur un ressenti assez justifié.

Oui l'avenir d'Intel semble assez sombre à moyen terme.

Il y a plusieurs raisons derrière le choix d'Apple et d'autres (Amazon, Marvell, Samsung, etc) à créer leur propre processeurs.

- Maturité de l'écosystème ARM

La démocratisation des processeurs ARM sur smartphones et les efforts de fondation comme Linaro (https://www.linaro.org/) ont fait que la software stack compatible ARM a énormément mûri ces dernières années.

Un bon 95% des logiciels Open Source Linux x86_64 (serveur & desktop) peuvent maintenant tourner sur ARM sans problème avec des performances similaires.

- L'émergence de processeur ARM Serveurs / puissants

Plusieurs constructeurs ont commencer à faire des processeurs ARM serveurs et ont prouvé que ARM avait sa place sur le marché des processeurs "beefy".
Incluant les séries ThunderX de Marvell (https://www.marvell.com/products/server-processors/thunderx2-arm-processors.html) ou les machines ampère ( https://amperecomputing.com/).

Ce qui a ouvert la porte à plusieurs société spécialisées dans le hardware haut de gamme à faire la même chose comme récemment Amazon (https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd), Nuvia (https://nuviainc.com/leadership) ou Apple (https://en.wikipedia.org/wiki/Apple_A13).

Ceci sur un marché qui était la chasse gardé d'Intel et d'IBM : le processeur haut de gamme.

- La fin de la loi de Moore et l'émergence des architectures spécialisées

La fin de la loi de moore a fait que le monde du HPC s'est détaché des processeurs haut de gamme (historiquement IBM POWER ou Intel/ADM) pour s'orienter vers des architectures spécialisées. Soit des architectures avec GPU ou des architectures entièrement designé pour le HPC comme pour Fugaku (https://en.wikipedia.org/wiki/Fugaku_(supercomputer) ) avec A64 FX https://en.wikipedia.org/wiki/Fujitsu_A64FX ).

Le TOP 500 illustre bien le phénomène avec le top du classement presque entièrement dominé par les architectures hybride (GPU) ou spécialisées.

- Le degroupage entre designeur et fondeur

Historiquement, les gros designers de processeurs étaient également des fondeurs: Ce n'est plus le cas. Même les grands noms de se monde comme Intel, AMD ou IBM passent maintenant par des sociétés comme TSMC (Taiwan_Semiconductor_Manufacturing_Company) ou Global foundries (https://en.wikipedia.org/wiki/GlobalFoundries) pour réaliser leur chip.

Ce qui a eu comme effet, indirectement, de rendre plus accessible le marché de la création de processeurs avec des sociétés de toute taille qui s'y attaque de front (Huawei, Samsung, Qualcomm, Marvell, Nuvia, Amazon, Apple, Fujitsu) et donc de fortement secouer le monopole d'Intel.
- [^] # Re: One Task One processor
  
  Posté par claudex le 02 septembre 2020 à 10:55. Évalué à 10.
  
  Historiquement, les gros designers de processeurs étaient également des fondeurs: Ce n'est plus le cas. Même les grands noms de se monde comme Intel, AMD ou IBM passent maintenant par des sociétés comme TSMC
  
  Intel est encore fondeur. Même s'ils vont utiliser d'autres usines, ils n'ont pas encore annoncé l'abandon de leur business de fonderie. Samsung est aussi encore fondeur. Par contre, Global Foundries a abandonné la course à la finesse de gravure.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: One Task One processor
    
    Posté par Firwen (site web personnel) le 02 septembre 2020 à 15:48. Évalué à 6.
    
    Intel est encore fondeur. Même s'ils vont utiliser d'autres usines, ils n'ont pas encore annoncé l'abandon de leur business de fonderie.
    
    Oui, et c'est justement une des raisons pour lesquelles ils ont tellement de difficulté à sortir du 7nm.
    
    https://www.tomshardware.com/news/intel-announces-delay-to-7nm-processors-now-one-year-behind-expectations
    
    Ironiquement alors que d'autres comme AMD le font déja via TSMC.
    - [^] # Re: One Task One processor
      
      Posté par Nicolas Boulay (site web personnel) le 02 septembre 2020 à 15:56. Évalué à 8.
      
      Attention tout de même, la taille annoncée n'est pas vraiment la même selon le fondeur.
      
      "La première sécurité est la liberté"
- [^] # Re: One Task One processor
  
  Posté par Kerro le 02 septembre 2020 à 15:58. Évalué à 7. Dernière modification le 02 septembre 2020 à 15:58.
  
  La fin de la loi de moore a fait que […]
  
  Vous êtes combien à être au courant ?
  - [^] # Re: One Task One processor
    
    Posté par lasher le 02 septembre 2020 à 21:07. Évalué à 6.
    
    La loi de Moore (doublement des transistors sur une même surface tous les 24 mois) est invalidée depuis 5-6 ans je dirais (d'autres iraient p'tet jusqu'à remonter à 2012). On fait toujours augmenter le nombre de transistors, mais il n'y a plus de doublement.
    - [^] # Re: One Task One processor
      
      Posté par Nicolas Boulay (site web personnel) le 03 septembre 2020 à 10:26. Évalué à 5.
      
      Ce n'est pas sur une même surface, mais pour le même prix.
      
      "La première sécurité est la liberté"
      - [^] # Re: One Task One processor
        
        Posté par SpaceFox (site web personnel, Mastodon) le 03 septembre 2020 à 11:07. Évalué à 8.
        
        D’après Wikipedia, les deux sont vraies (dans le sens où elles ont été énoncées par Moore à peu près dans ces termes).
        
        La connaissance libre : https://zestedesavoir.com
    - [^] # Re: One Task One processor
      
      Posté par Thomas Debesse (site web personnel) le 03 septembre 2020 à 12:16. Évalué à 9.
      
      Au delà de la question des transistors pour une même surface, un même coût, ou une même consommation énergétique, on peut aussi regarder les performances pour un calcul similaire. J’avais développé ce sujet dans un précédent commentaire d’un précédent journal, mais pour résumer (source : Benchmark Phoronix) :
      
      Je cite mon commentaire de l’époque :
      
      En juillet 2013 le FX 9590 était ce qu’AMD avait de mieux à offrir pour le marché « desktop » (avec un TDP de 220W). En février 2020 le meilleur qu’AMD propose pour le même marché est le ThreadRipper 3990X (avec un TDP de 280W).
      
      Si tu linéarises la progression, ça fait du +300% par an. D ’ici 2021/2022 AMD aura atteint les 4nm dans sa gravure en production et pourra offrir plus encore. En 10 ans ça va finir par être conséquent. [NDA: je répondais à un commentaire qui disait d’Intel que « +10% à chaque génération, en 10 ans ça finit par être conséquent »].
      
      Alors oui c’est un benchmark favorable, mais même avec un benchmark pensé pour être défavorable car n’utilisant qu’un seul thread (et le point fort du TR 3990X est d’être le CPU avec le plus de cœurs/threads du marché), t’as plus de 200% de gain en moins de 7 ans.
      
      Je n’ai pas de ThreadRipper 3990X, mais j’ai des tâches qui ont la même progression sur le matos AMD que le raytracer testé par Phoronix (j’utilise un autre raytracer) et j’ai un FX 9590 sous la main pour comparer. Si j’extrapole les performances que j’ai pu tester sur d’autres processeurs actuels d’AMD, une tâche que met près de 2 jours (1 jour et 18 heures avec tous les cœurs à 100%) à produire un rendu sur un FX 9590 mettrait 15 minutes sur un TR 3990X.
      
      Et si tu ne peux pas acheter « le meilleur qu’AMD a à offrir » (qui est grave cher, ne le nions pas, 4000€) mais que tu te contentes d’acheter un processeur qui est dans la gamme de prix où était le FX 9590 à l’époque comme un Ryzen 9 3900X (400€), tu multiplies facilement par 5 les performances. Sur un test réel, un rendu qui mettait 5h ne dure plus qu’une heure. Et le TDP du Ryzen 9 3900X c’est 105W.
      
      Donc, comparons 7 heures de calcul avec un CPU à 220W de TDP contre 1 heures de calcul à 105W de TDP… ou 42 heures de calcul avec un CPU à 220W de TDP et 15 minutes avec un CPU à 280W de TDP… La progression d’AMD est énorme, Intel ne suit pas.
      
      Je pourrai ajouter que l‘offre d’AMD était en deça de ce que proposais Intel à l’époque, donc le graphique augmente artificiellement l’écart par rapport à ce qu’on aurait si on prend la même génération tout concurrent confondu… Mais tout de même, que l’on compare le prix ou le TDP, la performance de calcul s’est retrouvée multipliée par au moins deux tous les deux ans, très largement. Et rien n’empêchait théoriquement Intel de concevoir des produits aussi performants dans le même temps, sinon plus tôt qu’AMD si on considère qu’ils avaient de l’avance sur AMD.
      
      ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: One Task One processor
    
    Posté par FluffyHamster le 02 septembre 2020 à 21:22. Évalué à 6.
    
    Je sais pas a quel point c'est ironique, mais la loi de moore on en parle quand même vachement moins. CF les déclarations de Moore lui même, ou des CEO d'intel et de nvidia par exemple. Sans dire qu'elle est morte, elle est mal en point. Et je sais plus ou je lisais ça, ils argumentaient qu'intel n'avait même pas tenté d'actualiser les 18 mois en 24 (alors que le CEO à admis qu'ils étaient plutôt à 30), ils ont juste arrêté de mettre le terme dans tout leur power points.
    
    Wikipedia a un beau graph, ou déjà on voit la courbe s’aplatir, et surtout on voit que les CPUs qui la maintienne artificiellement vers le haut sont des monstres, des epyc 32 coeurs, xeon phi 72 coeurs et compagnie, des socs qui réunissent toute les puces d'une carte mère en une. Dis plus simplement, ce sont quand même des puces dont le nombre de transistor double uniquement par ce qu'on en a doublé la surface, ce qui me semble un peu pervertir la prédiction qui parlait aussi de densité ?
    Si on devait rester dans le grand public ou dans une gamme comparable avec l'évolution post 2010, on est plus dedans. Intel vient quand même de passer 4 ans avec le même CPU quad core…
    Dans les GPU c'est également plat (enfin…) avec 4 ans / 2 générations par node voir plus (ou des petits bonds, genre 16, 14, 12 et même pas chez le même fondeur et sachant que le 14 à la même densité que le 12 chez TSMC).
    - [^] # Re: One Task One processor
      
      Posté par flan (site web personnel) le 02 septembre 2020 à 21:58. Évalué à 7.
      
      Un des avantages de la loi de Moore est d'avoir suffisamment de versions pour que chacun puisse avoir raison :)
      - [^] # Re: One Task One processor
        
        Posté par claudex le 02 septembre 2020 à 22:05. Évalué à 10.
        
        Est-ce qu'on double le nombre de version de la loi de Moore tous les 18 mois ?
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: One Task One processor
    
    Posté par Firwen (site web personnel) le 03 septembre 2020 à 08:53. Évalué à 10. Dernière modification le 03 septembre 2020 à 08:55.
    
    Vous êtes combien à être au courant ?
    
    C'est une information réservée à un cercle très très restreins, ta sécurité ne peut être garantie si nous te mettons dans la confidence….
    
    Blague à part….
    
    C'est communément admis dans la communauté HPC que la loi de Moore vit ses derniers beaux jours, ce n'est absolument pas un tabou (excepté pour commerciaux). La plupart des podcasts / interview de Hardware Engineers que tu peux trouver font également consensus sur le sujet.
    
    La principale limitation étant énergétique. Même si la finesse de gravure s'améliore encore, il n'est pas envisageable (techniquement et économiquement) de faire des puces qui dissipent 400-500W en fonctionnement normale. C'est pourtant la voie empruntée actuellement par les puces actuelles par manque de solution technique alternative.
    
    Dans le monde HPC, ça s'illustre principalement avec la métrique principal maintenant qui est devenu non plus le FLOPS-pure mais le FLOPS/Watt.
    
    Car la difficulté n'est pas d'avoir une machine Exascale, mais d'avoir une machine Exascale qui peut tourner sans avoir sa propre tranche de centrale nucléaire pour l'alimenter et une deuxième tranche de centrale nucléaire pour la refroidir.
    - [^] # Re: One Task One processor
      
      Posté par Kerro le 03 septembre 2020 à 18:42. Évalué à 8.
      
      la loi de Moore vit ses derniers beaux jours
      
      Du coup elle est déjà morte, ou elle est sur une pente moins marquée ?
      Tu parles des supercalculateurs, je trouve que ce n'est pas flagrant du tout. La pente montre une très légère inflexion.
      
      Depuis le début des années 90 j'ai toujours entendu des gens qui affirment avec force que la loi de Moore c'est terminé. Ils amènent plein d'arguments qui leur semblent imparables, ils expliquent que c'est tellement évident (comme dans le présent fil), et 10 ans plus tard… ben rien :-)
      Forcément un jour ou l'autre ça va se terminer, mais après 30 ans d'erreur, normalement ça incite à un chouïa de circonspection.
      - [^] # Re: One Task One processor
        
        Posté par flan (site web personnel) le 04 septembre 2020 à 14:50. Évalué à 3.
        
        Sauf que si tu regardes la puissance des super calculateurs, tu prends en compte le nombre de processeurs (qui a lui aussi explosé), alors que la loi de Moore ne parle que d’un seul processeur.
        
        Mais je suis sûr qu’on peut en faire des versions sur le nombre de processeurs ou le prix total :D
        
        [^] # Re: One Task One processor
        
        Posté par Nicolas Boulay (site web personnel) le 04 septembre 2020 à 17:24. Évalué à 7.
        
        non la loi de Moore parle de nombre de transistors au même cout ou surface. Cela fait longtemps que plus de transistors ne signifient pas plus de puissance monothread.
        
        "La première sécurité est la liberté"
        
        [^] # Re: One Task One processor
        
        Posté par Kerro le 04 septembre 2020 à 21:01. Évalué à 4.
        
        si tu regardes la puissance des super calculateurs, tu prends en compte le nombre de processeurs (qui a lui aussi explosé), alors que la loi de Moore ne parle que d’un seul processeur.
        
        Il faudrait voir le prix des calculateurs.
        Je me trompe peut-être, mais je doute qu'ils coûtent nettement plus chers (en monnaie constante) pour doubler la puissance.
        
        Dans l'hypothèse où ils coûtent la même chose pour le double de puissance, alors la puissance par processeur coûte moins. Ce n'est pas fidèlement la loi de Moore, mais en première approximation ça tient la route sans avoir à décortiquer les caractéristiques.
        
        J'ai regardé vite fait sur 3 calculateurs, les prix sont du simple au double pour une même puissance, ou même prix pour plus performant l'année d'avant. Donc il faut une courbe sur plusieurs années et sur l'ensemble des grosses machines.
        En plus certains calculateurs ont un prix pour le programme complet, alors que d'autres c'est pour le prix du matériel (celui qui nous intéresse ici, même si ça n'est pas non plus exactement fidèle à la loi de Moore).
# Le problème de l'avx, c'est l'arrogance d'Intel et l'absence de redirection sur le développement log

Posté par cedric le 08 septembre 2020 à 08:34. Évalué à 6.

Que l'implémentation de l'avx512 ne soit pas super utilisable, car faisant chuter les performances globales est un problème. Mais combien de logiciel sont optimisé pour du vectoriel? Même l'avx2 ou néon, c'est marginal. Les compilos n'arrivent que marginalement à générer du code vectoriel. Et ce n'est pas mieux avec opencl dont la portabilité est fun, sans compter la plaie d'avoir a transférer les données entre les deux environnement de développement.

Intel pense encore être le seul fournisseur de hardware et que tous les développeurs de la planète vont avoir le temps d'optimiser pour ses plateformes spécifiquement. On dirait qu'ils n'ont pas remarqué que la majorité des codes qui tournent sur nos machines ne sont pas écrit en assembleur spécifiquement pour Intel. Résultat leur machine sont chroniquement sous utiliser.

Au lieu de se pencher sur comment écrire du code vectoriel portable, on en est encore à devoir tout écrire à la main. Et le plus terrible dans l'histoire, c'est qu'Intel tenait un bon début de théorie avec ispc, le compilateur spmd. Mais il devrait bosser à ajouter une infrastructure spmd à go, rust et faire que les implémentations comme cppspmd soit utilisable et utilisé.

Ca fait plus de vingt ans qu'on a des jeux d'instructions vectorielles dans l'informatique grand publique et on commence tout juste à avoir la technologie pour les utiliser, mais faut pas compter sur les fournisseurs de hardware.
# Northwood mon amour

Posté par ll0zz (Mastodon) le 10 septembre 2020 à 21:27. Évalué à 2.

[…]les multiples niveaux de pipelines qui ont conduit à l'échec du Pentium 4 (20 étages !).

Ne dites pas de mal de mon Pentium 4 M Northwood que j'ai aimé d'amour tendre !

Sous-volté et sur-cadencé c'était une tuerie de rapport perf/conso.

C'est la génération Prescott (alias le grille-pain) qui a souillé l'honneur de ce respectable nom.
# RISC devient incontournable sur supercalculateurs et ouverture de différents ISA RISC

Posté par tao popus le 11 septembre 2020 à 22:38. Évalué à 4. Dernière modification le 12 septembre 2020 à 09:27.
Il est intéressant de voir que dans le top 20 des supercalculateurs, il y a de plus en plus de RISC (déclinaison ARM (A64FX) qui écrase tout de Fujitsu (Japon), Power9 d'IBM (USA) et SunWay SW26010 de Sunway (Chine)) en terme de processeurs, ils sont même majorité dans le top 5, et les 4 premiers en sont, et on passe ensuite du simple ou double en performance de calcul.

L'European Processor Initiative à pour but de rattraper le retard de l'Europe et de faire un processeur domestique, un mix processeur basé sur ARM (après tout britannique) et accélérateur basé sur RISC-V (après tout maintenant logé en Suisse) avec pour objectif actuel, un supercalculateur exascale en 2023, et l'utilisation de ces puces dans l'automobile. L'accélérateur RISC-V pourrait selon les déclinaisons, avoir des spécialité AI, calcul matriciel (comme les GPGPU) ou les 2 unités, permettant d'avoir des puces optimisés aux différents besoins. De ce que j'ai lu, il y a débat sur le supercalculateur entre avoir des sous-clusters spécialisés dans chacune de ces tâches, et ainsi de pouvoir les assigner aux calculs à différents groupes dans ces domaines distincts. ou un cluster général ayant les deux simultanément. Bien sûr tout à été prévu pour la réutilisation du code existant et comme 99,9%+ des autres supercalculateurs ça sera du GNU/Linux de l'OpenMP pour la répartition des tâches, et ils choisissent ici LLVM pour la compilation.

Il ne faut pas oublier non plus que :
- On a des petites machines bien efficaces comme ordinateur portables (PineBook Pro) ou de bureau avec de l'ARM à présent. Ils sont utilisé majoritairement dans les téléphones mobiles/tablettes, box, et commencent à percer doucement dans le domaine des seveurs, Amazon, a développé son SoC ARM.
- De son côté RISC-V continue son bonhomme de chemin en tant que microcontrôleur (GD32V, compatible pin à pin avec les STM32, le plus répandu des ARM en microcontroleurs), processeurs qui ont la patate pour un vrai ordinateur personnel (HiFive). Processeurs destinés aux serveurs Alibaba à créé un XuanTie 910 ayant la puissance de calcul d'un ARM Cortex-A73, pour ses fermes de serveurs, comme Amazon avait fait son ARM.
- Du côté d'OpenPower, un Open Hardware Laptop Built On Power PC ISA.
# Fin de OoO

Posté par Kannagichan le 24 novembre 2020 à 00:26. Évalué à 3. Dernière modification le 24 novembre 2020 à 00:26.
A l'heure où les IPC sont autour et en dessous de 1 depuis longtemps, quel point de salut en dehors du massivement multi-coeur ?

Malheureusement c'est assez faux , il y'a 10 ans ,c'était vrai , mais depuis ces dernières années l'IPC tourne autour de 3-4 (je ne compte pas bien sur la moyenne avec le cache miss , ça serait sûrement bien moindre).
1. La fin de la nécessité du Out of Order ?
C'est une conviction que j'ai depuis longtemps : les incantations vaudou sur le code alors les compilateurs sont capable parfaitement capables d'optimiser eux-même le code (ceux qui me connaissent de longue date ici connaissent mon passé à ce propos) vont forcément disparaitre un jour, et plus que les avancées de GCC, du Intel C Compiler, c'est surtout Clang à mon sens, qui est en train de tuer la nécessité de tuer le Out Of Order : les compilateurs deviennent assez malin, on a assez de puissance de calcul pour optimiser au mieux le code et précalculer les dépendances read-after-write.
C'est aussi l'avis de F. Piednoel, qui partage cette opinion lorsque je la lui ai exposé.
À moins que tous les sites codées en NodeJS sauvent Intel ? X-D
Mais peut-être certains d'entre vous auront des avis divergents sur ce point, ça m'intéresse ;-)

Bref, m'est impression que les x86 d'Intel, descendant directs des archis Pentium, consomment énormément de transistors à descendre les IPC à moins de 1, avec le out of order, les multiples unités d'exécutions, les multiples niveaux de pipelines qui ont conduit à l'échec du Pentium 4 (20 étages !). Or tout cela, avec la progression des compilateurs va devenir de plus en plus inutile. Intel y a cru pourtant, avec Itanium, mais c'était trop tôt, et l'archi état trop complexe (VLIW)
Ouaw , je suis super content de lire ça !

Cela fait des années que je dis que le Out-Of-Order est de la merde est qu'on peut faire mieux. (consommation moindre pour un prix plus faible avec 8 coeur facile).

Et j'ai cette conviction depuis la PS2 , la PS2 était un proc VLIW donc 2 instructions/cycles , et il pouvait même faire la division sur un cycle bien programmer (la division étant sur 7-8 étages , c'est faciles à //).

Il avait pas mal d'instruction SIMD facilement parallélisable et bien mieux foutu que les SSE d'intel :)

Le reste étant sur 5-6 étages , donc une latence de 3 cycles, bref que dalle est donc on pouvait facile avoir 2 instructions/cycle.

La plus grande force était que même la mémoire "cache" était manuelle ,donc tu pouvais paralléliser le calcul et les transferts , et donc c'était possible de faire des calculs complexe (toute la transformation de perspective par exemple) sans aucun cache miss, un exploit technique , qu'on a jamais refait…

Et la le proc de la PS2 montrait deja l'avantage de ce genre de proc ,non seulement ce qu'il faisait était bien meilleur que les autre proc de son époque , mais en plus il pouvait se permettre d’être un "tri-coeur" en 2000.
(parce que forcément un proc VLIW avec "cache manuelle" , tu réduit ta consommation de transistor de beaucoup).

A l'époque il y'avait pas de compilo , mais de nos jours avec clang ,je suis sur qu'il y'a moyen de faire pas mal de chose sur ce point facilement.