Version imprimable du sujet

Écrit par : Lionel 12 Jan 2021, 09:19

L'une des forces des puces ARM, dont celles exploitées par Apple, est de cumuler des cœurs destinés aux applications nécessitant beaucoup de puissance et d'autres consommant peu d'énergie pour des taches plus légères.

Intel avait jusqu'à maintenant une autre approche moins efficace en faisant varier tension et fréquence.
Le fondeur vient d'annoncer qu'à la mi-2021 sortira une nouvelle architecture de puces appelées Alder Lake.
Ces puces embarqueront également deux types de cœurs, espérant ainsi réduire la consommation et augmenter l'autonomie des machines mobiles.

Ces puces utiliseront la seconde version de la gravure 10nm d'Intel, plus efficace.

http://macbidouille.com/news/2021/01/12/intel-se-lance-dans-le-biglittle

Écrit par : 1010 12 Jan 2021, 09:23

big.LITTLE non ?

Écrit par : cfendt 12 Jan 2021, 10:22

Je suis curieux de savoir si le processeur va tout gérer tout seul ou si il faudra une adaptation de l’OS pour gérer le tout... ou pire, une recomposition des applications!
De mémoire, sous Linux, il a fallu faire des modifications (qui datent de 2012/2013?)... donc une annonce de ce genre de la part d’intel doit dépendre d’une hypothétique prise en charge de Windows ! Sinon, aucun intérêt pour le grand public... ou alors j’ai raté un truc!

Écrit par : Lionel 12 Jan 2021, 10:32

Oui, Merci

Écrit par : SartMatt 12 Jan 2021, 11:25

Il faut effectivement une adaptation de l'OS, pour que le scheduler affecte intelligemment les processus aux différents cœurs, puisque les performances ne sont plus les mêmes sur tous les cœurs, comme à l'époque où l'HT est apparu sur des CPU multi-cœurs et était catastrophique sur les anciennes versions de Windows, qui pour deux processus lourds chargeait les deux cœurs logiques d'un même cœur physique).

Mais les noyaux Windows et Linux savent gérer ce genre d'hétérogénéité, puisque ça a été implémenté dans les versions ARM, et ça ne devrait donc pas être trop compliqué à adapter aux versions x86, si ce n'est pas déjà fait.

Écrit par :  Joe 12 Jan 2021, 13:46

Pas grand chose a adapter en effet, c'est comme si les coeurs plus léger étaient des coeurs plus rapide mais déjà occupés à x %.

Écrit par : iAPX 12 Jan 2021, 13:55

Le big.LITTLE je doutais au début, alors que ça c'est révélé être une solution extrêmement efficace pour optimiser la consommation ET les performances sur des produits mobiles, et pourrait être aussi très intéressant coté Cloud et serveurs sur le long-terme.

Intel a un énorme problème de gravure, que leur excellent R&D tente de compenser en partie face à AMD.
Pour les CPU largement disponible (10xxx), il n'en reste pas moins qu'à performance similaire, les CPU Intel consomment 2 fois plus que les CPU AMD aux performances similaires, plus précisément autour de 2 fois le TDP annoncé si on a une bonne alim et un bon refroidissement (forcément), près de 25W par cœur (cf. https://www.anandtech.com/show/16341/intel-core-i9-10850k-review-the-real-intel-flagship/2 )

Le big.LITTLE aidera pour l'autonomie, car pour les usages les plus courants on a pas besoin du niveau de performance délivré en pointe, très loin de là.
Mais ça ne résoudra pas les problèmes d'autonomie de ceux utilisant des charges lourdes, le M1 avec moins de 3W par cœur rapide étant très loin devant (essayez Intel Power Gadget, vous verrez combien vos cœurs Intel consomment!).

À cause de ses différents problèmes de gravures, Intel est dans la position qu'a eu AMD à une époque, et rien ne semble indiquer que le retard sera rattrapé.
Certains actionnaires prédateurs font d'ailleurs pression pour séparer conception et gravure, sous des prétextes fallacieux, pour revendre des bouts d'Intel à la découpe et faire du profit rapide au détriment de l'avenir de la société: ça sent le sapin.

Intel est-il affecté du syndrome PowerPC G5?!?

PS: il y a beaucoup à adapter pour un usage efficace, certains process nécessitant des cœurs rapides d'office pour limiter la latence, d'autres devant prioriser des cœurs lents même si longs à exécuter pour maximiser l'efficacité.
Sans compter le Dark Silicon come les unités AVX2 ou AVX-512 certainement non-présente sur les cœurs lents, avec émulation (comme sur les CPU en disposant) ou nécessitant de transférer la tâche sur un cœur rapide?!?

Écrit par : zarck 12 Jan 2021, 14:03

Lake, Intel toujours au fond du lac...

Il devrait changer de nom...

En ce qui concerne le 10 nm SuperFin... du marketing à deux balles... ou comment se cacher derrière son petit doigt...

Pour ce qui concerne la solution de sous traiter à TSMC ou Samsung, la demande est plus forte que l'offre, il suffit de voir les ruptures de stock chez Amd et Nvidia...

Écrit par : os2 12 Jan 2021, 15:23

bof, tu bullshits, comme trop souvent

https://www.techpowerup.com/272489/intel-14-nm-node-compared-to-tsmcs-7-nm-node-using-scanning-electron-microscope

Écrit par : zarck 12 Jan 2021, 15:41

Si Intel peut faire aussi bien qu'Amd on aimerait bien que cela se voit dans les produits Intel...

Quel est l'équivalent chez Intel ? à l'Amd ci dessous ?

AMD Ryzen Threadripper 3990X (4.3 GHz Max.)
Processeur 64-Core 128-Threads socket sTRx4 Cache 256 Mo 7 nm



AMD Ryzen Threadripper PRO
AMD termine avec du lourd, les Ryzen Threadripper PRO. La gamme comprend trois modèles, dont un 3995WX muni de 64 cœurs / 128 threads. Selon la société, « ils proposent une palette de fonctionnalités inégalée pour les utilisateurs de workstations, avec jusqu’à 64 cœurs, 8 canaux de mémoire vive, le support des modules RDIMM et LRDIMM, 128 lignes PCIe Gen 4 ainsi que des technologies de sécurité AMD PRO ».

Modèle Cœurs/Threads Fréquences Boost /Base(GHz) Cache (Mo) TDP (Watts)
AMD Ryzen Threadripper PRO 3995WX 64C/128T Jusqu’à 4,2 / 2,7 GHz 288 280
AMD Ryzen Threadripper PRO 3975WX 32C/64T Jusqu’à 4,2 / 3,5 GHz 144 280
AMD Ryzen Threadripper PRO 3955WX 16C/32T Jusqu’à 4,3 / 3,9 GHz 72 280

https://www.tomshardware.fr/amd-devoile-ses-ryzen-5000-mobiles-deux-nouveaux-ryzen-5000-et-ses-ryzen-threadripper-pro/

Écrit par : iAPX 12 Jan 2021, 16:13

Je me suis fait la même réflexion: cela voudrait-il dire que c'est le R&D d'Intel qui a des années de retard au lieu de la gravure?!?
J'avoue que je ne suis certain de rien sur les origines du problème d'Intel, mais que celui-ci est visible et évident: ils sont largués!

Voire complètement à la ramasse si on regarde le M1 avec ses 15W, même le A12z à 10W+ qui a 2 ans a une efficacité incroyable face aux CPU Intel actuelles.

Écrit par : Sethy 12 Jan 2021, 17:00

A lire de nombreux commentaires, j'ai l'impression que tout le monde voit la course comme une étape cycliste de plaine avec Intel qui aurait l'équivalent d'un problème de dérailleur.

Or, selon moi, on est plutôt en montagne avec sous les roues les fameuses barrière technologiques qu'on évoque depuis si longtemps et qu'on a un temps repoussé.

Intel fait course en tête depuis longtemps et soudain, il y a une nouvelle attaque tant des puces ARM qu'AMD.

Nouvelle car ce n'est pas la première d'AMD ... ni des processeurs RISC comme le sont les ARM (je rappelle qu'il y eut 25 ans passé il existait des versions de Windows pour les CPU MIPS ... autrement dit des processeurs RISC). Je le sais, j'ai administré un PDC NT 3.x qui tournait sur un R4000. Tout le monde prédisait alors la mort du CISC comme le sont les processeurs x86.

Tout le monde part de l'idée que cet effort initial va se poursuivre ... mais pour moi, rien n'est moins sûr car c'est une course où le sommet est dans les nuages. Evidemment dans une attaque, soit on est vraiment le meilleur et on a de quoi assurer, soit on "tape" dans ses ressources histoire de mettre de la distance avec les poursuivants.

Je ne vois rien dans les avancées d'AMD et d'ARM qui permet de penser qu'ils ne seront pas tôt ou tard confronté au même mur technologique.

Écrit par : maclinuxG4 12 Jan 2021, 17:06

intel as abusé de l'augmentation sur la fréquence avec un design reuse, et sans technologie pour réduire le volume, la puissance ne diminue pas:
Bref, c'est un voie sans issue (nombres de core + cache + fréquence)

Bref, un design sur 2 ans minimum, en tenant compte de la gravure.

Si la gravure, le TDP global ne diminue pas, ce n'est pas un processeur , mais la famille de processeur qui va plafonné, non seulement en performance, mais avec une TDP trop haute , principalement du à la fréquence
Si la fréquence diminue, tu perds de la puissance de calcul...


Comment se tire un balle dans la tète à la puissance n..........

Écrit par : iAPX 12 Jan 2021, 17:20

Le RISC a gagné, depuis une décennie.

Les CPU d'Intel et AMD sont RISC en backend, plus précisément de type Load-Store, avec une unité de décodage des jeux d'instructions x86, Amd64 et des extensions qui traduit ces premières en instructions Load-Store cachées et qui sont directement exécutées dans les boucles.
Il reste une énorme différence entre les mondes x86 et Amd64 avec ARM, les transactions mémoires et les garanties par défaut (ou leur absence pour ARM nécessitant de mettre plus souvent des barrières mémoire explicites).

Les CPU CISC sont mortes. Les jeux d'instruction CISC sont bien moins répandus que RISC mais présents encore et probablement pour longtemps.

Écrit par : Lionel 12 Jan 2021, 17:23

Intel s'est endormi dans une gestion de bon père de famille de son avance technologique, certain que rien ne pourrait le supplanter. Je ne les enterrerais pas pour autant car ils viennent de prendre des claques propres à réveiller un mort. C'est la survie de la société qui se joue maintenant, de quoi motiver pas mal de gens.

Écrit par : Sethy 12 Jan 2021, 17:33

J'ai appris quelque chose. Donc, il y a une sorte de JIT qui compile les instructions CISC en RISC, c'est ça ?

Écrit par : iAPX 12 Jan 2021, 17:52

C'est un transcodage plus qu'une compilation, certaines instructions communes aux deux types de jeu d'instruction n'étant pas traduites, d'autres si.
Par exemple déplacer une donnée de la mémoire vers un registre virtuel sera gardée telle-que, mais déplacer une donnée de la mémoire vers la mémoire sera traduite via un chargement de registre physique intermédiaire et donnera 2 instructions séparées.

Et pour revenir au sujet, Intel a un backend dépassé face à AMD, avec un mauvais IPC et une inefficacité énergétique incroyable même si le gavage de Watts et de Gigahertz permet de masquer les choses.
Mais si on compare avec le M1 d'Apple, on est totalement dans un autre territoire tant en terme de performances par cœur que d'efficacité énergétique, et comme je l'espérais tout le monde a -enfin- remarqué le surplace incroyable, y-compris les actionnaires de Intel.

Ce surplace créé aussi une hémorragie des meilleurs éléments coté R&D, entre autre à cause des magouilles de certains hauts placés, ce qui ne peut qu'affaiblir encore plus le géant aux pieds d'argile de Santa Clara.

Écrit par : SartMatt 12 Jan 2021, 17:52

Non, c'est pas aussi simple non plus. Parce qu'il tient compte aussi de l'aspect énergétique, certaines tâches seront envoyées en priorité sur les petits cœurs, même si les gros sont totalement libres et les petits déjà occupés.

Ni l'un ni l'autre. Aussi bien côté RISC que côté CISC, tous les CPU performants d'aujourd'hui font du découpage en µops (ce qui montre en fait qu'ils ne sont plus complètement RISC, ils proposent des instructions qui font en une seule instructions ce qui pourrait être fait en plusieurs instructions de base...) puis de la fusion de µops, ce qui s'apparente plutôt à du VLIW.

Les "grosses" instructions sont découpés en instructions plus petites et plus simples (µops).

Ensuite ces µops sont réorganisées et regroupées pour optimiser l'utilisation parallèle des différentes unitées de calcul du CPU (deux µops venant de deux instructions différentes peuvent être regroupées et être exécutées en même temps, et à l'inverse les µops d'une même instruction ne seront pas forcément exécutées en même temps, les CPU étant capables de faire x opérations arithmétique en parallèle + y opérations flottantes + z opérations d'accès mémoire, etc...

Écrit par : iAPX 12 Jan 2021, 18:00

Ça n'est définitivement pas du VLIW, et c'est totalement du load-Store qui est comme cela que l'on qualifie aujourd'hui le RISC, non lié à la complexité des instructions puisque justement la macro-fusion consiste à fusionner deux instructions simples en une instruction plus complexe, mais uniquement autour des échanges puisque Load-Store, donc un accès mémoire maximum par instruction interne exécutée.

Le Scheduling est séparé du décodage et effectuées sur leur résultat (souvent caché).
Une raisons évidente est que le décodage amd64 est inefficace avec peu d'instructions par cycle décodées (4 à 6) quand le Scheduler peut facilement en prendre 8 depuis le flux caché (plus encore si il y a des déplacements entre registres virtuels traduits en changement de pointeurs), le problème existant depuis les Core™ 2.
C'est pour ça -entre autre- que ce qui est caché en interne ce sont des instructions Load-Store (RISC) et non du VLIW.

Et avec ARM un modèle de transaction mémoire plus léger, avec moins de garanties, la plus grande différence entre ces CPU car simplifiant énormément le modèle mémoire, les unités load/store ainsi que le chargement prédictif (instruction de chargement potentiellement exécutée avant de futures écritures mémoires situées pourtant plus tôt dans le flux).

PS: les jeux d'instruction ARM 64 bits et AMD64 sont plus bien proches sémantiquement que leurs versions 32 bits, en revanche l'encodage ARM a été changé et simplifié en 64 bits alors que coté Amd64 il est rendu plus complexe qu'en 32 bits puisque étendant celui-ci plus encore.
L'encodage des instructions et le modèle mémoire sont les deux principales différences en 64 bits entre Amd64 (aka x86-64) et ARM.

Écrit par : maclinuxG4 12 Jan 2021, 19:14

non, après ARM, c'est le RISC-V , avec interopérabilité, c'est le jeux d'instructions qui est garantie, Autrement dit, i lest possible d'avoir des version de composants nouveau,
avec garantie que le jeux précédent soit utilisable...

Écrit par : maclinuxG4 12 Jan 2021, 22:00

la concurrence à intel avance....
https://www.tomshardware.com/news/amd-announces-ryzen-5000-mobile-cezanne-processors-zen-3-and-overclocking-comes-to-laptops?utm_source=twitter.com&utm_campaign=socialflow&utm_medium=social

Que fait intel ?

Écrit par : SartMatt 12 Jan 2021, 22:01

Et PowerPC également (mais de mémoire, pas compatible avec les firmware des Mac de l'époque).

Écrit par : jeandemi 12 Jan 2021, 22:18

C’est plutôt dans l’autre sens que ça s’est passé :
Le nouveau CEO avait fait des coupes franches dans les équipes de développement, ce qui a diminué fortement les frais fixes d’Intel, avec pour résultat une augmentation de la valeur de l’action, et pour le CEO des gros revenus.
Mais sans R&D, ça n’est évidemment pas viable à moyen terme, surtout dans un domaine aussi technologique !
Quand les membres du board s’en sont rendus compte, ils l’ont viré, mais le mal était fait et l’hémorragie des techniciens qualifiés est extrêmement dure à récupérer.
Ceci dit, AMD a déjà été dans une panade très forte, et la commission pour la concurrence a obligé Intel d’injecter de l’argent dans AMD pour lui éviter la faillite.
Il pourrait y avoir un retour de l’ascenseur de AMD vers Intel, via injection d’argent ou de transfert de technologies.
Aucun des deux géants n’ont d’intérêt à se retrouver seul en position de monopole

Écrit par : Cronos 13 Jan 2021, 07:36

en tant que candide, je me pose les questions suivantes:
il y a un groupe de coeurs à faible consommation (LITTLE) et un groupe de coeur à forte consommation (BIG) plus puissant; dans l'exécution d'un programme , c'est bien le programmeur qui oriente les tâches vers l'un ou l'autre groupe pour optimiser le sytème ?
l'orientation est-elle imparable ou peut-il avoir des erreurs ou de mauvaises orientations qui freinent l'exécution? si on optimise l'énergie consommée peut-on en profiter pour augmenter la fréquence? où se trouve la limite des architectures de ces processeurs? les recherches sur les ordinateurs quantiques (bit remplacé par qubit) ont-ils pour but de les remplacer?

Écrit par : SartMatt 13 Jan 2021, 09:45

Par défaut, c'est l'OS qui gère la répartition, mais je suppose que le développeur doit pouvoir donner des indications à l'OS pour l'aider à faire le meilleur choix.

Le développeur peut également prendre la main en fixant durant l'exécution ce qu'on appelle l'"affinité", qui consiste en gros à dire à l'OS "je veux m'exécuter sur tels cœurs et pas sur tels cœurs". Charge à lui dans de cas de détecter au préalable les caractéristiques des différents cœurs pour choisir au mieux (avec plusieurs paramètres à prendre en compte, big et LITTLE, mais rattachement des cœurs logiques à un cœur physique par exemple, voire en fonction des CPU, le partage de certaines ressources entre certains cœurs physiques*).

Enfin l'OS peut également donner la main à l'utilisateur pour gérer lui même l'affinité, à la place du développeur et de l'OS, mais le plus souvent avec une granularité plus faible. Par exemple sous Windows l'utilisateur a accès à l'affinité globale d'un processus, mais pas à l'affinité individuelle de chaque thread qui compose ce processus.

Les cœurs basse consommation ont plutôt tendance à tourner à faible fréquence. Par contre le fait d'envoyer certains threads sur les cœurs basse consommation va libérer en partie les cœurs hautes performances, ce qui devrait mener à être plus souvent dans des situations où seulement une partie des cœurs hautes performances sont chargés, ce qui permet au turbo boost de les faire monter plus haut en fréquence que quand ils sont tous chargés.

À priori, non. Les ordinateurs quantiques seront théoriquement extrêmement performants, mais seulement sur un ensemble très restreints d'opérations. Il n'y a aucun intérêt à essayer de faire tourner un traitement de texte ou un navigateur sur un processeur quantique.

Donc si un jour le quantique arrive chez le grand public (et personnellement, je n'y crois pas trop), ça sera sans doute sous forme de co-processeur dédié à certains calculs, aux côté d'un CPU binaire classique.


* Par exemple sur les Intel Core 2 Quad, il y a deux caches L2 partagés entre deux cœurs physique, si un programme a deux threads lourds exécutant le même code et/ou travaillant avec les mêmes données il sera donc plus efficace de faire tourner les deux threads sur deux cœurs partageant le cache L2 plutôt que sur deux cœurs ayant un L2 différent. À l'inverse, sur les AMD FX, chaque paire de cœurs partage une FPU, donc deux threads lourds ayant besoin de faire des calculs sur des flottants ont intérêts à être mis sur deux cœurs ne faisant pas partie de la même paire (comme avec les coeurs logiques de l'HyperThreading... il me semble d'ailleurs que pour profiter de la gestion mise en place pour l'HT les AMD FX déclarent la paire à l'OS comme étant deux cœurs logiques d'un même cœurs physique, bien qu'au niveau commercial ça soit vendu comme deux cœurs physiques... c'est techniquement un peu à mi-chemin entre les deux, quasiment tout est dédoublé, comme dans deux vrais cœurs physiques, sauf la FPU qui est partagées comme entre deux cœurs logiques).

Écrit par : Cronos 13 Jan 2021, 14:38

merci SartMatt.
cela est assez complexe comme beaucoup d'optimisation et pourrait utiliser l'intelligence artificiel?

Écrit par : maclinuxG4 13 Jan 2021, 14:54

si tu considère tous les applications (lente , moyenne , rapide), du schéduleur interne logiciel et hardware, cela aurait été possible.
Mais c'est difficile, car chaque mise à jour introduit des changements impossible à prévoir.

Apple, réalise quelques applications, les éditeurs de logiciel réalisent l'ensemble des applications.....Bref.

Écrit par : raoulito 13 Jan 2021, 15:19

ooh
un copro quantique, pour le coup oui ca aurait du sens sous reserve d’avoir des app qui sachent l’utiliser. Rendez-vous dans 50ans, à peut pret à l’epoque de la maitrise de la fusion nucleaire et des premiers tsunamis sur les cotes bretonnes...

Écrit par : iAPX 13 Jan 2021, 15:25

Il y a à la fois des heuristiques simples applicables (par exemple un processus "nice" avec une priorité plus faible serait envoyé sur un cœur lent par défaut, un processus interactif sur un cœur rapide par défaut) mais aussi la nécessité d'ajout plus de canaux de communications entre les processus/threads et le noyau, dans les deux sens, tout comme pour l'allocation mémoire d'ailleurs pour que le noyau puisse demander gentiment aux process de réduire leur empreinte mémoire lors de situation à forte pression (ou l'inverse).

L'IA pourrait trouver sa place, pour offrir plus que les heuristiques simples, si elle n'induit pas plus de consommation de ressources qu'elle n'en économise, et soit agir par Application grossièrement (et probablement inefficacement) soit par threads qui sont très dynamiques dans un système interactif, donc avec très probablement trop de travail à faire, mais sur les serveurs spécialisés effectuant des tâches répétitives ça me paraît évident que ça serait une voie à explorer.

Sur certains serveurs spécialisés un mix de nombreux cœurs à grande efficacité énergétique peut être vraiment intéressant, avec quelques cœurs hautes-performances, pour augmenter l'efficacité énergétique (autour de 50% du budget global!). Certains.

Écrit par : SartMatt 13 Jan 2021, 15:31

Je pense que le gros des cas est couvert avec des règles simples, et notamment une toute simple : si le threads ne monopolise pas 100% d'un cœur lent, on peut le laisser dessus, sinon on le passe sur un cœur rapide.

Le cas qui pose problème, c'est les applications qui consomment peu de temps CPU mais ont besoin d'une latence la plus faible possible. Là cette règle simple se plantera et les mettra sur les cœurs lents, alors qu'elles pourraient bénéficier d'une meilleur latence sur les cœurs rapides.

Mais je vois assez mal comment détecter ce type de cas. Le fait d'avoir besoin de latences faibles dépend vraiment énormément du fonctionnel de l'application, et je vois assez mal une IA réussir à déterminer et comprendre toute seule ce fonctionnel. Dans ce cas, je pense qu'il faut un mécanisme pour permettre au développeur d'indiquer que son thread est dépendant des latences, et que c'est donc ça qui doit être privilégié.

Et puis faut pas oublier aussi qu'une IA a un coût énergétique souvent élevé, même avec un coprocesseur dédié, donc le risque serait qu'elle coûte bien plus que ce qu'elle fait économiser...

Écrit par : maclinuxG4 13 Jan 2021, 17:49

est la fin du lead des processeurs en tant que fondeurs avec les technologies ?

intel n'as plus le choix:
https://www.lesechos.fr/tech-medias/hightech/intel-change-de-patron-a-la-veille-dun-virage-historique-1280768#xtor=CS1-26

Écrit par : iAPX 13 Jan 2021, 17:54

Je ne le pense pas, pas pour tout de suite et pas en séparant les entités et les CPU fabriquées par TSMC ou Samsung, ce qui serait une perte d'indépendance et de souveraineté des États-Unis.
Même Joe Biden n'osera probablement pas.

Il faut quand-même rappeler que seules 3 sociétés sont capables de faire des CPU pour ordinateur personnel qui tiennent la route: Apple, AMD et Intel.
Et seuls deux d'entre eux fabriquent des CPU pour serveur nécessitant une faible latence sur des charges complexes, personne d'autre ne sait le faire, pas même IBM dont les CPU serveur sont orienté bandwidth avec un SMT massif.

Donc non, Intel n'est pas encore mort.

PS: mais prêt à parier que les cœurs rapides Intel seront plus lents que ceux du M1 d'Apple, et que les cœurs lents consommeront pourtant autant que ceux-ci (3W par cœur grand max), alors l'intérêt sera mitigé par rapport à cette nouvelle génération de concurrents. La seule chance d'Intel est qu'Apple ne vend pas ses technologies à d'autres!
Une CPU M2 avec 12-coeurs rapides et 12 cœurs lents et un SLC étendu pour profiter des 45W de TDP devrait égaler un Mac Pro 28-cœurs et tripler (3X) les performances multithreadées de l'actuel MacBook Pro 16" 8-cœurs avec bien plus d'autonomie en usage réel!

Écrit par : maclinuxG4 13 Jan 2021, 18:47

il y as un autre fondeur aux USA en gravure 7 nm....et pas que TMSC ou samsung.



attention, AMD et intel ont le savoir de faire le CPU avec la fonderie (production).
Oui, Apple , avec le M1, commence mais pour el meoment avec les fondeurs ( TMSC ? autre ?)



apple as fait des serveurs à uen époque, mais je dois dire n'as pas avancé.


Le modèle économique, et les deux dernières années n'ont pas etre profitable pour intel:
-cela lest lié à la base de l'architecture qui arrvie à bout de souffle
-absence de résutlat poru rpoduit à 7 mn... depuis plus d'un an, AMD remet uen couche aujroud'hui avec les latops...il se retrouve dans la position d'aMD.

Au lieux d'investir en R & D le CEA qui part à mis à mal les équipes R & D de dev et technologique. C'est pas q'un perte de temps, c'est bien plus grave, AMD à mis des années à revennir



C'est pas aussi simple, Apple ne vendra pas cette technologie, soyons clair, pour conserver son lead sur la sécurité.
Par contre, linux doit etre porté (loi anti trust) et démarre

AMD continue sur la voie, et converse son architecture, M1 est la mais j attend de voir les performances processeurs du dernier AMD.
Coté vidéo, AMD vient de mettre la barre assez haut, il faut comparer un hackintosh ryzen avec le M1X





A suivre si le M1X est tenu (sans une TDP trop haute), c'est le vrai enjeux et c'est en grande partie une question de techno
-architecture
-technologie avec la gravure


NOTA: il y as déjà un ryzen 5900 avec un carte R6800 (gestion de type VGA, et logicielle), mais les perfo décoiffe....

quel chemin prendra intel ?

quel chemin prendra AMD ?

coté imac quel chemin prendra Apple ?

Écrit par : SartMatt 13 Jan 2021, 20:20

Non. AMD a abandonné la fonderie depuis 2009, quand elle a vendu toutes ses usines à Abou Dabi, qui a lancé GlobalFoundries. Et la fabrication des derniers CPU et GPU AMD n'est même plus confiée à GlobalFoundries, c'est TSMC qui fabrique toutes les puces AMD de dernière génération.

Non, aucune loi n'oblige à permettre de mettre Linux nativement sur les Mac. Sinon on trouverait aussi Linux nativement sur toutes les consoles et TV par exemple, mais aussi sur les iPhone, iPad, etc...

Écrit par : vlady 13 Jan 2021, 20:33

Je ne vois pas pourquoi tout le monde s'excite autour des M1, ok ils sont bons et alors ? Apple restera dans sa niche "pompe pour extraction de pognon des riches" et le reste du monde continuera d'utiliser le standard du marché X86.

Moi perso, je me contrefous de "incroyable performance per watt", j'ai un job à finir et la prise n'est jamais loin. Mon i7 10700K et presque aussi bon "en mono" et meilleur "en multi", je mets la RAM que je veux et les SSD que je veux. Perdre toute cette liberté (et la garantie 5 ans) juste pour "incroyable performance per watt" et s'embarquer dans les galères épouvantables si il y a un moindre souci ? Je ne sais pas, ça me tente pas trop, en tout cas pour le moment...

Détail amusante pour Intel, le nouveaux CEO (Pat Gelsinger) est l'ancien CTO ... d'Intel.

Écrit par : iAPX 13 Jan 2021, 20:40

Pourquoi s'exciter?

C'est que justement comparé à un 10700K qui peut pomper largement plus de 200W malgré un TDP affiché de 125W, avec seulement 15W réels (et moins dans le MacBook Air en continu), il fourni un niveau de performance énorme, contrairement à ton ordinateur portable qui s'il a la même autonomie doit peser 20Kg

Les MacBook Pro avec les versions plus puissantes de la même architecture écraseront le 10700K et probablement tous les autres avec un cinquième grand maxi de la consommation. La série 10xxx tenant plus de l'usine à gaz que d'autre chose, AMD consommant 2 fois moins pour les mêmes performances.

Pour Patrick Gelsinger, Intel semble avoir noté le leadership incroyable de Lisa Su (AMD) qui est pour moi totalement admirable.
Une CEO qui tient les rênes, dirige, choisi, sait faire du PR bien sûr, mais aussi capable de répondre sur des points de détail de l'architecture de chaque produit car elle les connait et les comprends intimement. Exemplaire!

Écrit par : vlady 13 Jan 2021, 20:52

Les ordinateurs portables ce n'est pas mon truc et ne le sera probablement jamais. Encore une fois, j'ai du mal à renoncer à pas mal de libertés juste pour "incroyable performance per watt" que j'aurai du mal à traduire en "incroyable différence des temps de compilations" ou en "incroyable robustesse du stack USB ou bluetooth"

A mon avis, le danger serait infiniment plus grande si cette innovation venait d'AMD, par exemple (ouverture, Linux etc). Avec Apple on est sûr que ça sera cher et que ça restera "dans la niche"...

Écrit par : biaucean 13 Jan 2021, 21:02

Peux tu préciser ce qui te faisait douter au début, ou bien quelle a été ton erreur d'analyse. J'ai envie de comprendre...

Écrit par : iAPX 13 Jan 2021, 21:12

Comme tout le monde, je fais des erreurs, je dis des conneries, et même mieux j'en écris ici tant qu'à faire, pour que ça reste à la postérité
Dans le même ordre d'idée on m'a montré du TCP/IP en 1992 (LINUX plein texte sur 386) avec de l'email et de l'hypertext (HTML avec liens locaux) sur disquette (ATARI) vers 1993, et il m'a fallu attendre 1994 pour que je percute et me jeter dessus (NT et Netscape Server, tant qu'à se tromper).

Quand le big.LITTLE est apparu en 2011, les cœurs "rapides" étaient alors sacrément lents et je ne voyais vraiment pas l'intérêt de mettre des cœurs encore plus pourris en terme de performance pour économiser de l'énergie.
Comme mettre un moteur de mobylette en sus dans une 2cv, pour lui faire consommer moins quand elle roule au pas.

Sauf que...
Alors que les CPU x86/Amd64 faisaient du surplace évolution après évolution, ce qui a probablement altéré mon jugement encore plus surement qu'un single malt très tourbé, je ne voyais pas vraiment la vitesse d'évolution des CPU mobiles qui nous a amené une décennie plus tard à avoir un iPhone 12 largement plus performant en monothread qu'aucun Mac x86!!!

Aujourd'hui le niveau de performance offert est incroyable, alors que l'autonomie est de plus en plus essentielle même pour nos ordinateurs de plus en plus mobiles (sauf pour 2020 et 2021! ), et là des déclinaisons largement moins performantes mais offrant de meilleures performance/watt en liaison avec les premières permettent d'offrir le meilleur des deux mondes, 50% d'autonomie réelle en plus et des performances largement doublées. En même temps (non Manu).

Un MacBook Air capable de 18h d'autonomie en usage léger ou une pleine journée de travail normal?
Un MacBook Air en même temps plus performant qu'un MacBook Pro 16" 8-cœurs sur des tâches lourdes sur la durée?!?

PS: et dans les ratés, le Thunderbolt et l'USB Type C, dont je suis fan maintenant pour les deux, annoncer depuis 5 ans les Mac ARM "pour l'an prochain" en ayant donc régulièrement tort (même si j'ai été un des tout premiers à en avoir un), et tout ça est bel et bien ici et d'aucun comme @SartMatt peuvent en témoigner!

Écrit par : biaucean 13 Jan 2021, 21:37

Donc c'est pas le big.LITTLE en tant que tel, mais son efficacité en pratique dans le contexte de l'époque, compte tenu des performances du matériel à disposition. A posteriori, c'est toujours plus facile ....
N'est pas singe malte troublé, qui veut!

Écrit par : maclinuxG4 13 Jan 2021, 22:01

rappe: M$ risquait le démantellement, lorsque apple allait mal, et à l'époque linux n'existait pas....,
l ne peux avoir un seul PC (une societe en situation de monopole)
idem sur les OS !!!!

Pour apple, un autre os suffit

M$ fera pareil

Écrit par : iAPX 13 Jan 2021, 22:07

Je crois plus en la législation Européenne autorisant la décompilation et l'ingénierie inverse pour assurer l'interopérabilité, et j'espère que Linux pourra être porté sur les mac avec puces T2 et surtout les Mac avec Apple Silicon.
Il y aura bien sûr des déconvenues (Touchbar, lecteur d'empreinte, Bluetoooth et WiFi, comme d'hab quand c'est propriétaire), mais le pire est à prévoir pour les Mac avec M1 et suivant puisque TOUT, absolument TOUT est propriétaire et créé par Apple, même si https://en.wikipedia.org/wiki/Darwin_(operating_system) pourrait aider en partie.

Quand à Apple elle a eu un Unix System V avec https://en.wikipedia.org/wiki/A/UX.

Écrit par : maclinuxG4 13 Jan 2021, 22:10

oui, car la AMD adresse le PC avec Windows, et les cartes AMD vidéo sont actuellement bien mieux.
NVIDIA est pourtant partir sur une base ARM....

La question est maintenant qui va supporter , linux windows, mac intel....

Apple parie ARM, mais la gamme vendu aujourd'hui repose encore sur mac intel, et cett game est conséquente.
(base utilisé actuellement et produit proposé à la vente)

Le nerf de la guerre, c'est les technologie de virtualisation à supporter(émulation, natif) et supporte d'autres OS.

attendons la suite. (je pense au moins cette année)

Écrit par : iAPX 13 Jan 2021, 22:20

Les Mac Intel sont morts, il faut plus de 12-cœurs Intel Desktop (Mac Pro 12-cœurs) pour concurrencer un MacBook Pro 13" M1 sur une tâche multithreadée longue comme la compilation de WebKit. De toute façon Apple les tuera, remplaçant ou pas. On peut/doit les oublier.

Quand à la vente, le MacBook Air, l'entrée de gamme MacBook Pro 13" et le Mac Mini c'est vraiment l'essentiel en terme d'unités. C'est plié.

Les Mac x86/Amd64 ne savent pas virtualiser les Apps iOS natives, les Apps Android natives, un Raspberry Pi, les serveurs ARM, Windows on ARM, L'avenir.
La seule virtualisation importante offerte est celle de Windows x86 ou Amd64, et accessoirement les serveurs x86/Amd64 mais sans intérêt sauf à faire de l'assembleur ou utiliser des intrinsics Intel en C.
Ça dépends donc de quelles plateformes on veut ou doit supporter, mais bien plus de plateformes sont supportables (le conditionnel!) par un Mac Apple Silicon que sur les anciens Mac, avec Linux, iOS/iPadOS/tvOS/watchOS et potentiellement Android et Windows WoA nativement.

Écrit par : maclinuxG4 13 Jan 2021, 22:20

Sans aide apple, tu ne peux pas, notamment chaque composant spécifique.
je ne pense pas qu'apple veuille reimplementer toutes les fonctions, j'imagine qu'il est prévue un cadre....

NOTA/ linux n'as pas de icloud, etc.

Écrit par : iAPX 13 Jan 2021, 22:27

Linux est un Kernel et en tant que tel n'utilise pas de Cloud ni iCloud propriétaire.
C'est d'ailleurs inutile voir nocif. À chacun de voir.

Ce que je veux dire c'est que même afficher quelque-chose ne sera probablement pas possible, ce qui limite grandement l'usage d'un ordinateur

Écrit par : maclinuxG4 13 Jan 2021, 22:32

cela dépend ce qu"apple a implémenter. Le comportemetn sera différent, à quel point ,je ne sais pas.
j'espère qu'il sera utilisable sous linux.

Écrit par : iAPX 13 Jan 2021, 22:36

Moi aussi, pour des raisons économiques et écologiques (comme quoi les deux peuvent être liées positivement), pour leur donner une deuxième voir troisième vie.

Linux est -pour moi- ma plate forme de développement (Ubuntu 20.04 LTS), la plateforme qui me sert à faire tourner la majorité de mon code, mais aussi avec d'autres distributions plus légères ce qui anime mes Raspberry Pi et qui permet de redonner vie ou de l'étendre pour d'anciens ordinateurs, évitant de jeter, de gâcher et retardant le moment où ils vont polluer.

Linux est écologiquement et socialement positif. Aucune surprise que Linus soit Nordique (Finlandais).

PS: macOS/iOS/etc et Android sont la démonstration qu'on peut corrompre l'Open-Source de BSD et Linux, avec un processus propriétaire et des morceaux essentiels propriétaires tout en mettant Darwin et AOSP totalement inutilisables tel-que à la disposition du public. Ça en est comique!

Écrit par : SartMatt 13 Jan 2021, 23:56

Rien à voir. Ce qui était reproché à Microsoft, c'était d'user de pratiques déloyales pour "forcer" les constructeurs de PC à livrer leurs machines Windows avec divers autres logiciels Microsoft et leur "interdire" de livrer leurs machines sans OS ou avec d'autres OS (réduction très importante sur le tarif de Windows pour les constructeurs qui ne faisaient que du Windows, ce qu'Intel faisait aussi pour essayer d'évincer AMD et Cyrix). Et Linux, ainsi que d'autres OS alternatifs pour PC existaient déjà à l'époque hein... Je rappelle que Linux est apparu avant Windows 3.1, et ce n'était pas le premier OS alternatif pour PC.

Dans le cas des Mac, Apple est à la fois le fabricant du matériel et l'éditeur de l'OS, on ne peut donc pas lui reprocher que son matériel ne supporte pas d'autres OS que le sien (encore une fois, cf ce qui se fait sur les consoles, les téléphones, les tablettes, et plus généralement tous les appareils "intelligents" d'aujourd'hui, à part les PC). À la limite, on pourrait peut-être le lui reprocher si soudain la part du Mac montait en flèche et s'il se mettait à représenter 90% des ventes d'ordinateurs...

On voit d'ailleurs bien ça avec ce qu'il se passe dans le monde Android. En Europe notamment, il a été reproché à Google de profiter de sa situation dominante sur les OS de smartphone pour favoriser ses produits dans d'autres domaines, et notamment son navigateur et son moteur de recherche. Suite à ça, Android a été mis à jour et désormais il demande aux utilisateurs de choisir leur moteur de recherche et leur navigateur par défaut dans une liste de choix. Un fonctionnement qui ne concerne toutefois pas les smartphones Google, seulement ceux d'autres constructeurs, et seulement si ces constructeurs n'ont pas des accords avec d'autres entreprises pour mettre par défaut leur moteur de recherche et/ou leur navigateur. Parce que les autorités considèrent que mettre Google et Chrome par défaut sur un smartphone vendu par Google, ça n'est pas une pratique déloyale vis à vis de la concurrence sur ces deux secteurs, Google n'étant pas en position dominante sur les smartphones. Tout comme mettre Yahoo par défaut sur un smartphone Samsung (c'est pas le cas, exemple fictif) ne constitue pas non plus un abus de position dominante, Samsung et Yahoo étant deux entreprises indépendantes. Seul le fait d'imposer Google et Chrome par défaut avec Android sur un smartphone non Google est un abus de position dominante.

Aucune loi n'interdit les monopoles : ça n'aurait aucun sens d'interdire à une entreprise d'être seule sur un marché, ça tuerait l'innovation. Dès qu'une entreprise fait une vraie innovation, qu'elle a breveté, elle se retrouve en monopole sur les produits dépendant de ce brevet pendant au moins la durée du brevet (par exemple, dans le domaine de la santé : il y a énormément de médicaments qui n'existent que chez un laboratoire, sans alternative dans un autre), sauf si elle le licencie. À l'inverse quand un marché est en perte de vitesse, interdire les monopoles contraindrait le dernier acteur du marché à fermer quand l'avant-dernier ferme, ce serait idiot (Sony a ainsi été pendant quelques années en monopole sur la fabrication de disquettes 3.5", avant d'arrêter lui aussi la production). Il y a aussi plein de monopole dans le domaine de la propriété intellectuelle. Par exemple, dans la plupart des pays, la Formule 1 ou Roland Garros ne sont diffusé que par une chaîne de TV, qui dispose dans ce pays d'un monopole sur les images des ces compétitions.

Une entreprise peut même se retrouve en monopole sans même s'en rendre compte et sans qu'elle n'en soit responsable, ce qui serait sacrément problématique si les monopoles étaient interdits... Par exemple, si je développe une application et que je ne la propose que sous Windows, et en faisant bien exprès de faire en sorte qu'elle ne marche pas avec Wine, hop, Microsoft se retrouve immédiatement en position de monopole sur le marché des OS pouvant faire tourner mon application... Sans même que Microsoft le sache, et sans rien avoir fait pour se retrouver dans cette situation (d'ailleurs, elle est peut-être déjà dans cette situation : j'ai sur mon PC un script que j'ai développé, qui n'a quasiment chance de fonctionner correctement sous Wine, vu qu'il sert à modifier des paramètres système de Windows... donc de fait, Microsoft est en position de monopole sur le marché des OS pouvant faire tourner ce script... marché ridiculement petit, j'en convient, puisqu'il y a grosso modo un seul client et qu'il ne veut qu'une licence parce qu'il n'a même pas besoin de ce script sur toutes ses machines, mais le fait est que sur ce marché Microsoft est bien en monopole). Bien entendu avec un exemple comme ça c'est anecdotique... Mais regarde le marché des consoles, et tu auras plein d'exemple bien moins anecdotiques : les fameuses "exclusivités", les jeux qui ne sortent que sur un modèle de console, sont un moteur de vente énorme. Avoir le monopole des jeux Mario sur consoles de salon, ça fait vendre des palettes entières de consoles Nintendo...

Par contre, il y a des lois qui encadrent les activités des entreprises pour éviter par exemple qu'une entreprise en situation dominante sur un marché n'en profite pour fausser la concurrence sur un autre marché. C'est principalement ça qui était reproché à Microsoft : elle profitait de son quasi monopole sur les OS pour favoriser ses autres logiciels, notamment son navigateur Internet Explorer et sa suite bureautique Office.

Écrit par : iAPX 14 Jan 2021, 00:16

Il faut vraiment se souvenir de cela, comment des sociétés avec une volonté hégémonique ont tué la concurrence à coût de milliards au détriments des clients (consommateurs et sociétés). À plusieurs reprises pour Microsoft (tant que ça passe...).

Et c'est passé, et après les concurrents morts et enterrés des "condamnations" tenant plus de la tape sur la main que de la grosse claque dans la gueule vraiment méritée, asseyant ainsi leur hégémonie mais aussi étant une prime à l'abus de position dominante.

C'est aussi à cause de cela qu'est né WebKit, la base de Chrome, Chromium, Mozilla Firefox, le nouveau Microsoft Edge et évidemment Safari.
Microsoft a abusé de sa position dominante sur les navigateurs sous Mac OS avec Internet Explorer 5 pour couper l'herbe sous le pied d'Apple en stoppant les développements pour tuer dans l'œuf toute velléité de plateforme moderne, et Apple riposta en développant Safari et le framework WebKit open-source (vraiment pour le coup) qui tua tous les concurrents, avec Microsoft utilisant Chrome/chromium basés sur WebKit pour sortir son nouveau navigateur.

Apple, quand on l'attaque peut riposter extrêmement brutalement, WebKit étant un exemple de la réponse à Microsoft qui est inégalé.

Écrit par : SartMatt 14 Jan 2021, 00:36

Ne va surtout pas dire à Mozilla que Firefox est basé sur WebKit ! C'est le truc qu'ils ne veulent absolument pas faire, car ils estiment que l'hégémonie actuelle de WebKit pose le même problème que l'hégémonie de IE à une époque : c'est le moteur qui devient le standard de fait à la place des normes du W3C.

Et ils ont hélas raison, car aujourd'hui on voit plein de développeurs web qui usent et abusent en prod des propriétés CSS -webkit- qui sont normalement à utiliser uniquement pour tester en attendant la standardisation des nouvelles propriétés... Résultat, Mozilla se retrouve obligé d'intégrer ces propriétés dans Firefox pour pas être handicapé, même quand ces propriétés ont depuis été intégrés au standard CSS (sans préfixe du coup), et avec un comportement parfois légèrement différent de la version spécifique WebKit testée préalablement...

Écrit par : iAPX 14 Jan 2021, 00:38

ben on va corriger cela... Ne me crucifie pas pour rien

Et oui, c'est encore un bordel monstre pour rien, une guerre commerciale, qui fait perdre du temps et de l'énergie à tous, au lieu de bénéficier!

Mais pour revenir sur le non-sujet, Apple a bien en...é (en 7 lettres, plaisir de profundis) Microsoft avec Safari et WebKit, ce dernier aimant cela utilise maintenant WebKit pour son propre navigateur.

Mais Safari est le plus performant surtout sur M1 (et paf le chien je suis sur le sujet).

Écrit par : vlady 14 Jan 2021, 00:45

Hector Martin est en train de porter Linux sur M1 profitant le fait qu'Apple autorise le boot d'un kernel non-signé.

Écrit par : iAPX 14 Jan 2021, 01:11

Oui c'est extrêmement intéressant et je l'ai contacté à ce sujet.

Écrit par : maclinuxG4 14 Jan 2021, 08:03

oui, mais assez généralement, lorsque tu est en situation de monopole et que la concurrence est tué....c'est qu'il y as distorsion de la concurrence.
Rockefeler as été démantelé , d'autres sociétés ont été scindées, hors high technologies.

il ne faut pas retomber dans une situation ou la distorsion de la concurrence est manifeste

a noter, que les d'autres acteurs permettent à ces trois sociétés d'éviter cela ( icloud, android, différents navigateurs, etC...)
Mais que ce passerait il si samsung traversait une mauvaise passe ?



si un autre Os est proposé sur la plateforme, c'est possible (exemple Win de M$).

après, si chacun propose sa plateforme, son OS, sans être compatible, les logiciels ne pourront être compatibles
notre écosystème se réduit ( la base mac intel, permet l'installation de 3 os, et d'applications cross compilé possible, )

maintenant, à ce jour,
-Apple, tend vers M1, M1X et mac os ,
-AMD Window et linux, compatible mac intel / ryzen
-M$ Window et son os, compatible mac intel et sa plateform ARM

coté latop ARM, une version arm existe sous linux

La fin du mac intel signifie bien plus pour le moment

Écrit par : raoulito 14 Jan 2021, 08:39

sans oublier qu’AMd a annoncé creuser dans le sillon ARM egalement (pour eux c’est bien plus facile « philosophiquement » que chez intel)
https://www.thefpsreview.com/2020/12/04/amd-reportedly-working-on-arm-based-processor-to-compete-with-apples-m1/

Écrit par : Lionel 14 Jan 2021, 08:55

C'est surtout de Nvidia qu'il faudra se méfier. ARM leur appartient maintenant, et ils ont une immense expérience dans le GP-GPU. Je ne parle pas des puces mobile, mais des gros calculateurs, le business le plus lucratif.

Écrit par : shawnscott 14 Jan 2021, 09:58

Ils viennent par ailleurs de changer de CEO.

Écrit par : iAPX 14 Jan 2021, 13:11

En même temps nVidia devait réagir très vite et très fort après l'annonce d'Intel qu'ils allaient créer leurs propres GPU pour le HPC, ce qui était une menace directe qui n'a pour l'instant accouché que de moins mauvaises GPU intégrées puis d'une dGPU médiocre sans marché et sans avenir, que Intel essaye de refourguer comme encodeur vidéo car ce sont les seules unités qui tiennent la route sur le bousin!

Le plus drôle c'est que Intel a du comparer sa nouvelle dGPU de 2020 avec la GeForce MX350, basée sur une architecture de 2016 gravée en 14nm, et non la GeForce MX450 plus récente qui l'écrase

L'alliance de facto Intel+nVidia étant rompu par le premier, nVidia veut attaquer directement et par lui-même le HPC, avec potentiellement plus de succès à mon avis car même si les communications sont essentielles pour exploiter efficacement le système il faut d'abord et avant tout avoir des unités de calculs...

Après le 80860/i860 puis Larrabee, Intel se prépare à foirer sa troisième tentative de faire une unité de compute à haute performance, la nouvelle Xe DG1 reproduisant le schéma déjà observé avec la i740 (PR, Hype puis immense déception). Ils ont perdu le marché, définitivement, par pure arrogance.
À la sortie du Xe DG1, on a du sabrer le champagne chez nVidia et AMD!

Écrit par : maclinuxG4 14 Jan 2021, 16:18

aujoud'hui juste pour commencer l'architecture zen 3 arrive sur les portables
chaque valeur TDP est indiquée.
ttps://hardware.developpez.com/actu/311762/AMD-annonce-de-nouveaux-processeurs-AMD-Ryzen-lors-de-sa-keynote-au-CES-2021-dont-les-AMD-Ryzen-Threadripper-PRO-qui-seront-proposes-au-detail/

et ceci avant l'avènement ARM.

Écrit par : fkanker 14 Jan 2021, 21:51

Très intéressant, mais attention : l'auteur a comparé les process sur le cache L2, or le cache scale mal sur les process récents. TSMC et Samsung sont d'ailleurs en train d'étudier des caches "verticaux" pour palier au problème. Bref, le 7nm de TSMC est plus dense que le 14nm+++ Intel (et ils le disent dans l'article).

Écrit par : iAPX 14 Jan 2021, 21:57

Ben sans être un génie, un Wattmètre suffit pour le constater

Car les CPU Intel avec un TDP de 125W consomment 250W quand c'est possible pour essayer d'égaler les CPU AMD du même tonneau, qui respectent -elles- leur TDP.

Écrit par : fkanker 15 Jan 2021, 07:03

Regarde bien les images. Tu pourrais penser que les process sont égaux. Donc ça vaut le coup de le dire.


Ce n'est pas que grâce au process et je pense que tu le sais très bien. Si vraiment on voulait voir l'impact du process il faudrait comparer le même design sur chaque process. On devrait bientôt pouvoir chez Intel (entre le 10 SF Intel et le 5 TSMC, voire le 3 TSMC), reste encore à voir si Intel tunera le process de TSMC de la même manière qu'AMD et les autres.

Écrit par : iAPX 16 Jan 2021, 01:26

Je ne pense pas qu'avoir un meilleur process résoudra tous les problèmes actuels de Intel, mais Patrick Gelsinger (le nouveau CEO) a au moins eu le courage de faire remarquer que Apple faisait maintenant mieux (bien mieux) et ça change de leur communication interne précédente, mettant en lumière le problème et qu'en quelques années Intel soit passé du premier au dernier rang pour les ordinateurs individuels!

J'espère qu'ils bougeront vite et fort, je crois en l'usage d'un sous-ensemble du jeu d'instruction Amd64 plus facile à décoder et Load-Store quitte à ce qu'elles soient plus longues unitairement (instructions existantes bien sûr mais pas les "raccourcis" historiques), car il y a un problème de décodage.
Il y a aussi le problème immense des transactions mémoire à cause du modèle choisi et qui ne peut être quitté sauf à foutre en l'air toute compatibilité, et peut-être aussi un manque de registres virtuels (16 registres virtuels adressables pour environ 200 registres physiques).

Quand on voit comment le AArch64 est simplifié face au AArch32 (dont le thumb-2 problématique) avec un ajout massif de registres virtuels adressables (32 contre 16 en Amd64), alors que le jeu d'instruction Amd64 est encodé avec plus de complexité et de variabilité dans la longueur que son prédécesseur x86, je ne pense pas que ça aide.

Le problème a été créé il y a 2 décennies, par soucis de conserver une partie d'un encodage inutile (une sémantique équivalente suffisait, fut-ce par assemblage d'op-codes, c'était d'ailleurs la "compatibilité 8080" du 8086) en l'étendant avec plus de complexité et sans revoir le problème sur le fond, tout comme le modèle de transaction du sous-système mémoire, et tout autant j'avais loué le travail de AMD à l'époque, autant maintenant on en voit des limites qui auraient été difficile sinon impossible à prévoir.

Écrit par : Sethy 17 Jan 2021, 02:53

Même si je ne comprends pas tout, tout en comprenant bien l'ampleur possible pour Intel, je ne suis pas certains qu'à 3 ou 5 ans cela ait de vraies répercussions. Je pense ici au marché des PCs pour particuliers ainsi que le PC "poste" de travail d'un collaborateur "lambda" (celui qui utilise la suite office et Outlook).

Y aura-t-il un switch massif vers Apple d'utilisateurs de PC actuels ? Même avec cette augmentation de performances ? J'en doute. Surtout que visiblement le support Windows ne s'annonce pas un long fleuve tranquille. Pour les utilisateurs Linux ... OK mais que pèse Linux ajd ?

En ajoutant tout le côté négatif de la réputation d'Apple (prix, suivi, compatibilité, etc.).

Apple va-t-elle licencier ses puces ARM ? Poser la question, c'est, je crois, y répondre.

Donc il faudrait que d'autres acteurs majeurs investissent sérieusement pour créer une puce ARM concurrente. Pour cela, il faudrait séduire des intégrateurs mais la concentration est telles que ceux-ci se réduisent lentement mais surement. En gros il y a HP, Dell, Lenovo et ... le reste.

Autre question, qui va se taper le travail pour réaliser un "UEFI / BIOS" standard pour ARM ? C'est bien ce manque qui fait qu'aujourd'hui MS met à disposition Windows pour ARM mais laisse aux intégrateurs le soin de réaliser "l'installer".

Qu'ont-ils à y gagner ? Surtout que ces puces ARM arrivent aussi avec une réputation de moins chères ... donc faire de la marge est plus compliqué.

Donc, certes, on peut écrire beaucoup de choses "sur le papier" mais dans la réalité ?

Écrit par : iAPX 17 Jan 2021, 11:04

Dans la réalité Linux est l'OS de loin le plus utilisé au quotidien par tout le monde, tout comme Jourdain faisait de la prose sans le savoir.
Les Mac M1 permettent de développer nativement pour un nombre incroyable de Linux ou dérivés, comme Android, nativement pour iOS aussi, enfin.
Et pour Linus Torvald c'était le facteur manquant pour la plateforme ARM, notamment en serveur: le poste de développeur en jeu d'instruction ARM!

Dans la réalité le rapport performance/prix des Mac M1 est imbattable, leur rapport autonomie/performance aussi.
Le premier facteur dans nombre d'entreprises étant l'OS et le second le prix en valeur absolu, et les employés héritant généralement de merdes innommables pour cette raison, celles-ci sont généralement sous Windows et ne bougeront pas d'un poil.
Dans les entreprises technologiques, les Mac sont souvent déjà là si pas majoritaires, tout comme d'excellents PC comme les Dell XPS, et ça fera bouger les lignes en faveur des premiers.

Dans la réalité, les fournisseurs de solutions Cloud, le marché le plus juteux pour Intel aujourd'hui, ils sont tous en train de créer leur propre plateforme ARM.
AWS en est à sa deuxième génération, là aussi imbattable en terme de performance/prix (et performance/Watt), et si elle apparaît pour créer des instances EC2 ça n'est que la partie hébergée de l'iceberg; son infrastructure et ses innombrables services sont en train de passer silencieusement sur ARM aussi.
Donc Intel a un énorme problème, car non seulement ça marche mais c'est meilleur dans de nombreux cas et bien moins cher à l'achat et à l'usage.

Il n'y aura pas de puces ARM concurrente pour les ordinateurs individuels avant quelques années, il y a déjà des ordinateurs portables avec des puces ARM mais ils ne sont pas concurrents et ne peuvent pas l'être, puisque justement comme tu l'écris "ces puces ARM arrivent aussi avec une réputation de moins chères" et ils se sont focalisés sur le "pas cher" en réutilisant tel-que des puces sous-performantes (et un OS sous-performant et pas fini).

Mais le problème d'Intel n'est pas uniquement sur les ordinateurs individuels, mais sur quasi tous ses marchés maintenant, les serveurs de Cloud, incluant les serveurs spécialisés appelés Routeurs, NAS, Firewall et autres joujoux, le HPC (via nVidia à qui Intel a déclaré la guerre avec leur 3ème projet de dGPU pour le HPC), les ordinateurs individuels bien sûr où d'autres vont arriver et les marges vont encore baisser, et je ne parle pas du secteur essentiel de la mobilité, perdu complètement après plusieurs tentatives très coûteuses pour y rentrer.

Je pense que Intel et AMD ont un problème de x86/Amd64, bien plus fondamental, Amd meilleur surtout grâce à l'accès à de meilleures gravures, mais essentiellement le modèle employé (Amd64 dérivé du x86) pourrait bien être leur Nemesis.

PS: AArch64 (ARM 64 bits) a une sémantique proche du x86/Amd64, mais avec un encodage/décodage très simple et un modèle transactionnel mémoire totalement différent, ARM a eu raison d'attendre pour son architecture 64 bits et tout remettre à plat plutôt que de la dériver de son architecture 32 bits.

À noter qu'un facteur essentiel est le type de code qui est vraiment exécuté aujourd'hui (et non il y a 20 ans!) avec une énorme lourdeur maintenant en-dehors des boucles courtes donc rendant le décodage primordial (et son cache bien moins utile).
Un exemple pourrait être le code du hash de python, qui me donne le tournis (il y a des raisons, mais...) !

Écrit par : Sethy 17 Jan 2021, 18:16

Global market share held by operating systems for desktop PCs, from January 2013 to July 2020 :

July 2020 : Linux 1.85%

Src : https://www.statista.com/statistics/218089/global-market-share-of-windows-7/

Écrit par : iAPX 17 Jan 2021, 19:03

C'est ça et si on compare les parts de marché pour les smartphone: Windows 0%
Les parts de marché pour les routeurs: Windows 0%
les parts de marchés pour les Télés: Windows 0%
Les parts de marchés pour les Montres: Windows 0%
Les parts de marchés dans les imprimantes: Windows 0%
Les parts de marchés dans les NAS grand-public: Windows 0%
Les parts de marché dans les IoT: Windows 0%

Linux est le plus répandu des OS, et de très loin, tu en as probablement plusieurs autour de toi par ordinateur Windows que tu as.
Et je ne serais pas étonné que Q/NX soit en second, ou un autre Unix-like de toute façon.

Écrit par : SartMatt 17 Jan 2021, 19:21

Le noyau Linux est le noyau le plus répandu. Mais Linux n'est pas un OS. GNU/Linux est un OS. Mais énormément d'appareils fonctionnant avec un noyau Linux ne sont pas des GNU/Linux (par exemple, Android, WebOS). Et si on ne devait retenir qu'un des éléments de GNU/Linux pour le qualifier de système d'exploitation, c'est GNU qui mérite ce qualificatif, pas Linux (avec juste le noyau Linux, tu fais rien, alors qu'avec GNU, tu as un système d'exploitation qui peut fonctionner par-dessus différents noyaux, de façon quasi transparente pour l'utilisateur, qui ne fera pas la différence à l'usage entre un GNU/Linux, un GNU/Hurd ou un GNU/kFreeBSD).

Et même quand il y a un GNU/Linux en couche basse, quand l'utilisateur ne peut interagir avec l'appareil que via une surcouche propriétaire, c'est quand même un peu exagéré de considérer que c'est un OS GNU/Linux "utilisé au quotidien" par l'utilisateur : du point de vue de l'utilisateur, le système d'exploitation est la surcouche propriétaire avec laquelle il interagit, sans jamais interagir directement avec les composants de GNU/Linux. L'utilisateur utilise cette surcouche, et c'est cette surcouche utilise GNU/Linux. Pas l'utilisateur.

Prétendre que quelqu'un "utilise au quotidien" GNU/Linux parce qu'il a un NAS sous DSM, un routeur sous un dérivé de GNU/Linux ou une imprimante utilisant un noyau Linux, c'est du bullshit digne d'un marketeux GNU/Linux, s'il y en avait...

Va demander aux gens quel système d'exploitation ils utilisent. La majorité de répondront Android et Windows. Car ce sont bien ces deux systèmes d'exploitations qui sont les plus "utilisés" par tout le monde.

Écrit par : iAPX 17 Jan 2021, 20:50

La réalité existe indépendamment de la connaissance ou surtout de l'ignorance généralisée, que tu sembles bien empressé à défendre.

Par exemple, GNU/Linux est l'OS le plus utilisé au quotidien par tout le monde, même si ça n'est pas affiché sur chaque appareil l'intégrant, de la même manière que la terre n'est pas plate...

Et pour revenir sur le sujet, précisément GNU/Linux sur plateformes ARM en AArch32 et Aarch64, voilà ce qui est essentiel et qu'on peut maintenant faire tourner nativement sur les Mac M1 et sur leurs futurs successeurs, à commencer par des dérivés comme Android ou d'autres unix-like comme iOS.
Ça amène d'ailleurs des problèmes de sécurité que Apple a -en partie- résolu depuis peu, les Apps iOS tournant dans un modèle d'exécution complètement différent, j'avais anticipé cela dès l'annonce et commencé à l'étudier en Août pour faire restreindre l'accès à nos Apps mobiles depuis macOS.
En revanche on peut coder nativement et optimiser nativement, pour les plateformes mobiles les plus répandu.

Écrit par : SartMatt 18 Jan 2021, 09:09

Et donc, le code machine est le langage le plus utilisé par les développeurs, puisqu'au final, tous les programmes qu'ils écrivent passent bien par du code machine d'une manière ou d'une autre pour s'exécuter ? Non.

Et bien c'est pareil avec l'OS. À partir du moment où l'utilisateur n'interagit pas directement avec des éléments de l'OS, on ne peut pas sérieusement prétendre qu'il utilise cet OS. Et ce n'est pas une question d'ignorance, mais bien une question d'utilisation : quand l'utilisateur utilise uniquement une interface surcouche (qui se limite parfois à 2-3 boutons et quelques LED, sans autre forme d'interface utilisateur... c'est vraiment du délire de prétendre que l'utilisateur final "utilise GNU/Linux" dans ce cas...), il n'utilise pas l'OS. Même si derrière cette interface va utiliser l'OS, et même si l'utilisateur sait quel OS tourne en dessous de cette interface.

Écrit par : raoulito 18 Jan 2021, 13:25

ARRETE!
iAPX est en train de dire que lorsque j’aligne deux commandes dans Automator sur Mac je code avec de l’ojectifC, du langage machine et du coup je deviens un putain de dev top niveau !!

Je VEUX qu’iAPX ait raison et je veux le mettre sur ma carte de visite !!

Écrit par : iAPX 18 Jan 2021, 14:27

Non, je veux dire que Chrome est l'OS le plus utilisé, en suivant ta propre logique

PS: @raoulito ça ne fait pas de toi un top dev, quoique ça ne puisse être les langages utilisées qui le détermine, mais ça démontre que le langage C est partout, plus encore qu'aucun OS, et absolument incontournable.

Écrit par : SartMatt 18 Jan 2021, 14:54

Non, car les gens doivent au minimum interagir avec l'OS de base pour se connecter à la machine, pour se connecter au réseau, pour lancer Chrome, pour gérer leurs éventuelles plusieurs fenêtres de Chrome, pour arrêter la machine, etc... Alors que sur un routeur par exemple, l'utilisateur n'a en général aucune interaction directe avec l'OS de base. Tout passe par l'interface web du routeur, même l'identification des utilisateurs (qui est d'ailleurs distinctes des utilisateurs définis au niveau de l'OS).

Mais oui, dans le cas d'un ordinateur avec un OS GNU/Linux qui lancerait Chrome automatiquement au démarrage, sans aucun accès à la couche GNU, et avec un Chrome adapté pour qu'il propose directement les commandes de bases nécessaires pour mettre en veille et arrêter la machine et configurer le système (réglage du réseau, du son, de l'affichage), je ne considérerai plus que l'utilisateur utilise GNU/Linux. Je considérerai qu'il utilise Chrome OS, qui est d'ailleurs aujourd'hui un OS bien plus utilisé que GNU/Linux. Et ce même avec les versions récentes de Chrome OS, où Google a ouvert l'accès à un terminal GNU Bash et à la compatibilité avec les applications GNU/Linux : bien que l'OS de base soit du GNU/Linux, ce terminal et les autres applications GNU/Linux que l'utilisateur installent tournent dans une VM, on n'a pas accès à la couche GNU/Linux native de la machine.

Tout comme je ne considère pas que je fait du code machine quand je code en C, en Python ou en Bash...

Tiens question... Si tu fais passer à quelqu'un un entretien d'embauche pour lequel le profil de poste précise qu'il est nécessaire d'avoir déjà utilisé GNU/Linux et que le type te dis que c'est bon, il a une TV Samsung sous Tizen, tu l'embauches ?

Écrit par : Sethy 18 Jan 2021, 15:35

Je précise que j'ai eu, vers fin '93, une machine avec Linux 0.99 patch level 14

Mais bon, on est quand même à la base dans une discussion sur le big.LITTLE ...

Et la question que je posais me semble quand même intéressante à débattre pour elle-même. En quoi dans le segment qui nous intéresse, c'est à dire les concurrents directs des MacBook, les iMacs et les Mac Mini, le progrès des puces M va-t-elle réellement affecter le marché PC à moyen terme ?

Écrit par : SartMatt 18 Jan 2021, 15:41

À moyen terme, bien peu d'impact à mon avis, si ce n'est que ça va peut-être pousser Intel a sortir de sa léthargie de ces dernières années.

À plus long terme, peut-être que ça favorisera l'émergence de PC ARM performants, mais ça rien n'est moins sûr. D'abord parce que les autres fabricants de puces ARM n'atteignent pas le niveau de performance des puces Apple, ensuite parce que dans le monde PC la rétrocompatibilité totale est beaucoup plus importante et elle reste compliquée à assurer par émulation, notamment pour tout ce qui est pilotes de périphériques.

Écrit par : Lionel 18 Jan 2021, 15:48

Totalement d'accord.
Apple est la seule à pouvoir tous les 10 ans faire la révolution dans sa clientèle fidèle et la forcer à tout racheter.

Écrit par : iAPX 18 Jan 2021, 15:55

Il est déjà affecté, avec l'éjection du CEO de Intel où les puces M1 ont probablement été la goutte faisant déborder le vase.

Sur le moyen-terme ça devrait faire progressivement baisser le prix des CPU Intel et AMD, car maintenant non-compétitives.

Pour donner un exemple la CPU Core i9-9980HK du MacBook Pro 16" 8-cœurs de haut-de-gamme et au prix public 480 € ht/1000 unités se fait égaler par celle du MacBook Air M1 vendu 940 € ht tout compris, rendant impossible toute concurrence en terme de ratio performance/prix même avec des écrans pourris, trackpad merdique et présentation plastoque.
Sans parler de l'impossibilité manifeste de Intel et AMD de prétendre avoir du haut-de-gamme dès que Apple sortira ses SoC plus performants, ce qui affectera la vision du marché, mais aussi l'industrie.

Les partenaires de Intel (et AMD) ont tous déjà noté qu'ils étaient largués en terme de performance/prix et autonomie, savent qu'ils vont être écrasés en performances pures, et ils doivent être extrêmement insatisfait de cet état de fait.

Le big.LITTLE servira juste à sauver les meubles en terme d'autonomie, mais coté performances pures en multithreadé il n'y a aucun espoir avant 2 ou 3 ans.

PS: le premier problème est l'encodage très complexe du jeu d'instruction Amd64 et ses extensions, rendant le décodage très lourd et coûteux, un problème depuis le Core™ 2, et accessoirement le modèle de transaction mémoire.

Écrit par : raoulito 18 Jan 2021, 15:58

en meme temps, tout racheter tous les 10 ans ca va on a connu pire...

Écrit par : fkanker 18 Jan 2021, 16:42

Qualcomm https://siecledigital.fr/2021/01/18/qualcomm-nuvia-apple/, qui a promis un design Arm mettant une raclée à tout le monde, et qui sur le papier a le personnel pour. Qualcomm se concentrerait sur les serveurs dans un premier temps (pour enfin tenter de percer...), mais ils vont certainement déborder sur les autres marchés.

Écrit par : Lionel 18 Jan 2021, 16:49

Comme je me plais à le dire, Apple a tellement fait trembler son monde qu'il ne reste que du sable à déplacer. 68xxx, PPC, Intel, ARM, abandon du 32 bit, du SCSI, du Firewire...
Seule une société à la (petite) clientèle captive peut se le permettre.

Écrit par : iAPX 18 Jan 2021, 20:09

Il faut rappeler que pour le 680xx c'est Motorola qui a abandonné Apple: le 68050 raté et pas sorti, le 68060 sorti donc 2 ans trop tard, et surtout Motorola décidé à abandonner la lignée, Apple a agit comme il a pu, testant différentes architectures RISC, dont ARM, et même envisageant de créer sa propre architecture RISC Scorpius bien trop ambitieuse (et achetant un Cray toujours présent dans les locaux pour ce-faire), pour finalement choisir l'architecture Power en partenariat IBM et ajoutant Motorola au mix.

Pour le PowerPC c'est IBM qui a abandonné Apple, faisant évoluer ses architectures résolument vers un usage serveur, principalement pour ses Mainframes, sans considérer les ordinateurs personnels et encore-moins les ordinateurs portables, faisant en sorte que la déclinaison grand-public PowerPC G5 pouvait aller très bien dans un PowerMac, avait besoin d'un chausse-pied pour faire passer sa TDP dans un iMac mais était absolument impossible à intégrer dans les PowerBook: là aussi une impasse et un abandon.

Quand au passage de Intel à ARM, l'autonomie et le rapport performance/prix sont tellement au-dessus, bien plus que le passage des PowerPC aux x86, que pour le coup c'est tout bénéfice pour le client, surtout que la compatibilité avec le code 64 bits existant est bien présente et même très utilisable au quotidien, meilleur que ce qu'on a vécu lors du passage aux CPU Intel!
Faut s'imaginer que le MacBook Air M1 fait tourner plus vite le code Amd64 (aka x86 64 bits) que mon MacBook Pro 15" 2017, et est 2X plus rapide en natif, c'est l'entrée-de-gamme au tiers du prix!

Donc les transitions précédentes étaient forcées, Apple n'existerait plus aujourd'hui sans les avoir fait, et si le coche ARM a été loupé une fois, sur cette transition les bénéfices sont évidents.
Il faut d'ailleurs se demander comment on aurait tous réagit si un concurrent d'Apple avait fait cette transition, et pas Apple, ridiculisant celui-ci coté autonomie, performance, performance/prix, etc. Regardez le https://www.dell.com/fr-fr/shop/cty/pdp/spd/xps-13-9310-laptop/cn93210 plus cher, moins autonome, moins bien équipé (écran pourri, trackpad, plastoc) et près de 2X plus lent que le MacBook Air M1 en 16Go/1To.

Nota bene: Apple continue à vendre des Mac Intel, va continuer à le faire, et on en trouvera encore pendant 2 ou 3 ans sur le refurb, on a le choix!

Écrit par : fkanker 18 Jan 2021, 20:55

Apple est en quelque sorte le dernier à faire la transition. Linux tourne sur Arm depuis quelque années, Microsoft a lancé la Surface Pro X en 2019. Pour ce dernier, certes les performances du SoC sont pourries (mais avec un quad Cortex X1 couplé à un quad Cortex A55 ce serait déjà bien meilleur), le système est instable, l'émulation est lente et 32-bits (mais le 64-bit arrive cette année), mais ça fait quand même quelques années que Microsoft propose de compiler vers Arm en plus de x86.

Écrit par : iAPX 18 Jan 2021, 21:04

Oui c'est vrai, tu as raison de le rappeler, mais le premier a bien le faire pour ce qui concerne les ordinateurs individuels avec des résultats incroyables, qui amènent maintenant des Mac à être le meilleur rapport performance/prix, voir inégalés.
Ils auraient pu le faire depuis 2 ans, le A12z 10W étant du niveau des CPU Intel de l'époque Quad-Core 45W, ils ont attendu d'être largement devant.

Microsoft y ayant été à-reculons, sans stratégie de groupe, Microsoft Office n'étant toujours pas en version native sur WoA (Windows on ARM), ni d'ailleurs Visual Studio, tournant les deux en émulation cacochyme (et 32 bits tant qu'à faire) si on veut s'y essayer.
À noter que Windows on ARM tourne bien plus vite dans une VM sur un MacBook Air M1 que sur les Surface Pro X Microsoft d'ailleurs énormément plus chère, un beau paradoxe!

Ce qui est sûr c'est qu'outre l'éjection du CEO d'Intel, tous les gros constructeurs sont en train d'y penser très fort, et que vendre des PC au rapport performance/prix inférieur à ceux des Mac va pas aider dans le secteur des $1000+ (à grosse marge) déjà contrôlé par Apple.
Et le big.LITTLE n'aidera en rien, sauf pour une autonomie comparable.

Écrit par : fkanker 18 Jan 2021, 22:13

Il leur fallait un effet waou. La transition est clairement bien faite. D'un autre côté, ils ne sont pas dans la situation de Microsoft qui peut prendre son temps.


Ca fait en effet désordre alors qu'Office tourne en natif sur Apple Silicon et pas sur WoA Mais pour la VM sur le M1 ils n'y peuvent rien, c'est un peu la faute de Qualcomm qui jusqu'ici s'est reposé sur ses marges.


Les gros constructeurs ont déjà des notebook Arm au catalogue, mais ça ne vaut pas mieux que la Surface Pro X. J'espère vraiment que Qualcomm va faire quelque chose de NUVIA, ça mettrait un sacré coup de pied à Intel et AMD.


C'est surtout pour la veille que ça va aider Intel, le fameux "Always On" des tablettes, c'est quand même un des gros arguments des SoC Arm. Donc si ça va aider. https://www.anandtech.com/show/15877/intel-hybrid-cpu-lakefield-all-you-need-to-know, le core big va forcément suivre vu que maintenant ils ont le feu aux fesses. Et je ne parle pas d'AMD (qui est dans la même situation) mais bien d'Arm Ltd qui les rattrape rapidement. Ca va être intéressant à suivre, car Arm Ltd va pousser Intel et AMD à faire du +20% de perf par an rien que pour survivre, ce qui va pousser Apple également. Le tout avec le point d'interrogation NUVIA.

Écrit par : chombier 18 Jan 2021, 23:12

Always on.
Aujoud'hui, nous avons l'Intel Management Engine always on. What else ?

Écrit par : iAPX 18 Jan 2021, 23:28

C'est lancé comme une boutade mais c'est vraiment très intelligent et je n'y aurais pas pensé.

La limite pour échanger des informations sur Internet ça n'est pas la puissance de traitement usuelle, n'importe quelle CPU 32 bits peut faire ça (ARM2, 68020 et 386 compris), mais souvent l'accès à des primitives cryptographiques matérielles (forcément chiffrement/déchiffrement symétrique, déchiffrement asymétrique, création d'empreinte, probablement chiffrement asymétrique), que d'évidence cette partie possède car étant l'essentiel de son travail. Et elle a un accès complet aux périphériques et aux communications, plus encore que la CPU principale qu'elle contrôle en partie.
Oui, je pense que Intel pourrait faire mieux et bien plus utile avec cette CPU très simple (mais cryptographiquement compétente) sous un dérivé de Minix 4, dès aujourd'hui, sur les PC existant.

Écrit par : Sethy 19 Jan 2021, 00:20

Mon impression, est que la compatibilité fini toujours par payer (en tout cas dans le marché grand public et des postes de travail, celui qui nous intéresse en tout cas au premier chef dans cette discussion).

Comparez les premiers PC XT et même AT aux Amiga, Apple II, etc. Comparez les puces iA-64 face aux extension x64 d'AMD. Pensez firewire, Thunderbolt, ... vs USB. Pensez OS de Smartphones alternatifs à iOS et regardez où en est Androïd aujourd'hui qui a su accaparer la plupart des utilisateurs de Windows phone et des autres systèmes concurrents. Pensez la domotique ... Apple a bel et bien été forcée de se ranger.

D'autre part, est-ce que la frange "technophile", celle qui a tort ou raison à "besoin" de puissance va réussir à elle seule à révolutionner le monde des PCs ?

Quel chef d'entreprise déciderait aujourd'hui de basculer un parc de 1000 machines ou plus vers Apple ? Sachant tout ce que cela représente comme coût (formation, baisse temporaire d'efficacité, complexité supplémentaire pour les nouveaux collaborateurs, ...) pour un gain de même disons 360 euros ? Cela ne fait jamais que 10 euros par mois de gagné sur une durée de vie minimale de 3 ans. Qu'il y en ait un par-ci par-la, OK mais pour que cela compte il faudrait qu'au moins 5% des grandes entreprises fassent ce choix.

Pour le reste et je n'aurai de réponse satisfaisante que d'ici quelques années, je ne suis toujours pas convaincu que les limites technologiques auxquelles Intel fait face vont miraculeusement disparaître pour les solutions alternatives. Que la solution ARM vienne de mettre un coup aux solutions x86, je n'en disconviens pas. Mais je reste sceptique sur le fait que l'écart va inexorablement se creuser. Intel sait aussi faire preuve de pragmatisme (rappelons simplement l'abandon de l'architecture Netburst au profit de "Centrino", nom générique, je sais).

Écrit par : iAPX 19 Jan 2021, 00:42

Je suis entièrement d'accord: la compatibilité avec iOS en premier lieu, la compatibilité avec Android, la compatibilité avec les IoT ARM à commencer par nos Télés et tout ce qui nous entoure. La compatibilité avec les serveurs sous ARM qui attaquent maintenant le marché du Cloud avec succès (plus rapides et moins chers), même le HPC avec nVidia.
Et les Mac M1 sont compatible avec la majeure partie du code existant, avec la probable possibilité de faire tourner les Apps Windows x86 ou Amd64 via une VM, déjà démontré.

Aujourd'hui Amd64/x86 c'est la fermeture, lent et cher, la plateforme matérielle principale dans le monde utilisé comme ordinateur personnel c'est un smartphone avec jeu d'instruction ARM. À l'inverse incapable de faire tourner du code ARM (juste le nombre de registres virtuels adressables plombe toute velléité d'essayer pour ne pas se ridiculiser car saturant les unités load/store).
Certains n'ayant d'ailleurs que celle-là, un smartphone ARM et sous Android. La plateforme.

Quand à Intel ils ont un énorme problème avec leur dogme "x86" et un encodage/décodage très complexe du à AMD (Amd64), le jeu d'instruction n'étant pas en cause mais son codage oui car trop complexe et non cachable efficacement en 2021 avec le code actuellement généré. Et un problème secondaire avec les transactions du sous-sytème mémoire.
Avec Apple on est passé de la 2cv Intel à la 205 GTI M1 en terme de performances.

ARM est là, et envahi chaque secteur, peu importe nos opinions car c'est un fait, c'est l'avenir et le Amd64 ou x86 le passé.
Et Apple est le seul à avoir des ordinateurs personnels performants nativement compatibles avec le futur!

PS: pour être sérieux le passé n'est pas le garant de l'avenir comme l'on déjà subit IBM écrasé par Sun puis Sun écrasé par Intel.
Ils doivent se mordre les c...lles chez Intel de ne pas avoir accepté que Acorn utilise un 286 sur leur Archimedes, puis d'avoir refusé de développer une CPU x86 pour l'iPhone!

Écrit par : chombier 19 Jan 2021, 00:48

Ton Apple ][ ne t'écoutait pas à l'insu de ton plein gré.
L'Apple ][ c'était avant 1984.

Écrit par : Sethy 19 Jan 2021, 03:23

Tu pourrais aussi citer la gourmandise d'Intel à propos du TB2, de ses câbles "certifiés", etc.

Pour la compatibilité des usages des puces, je citerais simplement le 6502 qui équipait tant le Commodore-64 que ... l'Apple II. Or ... question compatibilité logicielle ...

Pour moi, un standard ne devient vraiment standard que par le choix des autres. C'est bien la rapide adoption par toutes les constructeurs informatiques qui fait du PC ce qu'on connait aujourd'hui. Ayant travaillé pour un tel constructeur, je me souviens bien de ce qu'un contrôleur financier (chargé du contreseing des offres) avait affiché derrière lui (avant '94) : "Reseale PC is easy, the hard bit is make a profit !".

Pour moi, le passage massif à ARM (toujours dans le monde du poste de travail et du particulier) ne pourra se faire qu'à deux conditions :
- Qu'un standard émerge (fut-il porté par une seule compagnie) en particulier pour l'équivalent du Bios,
- Qu'une certaine compatibilité ascendante et descendante soit garantie.

Sur ce dernier point, il ne va pas sans dire que j'attends Apple.

Et qu'on soit clair, sur ce point justement, même le grand public est au fait ... de part le monde des Smartphones et de l'arrêt "unilatéral" du support. Je ne suis pas du tout ce marché mais un ami me disait récemment que Google avait mis la pression sur Samsung en ce sens. Cet ami me parlait entre autres des Smartphone One qui justement affichait dès le départ une durée de support minimale.

Sur des mobiles dans les tranches de prix 200-400, c'est bien ... pour des PCs à 1000+ euros ... y a intérêt à offrir plus que 3 ans de mise à jour mais aussi de compatibilité.

Et là ... ARM va aussi se retrouver pris au piège de choix qui seront faits et qui conditionneront les usages futurs. Car qui dit standards, compatbilités, etc, dit forcément lourdeur et ralentissement dans ce qui est possible comme évolution !

Écrit par : SartMatt 19 Jan 2021, 03:37

On peut aussi noter qu'il semblerait que depuis quelques temps ARM autorise ses clients à modifier l'architecture, et non plus seulement la micro-architecture.

Or qui dit modification de l'architecture dit risque de rupture de compatibilité. iAPX vante le fait que le M1 est compatible avec tout le monde ARM. Mais si maintenant les clients d'ARM se mettent à modifier l'architecture, la compatibilité ne se fera que avec le sous-ensemble de l'architecture commun à tous les clients ARM. Si ça reste limité à quelques instructions en plus ou en moins, comme c'est le cas actuellement entre Intel et AMD (qui font des CPU à 99+% compatibles, mais pas à 100%), ça va. Mais si ça diverge de façon plus significative, ça pourrait ruiner cette "compatibilité".

La rigueur d'ARM a imposer un respect strict de l'architecture a longtemps été considérée comme un défaut de ARM, mais il ne faudrait pas qu'ils tombent dans l'excès inverse en ouvrant trop grand le robinet...

Écrit par : Sethy 19 Jan 2021, 09:10

Je reformulerais ça comme suit : La compatibilité n'est jamais due au hasard. Elle nait au contraire d'une volonté forte d'être compatible.

Et j'insiste sur les deux dimensions de cette compatibilité. A l'instant, c'est dans le choix de nombreux assembleurs mais c'est aussi dans la durée. Sur un PC de 2008 initialement sorti avec Windows Vista (mais avec les drivers pour XP), on peut installer Windows 7 ce que j'ai fait (et même apparemment Windows 10).

Le PC a 13 ans ... et on peut "encore" installer le dernier OS du jour ... Et je précise que ce PC pilote aujourd'hui une CNC (fraiseuse à commande numérique).

Écrit par : SartMatt 19 Jan 2021, 10:25

Tout a fait. Et ça peut aussi aller dans l'autre sens, chose extrêmement rare chez Apple : la plupart du temps on peut mettre une ancienne version de Windows sur un PC neuf (sur un PC d'aujourd'hui, XP est peu probable, mais une bonne part doivent pouvoir faire tourner 7). Microsoft offrait même officiellement cette possibilité aux entreprises sans racheter de licence (un PC acheté par une entreprise avec Windows 7 pouvait être downgradé en XP, avec Windows 10 il peut être downgradé jusqu'à Windows 7). Ce qui est bien utile pour une entreprise qui veut garder un parc informatique cohérent mais n'est pas encore prête à engager une migration vers la dernière version de l'OS, ça lui permet quand même d'acheter des machines neuves et de les intégrer dans son parc sans rompre la cohérence.


Et oui, clairement il y a une volonté forte d'être compatible dans le monde PC. Je redonne souvent une petite anecdote qui l'illustre bien. Il y a maintenant fort longtemps, Microsoft éditait un logiciel de comptabilité personnelle, MS Money, dont je suis utilisateur. Le marché n'étant pas bien gros, MS a abandonné ce produit, en 2005 pour la VF. Quand j'ai testé les premières préversions publiques de Windows 10 en 2014, ça faisait donc déjà 9 ans que Microsoft avait abandonné ce logiciel. Et pour la première fois, il ne marchait plus sur une nouvelle version de Windows (car il avait des dépendances sur des vieilles versions d'IE). Cette incompatibilité a tout de même été corrigée et quand la version finale de Windows 10 est sortie, Money 2005 tournait au poil dessus (et 5 ans plus tard, tourne toujours au poil sur les nouvelles versions). Microsoft a fait le nécessaire pour que les vieux softs dépendants de vieilles versions d'IE continuent à fonctionner. Et déjà en 2011, 6 ans après la sortie, Microsoft avait publié sur son site une dernière mise à jour de Money 2005 lui retirant toutes ses dépendances à des services en ligne et installable directement sans avoir installé au préalable une version antérieure, pour qu'il continue à fonctionner une fois que ces services seront arrêtés (car l'arrêt définitif des services en ligne posait notamment problème en cas de réinstallation : la version du CD ne pouvait plus lire les fichiers enregistrés par des versions mises à jour, et sans les services en ligne pas de mise à jour après l'installation). Voilà comment traiter correctement ses clients (bon, ce qui aurait été encore mieux, c'est de passer Money en open-source, ou au moins de documenter son format de fichiers, mais là c'est un peu trop leur demander je pense...).

Écrit par : jeandemi 19 Jan 2021, 11:51

C’est clair que c’est cette compatibilité qui fait la force du monde PC par rapport à Apple.

Que ce soit pour le logiciel comme l’exemple que tu cites, mais il y en a quantité d’autres ! De nombreuses sociétés ont encore des bases de données tournant dans une fenêtre DOS, et migrer vers un système plus récent est soit trop cher soit impossible (quand le développeur du logiciel a disparu par exemple)

Que pour le matériel (je pense par exemple à ceux qui ont des scanners SCSI, des palettes graphiques sur port COM etc. qu’il y a toujours moyen de faire fonctionner sur des PC Windows alors que ça fait plus de 15 ans que les Mac les ont placés au rebut). Quand c’est du matériel « pas cher » ce n’est pas trop grave, mais pour un scanner à plus de 5000€, même pour des pros, c’est plus gênant. Et il n’existe pas forcément de nouvelle version de ce matériel...

Écrit par : Sethy 19 Jan 2021, 17:20

C'est un peu le problème d'un forum tel que celui-ci. Il y a une sur-représentation d'un certain type d'usager. En plus le fait qu'Apple a totalement détourné le mot "Pro" de son sens initial n'aide pas.

Attention, je ne dénie à personne d'être "Pro" dans son domaine mais si on veut se poser en analyste, il faut voir un peu plus loin que son propre usage.

Écrit par : xpech 19 Jan 2021, 17:59

Il y a des limites quand mêmes j'ai un soft qui charge des dll de Microsoft pour faire du https, et elles ne fonctionnent plus avec les site modernes. Impossible de contourner le problème .. une vrai galère.

Écrit par : Sethy 19 Jan 2021, 19:47

Bien sûr, mais il s'agit ici d'un exemple. C'est surtout une approche qui est stigmatisée. Approche qui est courante dans le monde des Smartphone (et des tablettes) alors qu'elle est plutôt l'exception dans le monde PC.

Toute la question est de savoir quelle choix va faire Apple d'une part (un simple engagement de leur part serait déjà un grand pas. Je pense notamment aux acquéreurs de Mac Pro qui doivent quand même se demander jusqu'à quand OSX sera supporté. Pour rappel, au passage à Intel, seule 2 versions de l'OS sont supportées tant sur PowerPC que sur Intel (Source : https://fr.wikipedia.org/wiki/MacOS ). Heureusement à cette époque, il n'y a de sortie d'OS que tous les deux ans.