Un tri-bookmark qui se fait l'écho d'une tendance :
- «La marque de Cupertino serait en train de préparer activement le remplacement des processeurs Intel embarqués dans ses Mac à partir de 2020. La relève ? Elle serait bien évidemment assurée par ses propres puces ARM, conçues en interne.»
- Windows10 ARM est déjà là.
- Et même les fermes de serveurs s'y mettent, comme l'indique le récent tweet du PDG de CloudFlare (est-ce que le 1.1.1.1 tourne sur ARM !?)
Après les failles de janvier, c'est une lame de fond qui pourrait avoir de fâcheuses conséquences pour Intel. Le cours de bourse du fondeur aurait déjà "lourdement chuté".
# Effet de mode?
Posté par redo_fr . Évalué à 10.
… Mouais, bof… Jusqu'à ce qu'on trouve que les ARM sont eux aussi aussi troués que du gruyère au point de vue sécurité :-)
Je ne suis pas spécialiste de ces architectures, mais il me semble me souvenir qu'il existe pléthore d'ARM et que la norme étant assez "souple", les constructeurs peuvent y mettre à peu près tout et n'importe quoi, ce qui à mon avis va morceler le marché en créant des "niches" techniques…
On aura des applis "pour ARMv12" incompatible avec les modèles "ARMtheta" incompatibles avec les "ARMbloupi" etc, etc.
Sans compter que chaque constructeur ajoutera ses propres "failles" :-)
On morcelle le "web" avec les "mobapps" et on morcelle le matériel avec une foultitude de "normes" ARM peu compatibles entre elles…
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Effet de mode?
Posté par David Demelier (site web personnel) . Évalué à 4.
Oui mais au moins les processeurs ARM ne tournent pas minix en arrière plan avant ton OS, permettant à intel et la NSA l'accès complet à ton PC peu importe ton OS.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
y'a trustzone, c'est pareil. Un ring 0 que tu ne contrôles pas si tu n'as pas les clefs pour y envoyer des "applications".
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Tangi Colin . Évalué à 6.
La trustzone à juste rien à voir avec la solution d Intel, je suis désolée mais ton commentaire relève d une grosse méconnaissance du sujet. Trustzone est un environnement sécurisé de ton processeur. Sous Intel tu as un processeur différents qui tourne en arriere plan, sous arm si ton kernel linux (ou hyperviseur ou autre) ne fait pas un Secure Monitor Call (grosso modo un syscall hardware) et bien ton processeur/cœur ne rentra jamais dans le mode trustzone de ton processeur. La trustzone fonctionne sur un mode coopératif entre normal World et Secure World.
Donc pour avoir une trustzone qui ferait des choses dans ton dos en volant du temps CPU à ton Linux, faut une architecture avec un hyperviseur/moniteur qui fait périodiquement des SMC dans le dos de ton Linux ou un cœur dédié à ta trustzone. Très peu de systèmes sont architecturés de cette manière la.
[^] # Re: Effet de mode?
Posté par LaBienPensanceMaTuer . Évalué à 5.
A mon tour de nuancer ce commentaire: rien n'empêcherait un des étages de bootloader (bien souvent closed source sur ARM) de:
1. Loader le code dans la trust-zone
2. Le lancer.
Donc en fait, tu peux tout autant te retrouver avec quelque chose qui tourne en trust-zone sans le savoir…
Après, les impacts possibles de la trust-zone sur le reste du système me paraisse moindre que ce que propose Intel… mais je ne suis pas un professionnel !
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
Je pensais avoir répondu. J'ai bossé sur trustzone :) tu oublies un gros détail : trustzone peut récupérer les vecteurs d'interruption avant de refiler le bébé à l'OS en dessous. Il peut donc s’exécute avec une RTC, et l'OS ne verra rien. En tout cas pour la version TI.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Arvil . Évalué à 2.
C'est déjà le cas avec l'EABI, l'OABI, EABI-hf, les modes ARM et Thumb, le softfp/VFP/neon… L'ARM c'est déjà un beau bordel (ne serait-ce que parce qu'on doit ship une distribution par SoC…) mais il est vrai qu'il a favorisé l'émergence d'acteurs différents et plus variés que sous x86
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . Évalué à 1.
L'ARMv8 a balancé une bonne parti du bordel à la poubelle.
Le gros avantage de des processeurs ARM, le plus gros face à Intel, c'est justement qu'il y a plusieurs fondeurs, chacun avec ses propres designs, dans plusieurs pays, mais utilisant la même ISA… au lieu d'Intel et Intel uniquement pour le x86.
La chance que tous les puces soient ver-ollées made in NSA, alors qu'elles sont designées au quatre coin de la planète sont assez restreintes.
[^] # Re: Effet de mode?
Posté par Anonyme . Évalué à 9.
AMD a toujours un temps de retard mais de là à ne pas le comptabiliser c'est un peu fort. Surtout qu'avec la dernière architecture AMD est pas mal revenu dans la course.
[^] # Re: Effet de mode?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
Et puis,
AMD64quand même. D'accord, l'architecture a été publiée y'a 18 ans et les premiers CPU y'a presque 15, mais c'est pas à négliger dans l'histoire de x86.La connaissance libre : https://zestedesavoir.com
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . Évalué à -1.
Loi de moi cette idée mais mon point peut se comprendre en deux questions :
Le marché du x86 et x86_64 a été en quasi monopole depuis 20 ans. Si on peut louer les performances technique d'Intel, fait est qu'en pratique Intel tue et tuera toute concurrence en dehors d'AMD en utilisant ses droits de propriété intellectuel, ils l'ont déja fait et le feront encore.
[^] # Re: Effet de mode?
Posté par Anonyme . Évalué à 2.
AMD reste le concurrent le plus direct qui a obligé maintes fois Intel à proposer mieux. Cyrix avait le même rôle.
Si Intel est premier c'est parce que AMD ne suit pas que ce soit en efficacité énergétique, en performance monothread (une grosse partie des clients x86 sont joueurs) ou en développement rapide de leur gamme. AMD reste prisé pour son rapport perf/prix et son absence de gammes artificielles mais pour l'instant limité dans les stations de travail et les serveurs. On sort enfin de Bulldozer et d'une période morose en terme de prix et de performances.
Même si le système de licences d'ARM est ouvert à la concurrence, il n'y a pas beaucoup d'acteurs qui tirent la gamme vers le haut beaucoup se contentent de suivre. Et ce sont presque tous des fabless qui sont les clients de TSMC ou GloFo.
L'ISA d'intel n'est pas ouverte, mais VIA n'en fait rien non plus (je prédis que Zhaoxin sera aussi peu distribué que Nano).
[^] # Re: Effet de mode?
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 04 avril 2018 à 20:26.
Sur du Threadripper ça serait difficile avec 3 modèles de CPU.
Sur du AM4 on a 5 chipsets alors qu'on a à pein eles premiers CPU, pareil déjà du Ryzen 5 ou 7 (perso je comprend rien à la différence, les 2 on du 2 thread par core, du X par ci et pas par la, du pro par ci et pas par la) avec des trucs artificiels (SLI, overclocking autorisé ou pas…), et une critique sur Ryzen a bien été qu'AMD essaye de copier Inel sur des gammes artificielles! (et à mon avis ça leur est préjudiciable, et ça a été du moins un critère pour moi qui m'a fait garder Intel lors de mon choix : Intel fait pareil oui, mais AMD n'offre pas mieux donc égalité sur ce critère et au final ça a joué sur la "note" pour ma sélection).
[^] # Re: Effet de mode?
Posté par Anonyme . Évalué à 1.
Ah ouai, j'avais pas vu les chipsets. Effectivement ils commencent à faire bien de la merde. Ça et le PSP ça fait de plus en plus sous-copie d'Intel.
Perso, c'est l'incompatibilité DDR3 de Rysen et le prix bas du g4560 qui ont fixé mon choix il y a un an. J'avais aucun intérêt à attendre le Rysen R3.
[^] # Les jeux sont multithreads
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
L'argument ne tient plus depuis quelques années. Les moteurs de jeux récents gèrent bien 4 threads, et certains beaucoup plus. Cf les tests sérieux de jeux récents (i.e. ceux cohérents avec les attentes des joueurs, pas ceux en 720p options mini et une GeForce 1080 Ti « pour bien montrer l'impact du CPU »). Ça avait notamment posé problème à l'arrivée des Ryzen à cause de leur gestion particulière du SMT et de la communication entre cœurs.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les jeux sont multithreads
Posté par Anonyme . Évalué à 1.
Oui quatre threads, pas huit. C'était l'une des erreurs de Bulldozer. Il n'est pas possible de tout multithreader à l'infini et il y a un impact négatif en performances quand on veut saucissonner en sous-programmes. Et il y a encore des cas comme les émulateurs qui ne peuvent pas gérer quatre threads, l'exemple actuel le plus flagrant c'est Dolphin.
[^] # Re: Les jeux sont multithreads
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Non, l'erreur de bulldozer, c'est de faire passer des "threads amélioré" pour des cpus complet. Le thread intel est uniquement un ensemble suplémentaire de registre pour simuler l'existence de 2 cpu mais utilisant les mêmes blocs de calculs, cela permet de "boucher les trous" dans le pipeline vu sa longueur.
Bulldozer n'a pas dupliqué que les registres mais aussi les ALU, mais faire passer cela pour des cpu complet est gonflé surtout vis à vis de la FPU, ou du SIMD.
"La première sécurité est la liberté"
[^] # Re: Les jeux sont multithreads
Posté par Anonyme . Évalué à 1.
J'ai bien dit l'une des erreurs parce que c'était pareil avec un Phenom II x6 ou un i7 Nehalem : l'intérêt en jeu était dérisoire face à un i5 qui s'overclocke facilement.
[^] # Re: Les jeux sont multithreads
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
Néanmoins on commence à avoir des jeux qui affichent un vrai gain avec plus de 4 cœurs (+27 % entre 4 et 6 cœurs sur TotalWar Warhammer par exemple).
Quant à ton contre-exemple… ben c'est un contre-exemple, on en trouvera toujours :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les jeux sont multithreads
Posté par Anonyme . Évalué à 0.
Les jeux de gestion/simulation sont par essence blindés de petites IA, routines et animations indépendantes. C'est le genre de jeu le plus simple à diviser en threads donc pas étonnant de faire +27% de perf avec +50% de puissance CPU. Je dirais même que c'est très faible comme résultat alors que c'est le titre qui obtient le gain le plus haut.
Alors peut-être que les devs ont besoin d'être poussés et que l'arrivée des Coffee-lake 6 et 8 cœurs (merci AMD au passage) va les motiver davantage mais l'avancée restera lente.
Mon "contre-exemple" montre que ce n'est pas nécessairement de la mauvaise volonté des devs et qu'il y a des cas déjà existants où on ne peut pas tirer parti de threads supplémentaires et que la puissance par cœur reste un critère primordial. Le rôle du Turbo dans les CPU actuels est justement là pour palier à ce problème.
[^] # Re: Effet de mode?
Posté par calandoa . Évalué à 8.
« Si Intel est premier c'est parce que AMD ne suit pas que ce soit en efficacité énergétique, en performance monothread […] ou en développement rapide de leur gamme. »
C'est surtout que AMD ne suit pas en lavage de cerveau de consommateurs, en sabotage technologique et en corruption généralisée…
Pour rappel, après la sortie de l'AMD64, AMD avait une nette avance technologique et Intel les a proprement poignardés dans le dos en menaçant et distribuant des milliards aux constructeurs de PC pour leur interdire d'utiliser les chips AMD (e.g. $6 Md juste pour Dell), en modifiant leur compilateurs pour désoptimiser le code en fonction du CPU et en mentant joyeusement à tout le monde.
Il faut avouer qu'ils ont eu bien raison : ils ont été pris la main dans le sac et n'ont eu a payer que des amendes relativement faibles, et surtout, alors qu'un comportement aussi crapuleux aurait dû être largement dénoncé et condamné, même sur un forum technique avec des personnes censées s'y connaître, on fait croire que Intel ne doit son succès qu'à son excellence technologique… j'hallucine un peu que des crapules pareilles puissent s'en tirer aussi bien grâce à la naïveté et l'ignorance en vigueur dans les moulières.
Ce commentaire sur Reddit décrit en détail ces magouilles contre AMD (et en bonus celle contre Nvidia) :
https://np.reddit.com/r/pcmasterrace/comments/3s5r4d/is_nvidia_sabotaging_performance_for_no_visual/cwukpuc/
[^] # Re: Effet de mode?
Posté par Anonyme . Évalué à 0.
Jusqu'à ce que Core arrive. Il faut justement deux-trois ans du POC à la vente donc Intel a pataugé avec Netburst en attendant et a expérimenté le SMT.
À la génération suivante, K10 n'était déjà plus à la hauteur de la concurrence.
Intel a bien pourri les ventes d'AMD mais AMD a aussi pris une belle impasse avec Bulldozer qui a conduit à un ralentissement de l'innovation et une segmentation abusive chez Intel.
Belle démonstration de ta condescendance. C'était pas nécessaire.
[^] # Re: Effet de mode?
Posté par barmic . Évalué à 3.
Ben pour ARM il n'y a que ARM, non ? Là où Intel et AMD sont tous deux capables de proposer des évolutions.
Pour de vrai, il se passe quoi si ARM décide d'augmenter ses prix ? Les licences qu'il délivre ne sont probablement pas éternel.
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
En effet, c'est assez différent.
Pour ARM, on a ARM qui conçoit le CPU et fournit un (plusieurs, en fait) coeur qui est intégré par différents fondeurs dans leurs SoC (ou ils vont ajouter plein de périphériques autour).
Pour x86, on a Intel qui fournit le CPU déjà fabriqué et le chipset, mais qui ne permet pas à d'autres fabricants d'intégrer ce même coeur dans leurs puces. Par contre, on a d'autres implémentations indépendantes, chez AMD et Via en ce moment mais il y en a eu aussi chez Cyrix, IBM, et quelques autres (https://en.wikipedia.org/wiki/List_of_x86_manufacturers). Et on a encore plein d'autres entreprises qui fabriquent des chipsets pour aller autour de ces CPUs.
Pour moi ça donne un avantage au x86, pour deux raisons. D'une part il y a de la concurrence sur le design de l'architecture, et donc oui, Intel est obligé de continuer à faire évoluer son architecture sous peine de se voir rattrapé et dépassé (si ce n'était pas le cas ils ne s'embêteraient pas à sortir régulièrement de nouveaux modèles plus performants). Et d'autre part, quand on a un problème du genre Spectre/Meltdown, on a une petite chance que l'une des implémentations ne soit pas impactée. Le tout en pouvant exécuter les mêmes binaires sur ces différents CPUs, et donc avec un coût plus faible pour remplacer le matériel quand c'est nécessaire.
La solution la plus intéressante serait donc un jeu d'instruction standardisé (avec discussions entre les différents fondeurs pour la faire évoluer) et plusieurs implémentations. Mais ça risquerait de finir comme POSIX: un standard très minimaliste, et des extensions plus ou moins spécifiques à chaque implémentation.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
il y a aussi 2 licences sur le jeu d'instruction ARM, snapdragon et le A11 d'apple ne sont pas de cpu fait par ARM.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Prosper . Évalué à 4.
Pas seulement . ARM propose aussi la licence Architecture qui permet aux fabricants de designer leur propre coeur ARM . C'est le cas par exemple pour Apple , Samsung ou Qualcomm.
[^] # Re: Effet de mode?
Posté par barmic . Évalué à 2.
Mais globalement, si ARM décide de faire n'importe quoi, qu'est-ce qu'il se passe ?
[^] # Re: Effet de mode?
Posté par Prosper . Évalué à 2.
Aucune idée . Probablement une armée d'avocats au cul. J'imagine quand même que les contrats concernant les licences architecture doivent être blindés de toute part.
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . Évalué à 3.
Non, tu peux parfaitement acheter le droit d'utiliser uniquement le jeu d'instruction ARM et faire ton CPU toi même certifié compatible ARM. Là où avec x86 et Intel, c'est impossible, ou pratiquement impossible.
Il y a des tas d'acteurs qui font ça, aléatoirement :
- Qualcomm avec Centriq
- Cavium avec ses ThunderX
- Nvidia avec Tegra
- Apple avec ses A-Series
- Phythium avec Mars
- Applied Micro avec X-Genes
Fait quelquechose de similaire en x86 est théoriquement faisable, sauf qu'en pratique il faut une licence d'Intel qui n'en accorde pas ou plus. Nvidia a essayé, et s'est vite fait calmé.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Le plus gros problème pour arm est de ne pas avoir définit une plateforme minimale ce qui empêche de faire un binaire universel, ce qui parait délirant. On ne peut pas avoir une distrib unique "arm" comme une version 386 pour les compatibles x86, il faut une version différente par SoC ou presque.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par totof2000 . Évalué à 2.
???
T'exagères pas un peu la ? C'est pas plutôt les couches basses de l'OS qu'il faut réadapter ? (c'est une vraie question).
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
J'ai quitté TI depuis un moment, mais à l'époque, c'était impossible d'avoir un code qui teste là ou il est pour choisir le code suivant, comme le fait un x86. Je ne crois pas que cela a changé. C'était dû vraiment à des problèmes ultra bas niveau pour linux.
Il n'y a pas de BIOS standard, donc, il fallait setter les réglages de DRAM qui dépendent donc du contrôleur utilisé, mappé là ou le constructeur de Soc voulait, sans table standard pour la trouver. Et c'est pareil pour la RTC, et le lien série. Et je ne parle même pas des arbre d'horloge à gérer (PLL, switch) et autre "power switch". Et si tu le fais à tâtons, tu peux "bricker" la puce.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Faisons le point là-dessus.
D'abord sur OABI, EABI, EABI-hf: ce sont des ABIs, il y a exactement le même problème sur x86 selon qu'on utilise un compilateur Visual Studio ou un gcc, par exemple. Le CPU n'est pas directement concerné, sauf pour EABI-hf, qui se permet d'utiliser les registres des unités à virgule flottante directement (il faut que ces registres soient donc présents). Il me semble que maintenant tout le monde fait de l'EABI-hf, ce problème est donc largement réglé (sauf pour les gens qui font de l'embarqué avec des CPUs qui n'ont pas de FPU, mais ce n'est pas la question ici). Ce serait donc comme se plaindre qu'il y a des problèmes sur x86 quand on veut écrire du code qui tourne aussi bien sur un 486 que sur le dernier Core i7.
Ensuite sur la détection du matériel: ARM est effectivement uniquement une architecture CPU (comme x86), pas une architecture de machine (comme le "compatible PC"). Donc, c'est fourni sans BIOS ou UEFI, et surtout sans bus permettant d'énumérer les périphériques et de découvrir le matériel présent (sur un PC ce rôle est rempli en partie par le BIOS, et en partie par le bus PCI).
Enfin sur les versions de l'architecture matérielle: oui, il y en a plusieurs. Mais ça n'a dérangé personne de voir apparaître de nouvelles instructions (MMX, SSE, SSE2, …) sur les processeurs x86. Ni de voir AMD développer son propre jeu d'instruction concurrent (3DNow!) ou décider de faire une version 64 bits (que Intel a ensuite cloné). Pourquoi chez ARM soudainement ça serait un problème? Il est normal qu'une architecture de CPU évolue à chaque génération.
Cependant, les choses avancent. Du côté de ARM, tout un tas de choses qui ne sont pas purement du CPU sont standardisées petit à petit: la MMU, un timer qui déclenche une interruption à intervalles réguliers, etc. Du côté de Linux, les applications et tout l'userspace fonctionnent sur toutes les machines (c'est la moindre des choses qu'on attend d'un OS: fournir une couche d'abstraction du matériel). Le noyau devrait pouvoir le faire aussi, normalement. Pour cela on a besoin d'un "device tree" qui décrit le matériel (à quelle adresse sont les différents périphériques, la mémoire, etc) et dans le cas de Linux, de drivers intégrés dans le noyau mainline. C'est surtout de ce côté que ça coince: il ne semble pas raisonable pour la plupart des constructeurs de devoir absolument stocker leurs drivers dans le dépôt Git de Linus et de devoir passer toutes les étapes de revue de code (les défenseurs de cette stratégie diront que c'est pour leur bien, que ça augmente la qualité du code et qu'en échange ils assureront la maintenance). Pour l'instant le support des différents systèmes ARM repose donc largement sur la communauté, mais c'est comme ça que Linux a pu se faire une place sur le marché du PC aussi, au moins au début.
Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.
[^] # Re: Effet de mode?
Posté par freem . Évalué à 2. Dernière modification le 04 avril 2018 à 13:51.
Me semble pourtant bien que Linux est compatible Android, vu qu'Android se base sur Linux?
Du coup, je me dis que je dois pas comprendre ce que tu veux dire.
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Ce que je dis au-dessus à propos de l'intégration des drivers dans l'upstream Linux.
Faire marcher une distribution Linux "classique" sans modifications sur n'importe quelle machine à base de ARM est difficile parce que Linux fait le choix d'embarquer tous les drivers dans un seul dépôt git et de tout packager ensemble. Du coup, tous les fabricants de SoC qui ne sont pas d'accord avec cette approche font un fork (et le maintiennent très rarement). Résultat, on a plein de forks pas maintenus et on avance pas.
Le problème n'est pas forcément technique, mais dans la façon de s'organiser et de collaborer. Et donc oui, le fork qui a choisi une organisation différente et qui marche (un peu) mieux, il s'appelle Android.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je dirais plutôt "tout les fabricants de SoC qui ne comprenne rien au standard de qualité de Linux". TI le comprenait à peine en 2009. Il maintenait de vieille version jusqu'à faire des backport de fonctionnalités qui intéressait les clients dans les nouveaux kernels !
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Renault (site web personnel) . Évalué à 7.
Pour avoir été client chez TI, Marvell, nVidia et Broadcom, je pense qu'ils en étaient conscients mais que c'était trop cher à leurs yeux de faire bien.
Car bon, quand tu vois qu'ils préfèrent parfois réinventer les sous-systèmes du noyau plutôt que de réutiliser l'existant, tu vois qu'il y a un soucis. Cela n'a rien à voir avec le respect de la procédure de développement du noyau.
Après le noyau pourrait sans doute faire un petit effort pour simplifier leur travail aussi. Le noyau LTS prévisible en est un, essayer de ne pas casser les APIs internes trop souvent en est un autre qui serait nécessaire.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Trop cher à court terme, mais à long terme, c'est catastrophique, le cout de la maintenance explose.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Renault (site web personnel) . Évalué à 5.
Certes mais comme la puce vendue a une maintenance courte durée globalement, cela ne semble pas être un soucis d'agir ainsi.
Je suis convaincu qu'ils gagneraient à pousser cela upstream. Mais il y a une première marche importante à franchir d'abord. Qui est surtout culturelle.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
il y a aussi une mentalité de faire table rase à chaque version.
J'ai vu passer l'Omap 2, 3 et 4. Il sortent chaque année. Le spécification qui donne une ligne par morceau de registre, donc explication minimum, fait 6000 pages.
De mémoire, omap2, c'est DSP+un gros arm, omap3, c'est DSP+arm multicore + cpu spécifique+ 30 modules, omap4 c'est 5 type de cpu différents + 120 modules.
Et à chaque fois, il faut réécrire les drivers, aucune compatibilité logiciel minimal n'est recherché. Comment capitaliser sur le dev soft avec cette façon de faire ? Même pour le test, c'est chiant, il faut réécrire les drivers avant !
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Parce qu'avant le SSE2 inclus dans l'AMD64, personne n'utilisait ces instructions à part 2 ou 3 soft, comme les moteurs de jeu, Photoshop et les codec vidéo. C'est un gâchis monstre. Il fallu attendre longtemps avec de pouvoir utiliser autre chose qu'un assembleur pour utiliser ses instructions, et encore plus longtemps pour que gcc fasse l'effort de les utiliser.
Cela marche pour le PC depuis plus de 10 ans…
euh?!
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par ted (site web personnel) . Évalué à 0.
Dans ce cas pourquoi n'as-t-on pas de carte mère avec un BIOS fait pour ARM, comme c'est le cas pour x86? Ça éviterait d'avoir à se coltiner des bootloaders proprios sur nos installations. Personne n'y voit d'intérêt?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Effet de mode?
Posté par Renault (site web personnel) . Évalué à 6.
Cela existe, cela s'appelle l'UEFI. Pour l'ARM64 bits cela s'impose de plus en plus. Et cela a l'avantage d'être beaucoup plus portable que le BIOS (qui reste cantonné à l'x86).
Et dire que certains considéraient l'UEFI comme une infamie…
[^] # Re: Effet de mode?
Posté par Arvil . Évalué à 2.
Je peux me tromper mais l'UEFI a principalement fait grincer des dents à cause du secure boot et de la complexité indûe qu'il a causé à son lancement notamment pour l'utilisateur lambda qui souhaite simplement installer sa distro, surtout à l'époque où le support UEFI sous Linux c'était pas ça (partiellement à dessein d'ailleurs).
Je n'ai pas entendu râler sur le principe même de L'UEFI…
[^] # Re: Effet de mode?
Posté par claudex . Évalué à 5.
Pourtant beaucoup l’ont fait. Notamment sur le fait que c’est un truc énorme qui a tous les accès aux différents composant et qu’on a besoin de très peu des fonctionnalités.
« 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: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
C'est rare de ne pas trouver u-boot sur une machine ARM, de nos jours? Alors en effet, il y a souvent un bootloader "stage 1" en dessous. Mais c'est juste un niveau de découpage en plus (ou plus visible) par rapport au x86.
[^] # Re: Effet de mode?
Posté par LaBienPensanceMaTuer . Évalué à 1.
Sinon, le DTB remplace avantageusement le BIOS sur ARM.
Désormais, depuis des noyaux récents, tu peux même charger/modifier le DTB au runtime …
[^] # Re: Effet de mode?
Posté par Renault (site web personnel) . Évalué à 4.
Avantageusement, non.
Écrire et maintenir des devices-tree c'est vraiment pénible à mon sens, comme il n'y a pas d'énumération de tout le matériel, si d'une version à une autre tu as des changements sur la carte, tu dois maintenir ces différences à la main.
Et comme le noyau tout comme U-boot n'ont aucun moyen de savoir exactement quel DTB utiliser pour une carte donnée, tu dois t'amuser à spécifier tes conditions à la main pour dire ce que tu veux charger. Joie…
Le DTB est une solution à un problème sur ARM, et heureusement que c'est là. Mais un équivalent du BIOS serait bien plus profitable je te l'assure.
[^] # Re: Effet de mode?
Posté par Prae . Évalué à 4.
On morcelle par distribution Linux: A ce niveau, on ne sait plus ce qui est bon: la multitude de choix ou d'avoir un seul et même choix.
[^] # Re: Effet de mode?
Posté par redo_fr . Évalué à 5. Dernière modification le 04 avril 2018 à 13:55.
La différence c'est que les distributions ne cherchent pas à tout prix à t'enfermer sur leur système en ne te proposant que des parties "autorisées" du réseau ou des fonctionnalités, les applications mobiles dédiées si : Si tu utilises une distribution redHat, elle ne t'empêche pas de te connecter sur le site d'Ubuntu, par contre, si tu utilises l'application dédiée "La Dépêche", pas sûr que tu puisses lire les articles de "Sud-Ouest", simplement parce que les deux sites n'utilisent pas les mêmes protocoles de communication :-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Effet de mode?
Posté par YBoy360 (site web personnel) . Évalué à -4.
Le problème pour Intel, c'est que son jeu d'instruction implique une architecture 30 % plus consommatrice (au mieux) qu'une architecture RISC, et que, parmi toutes les architectures RISC, ARM est la meilleure.
Même si il y a plusieurs jeux d'instructions pour ARM, ça reste bien plus simple. Les autres RISC qui sont gavés de micro-optimisations rendent leurs architectures peu souple et plus complexe.
Le fait que Microsoft, ait décidé de se lancer dans l'aventure ARM prouve que l’écosystème : séparation des acteurs, et l'architecture sont mature et performant par rapport à Intel, qui ne fait que stagner depuis plusieurs années.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Je ne sais pas d'où tu sors cela, mais pour moi, c'est complètement faux.
Le code x86 a une qualité inégalée par rapport au code RISC : il est beaucoup plus compact. Et là, tu va me parler de ARM thumb, le code 16/32 bits, manque de bol, x86 est encore plus compact que ça. L'avantage énorme est la moindre consommation de cache de code, c'est en parti cela qui a tuer le VLIW itanium qui avait un code très volumineux et donc des caches énormes, trés consommateur.
Le seul avantage du RISC par rapport au x86, c'est la simplicité du décodage, et donc un décodeur plus petit et plus rapide. Mais plus la puce est puissante (multiscalare, …) plus cet avantage diminue.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Renault (site web personnel) . Évalué à 2.
Puis bon, cela fait quelques générations d'Intel que le cœur du processeur est RISC et qu'il y a un étage de traduction entre le code CISC et RISC.
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Sérieux ? Cela fait 10 ans que l'on le répète : dans RISC/CISC, le I veut dire "instruction". RISC/CISC qualifie le jeu d'instruction et pas du tout la micro-architecture du CPU.
La définition est flou, mais on peut retenir plusieurs propriétés communes dans les jeu d'instruction réduit : des commandes load/store, ce qui veut dire que les opérations sont depuis les registres, ainsi que les load&store mémoire. Cela a le gros intérêt de réduire la pipeline du cpu, car pour un CISC, l'ALU est suivi du bloc de gestion mémoire, dans un RISC, les 2 pipelines sont parallèles.
Le décodage est aussi simple, schématiquement, un code, et l'adresse de 3 registres, le tout sur 32 bits fixe. Une instruction CISC est souvent un multiple de 8 bits, il a même existé un cpu intel avec des tailles d'instructions au bit ! Il avait une énorme shifter très couteux.
Avantage : décodeurs simple (aligner sur 32 bits), pas d'instructions inutiles pour un compilateur
désavantage : plusieurs instructions pour une seul instruction cisc, code moins compact
"La première sécurité est la liberté"
# Pour les ordinateurs personnels, c'est pas ça…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
Pour un usage type serveur, ça ne m'étonne pas. On a beaucoup de charges serveur aujourd'hui qui ne sont pas limitées par la puissance CPU, mais par autre chose (I/O, typiquement). De plus, beaucoup d'usages CPU sont très massivement parallélisables et s’accommodent bien d'une configuration type « 2 x plus de cœurs, 2 x moins puissants unitairement, mais qui consomment 4 x moins ».
Pour les ordinateurs personnels, par contre, c'est toujours pas ça… la preuve les récents tests des PC Windows 10 sous ARM, comme le Asus NovaGo. Où l'on s’aperçoit que même avec des applications natives ARM les performances ne sont pas au niveau d'un ordinateur x86. J'imagine aussi que c'est une question de perception : des performances considérées comme acceptables sur une tablette ne le sont plus sur un ordinateur, surtout quand tu as en face un ordinateur de même format, de même prix mais sensiblement plus puissant.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
ARM devrait faire comme Intel pour AES : des instructions spécialisés. Et puis, 2 ou 3 versions de jeu d'instructions mais pas une pléthore de combinaison comme Intel : cela empêche d'avoir un intérêt pour les dev logiciel d'utiliser ces instructions, car ule jeu d'instruction intéressant est trop peu commun.
Il devrait compléter les instructions crypto, l'usage des copro étaient une mode : mais il n'y a jamais tous les modes disponibles, et la programmation du coproc peut prendre plus de temps que de faire le boulot sur le cpu pour les petits paquets. A moins d'avoir un truc énorme à faire comme la décompression vidéo. De plus, cela rend nécessaire l'écriture d'un drivers spécifique pour l'OS, alors qu'une instruction ne demande qu'un assembleur pour être généré.
"La première sécurité est la liberté"
[^] # Le retour de gentoo?
Posté par freem . Évalué à 2.
Peut-être que si ça finit avec une tétrachiée de CPU ARM incompatibles ou avec des jeux d'optimisations possibles différents (un peu comme le x86 à une époque, en fait) une distribution dont la spécialité est de tout recompiler pour que les briques logicielles soient faites sur-mesure pour utiliser à fond le hard et délestées des composants inutiles (je pense notamment au fait que mes machines perso n'ont aucun usage pour le protocole SMB et pourtant il me suffit de quelques paquets à installer pour l'ajouter. C'est bien, mais ces instructions de vérification runtime doivent bien être exécutées, consommant quelques cycles et pourrissant quelques caches?) pourrait tirer son épingle du jeu?
Du coup, les distros de type gentoo qui recompilent tout depuis les sources (enfin, il est possible d'installer des binaires aussi je crois?) et en permettant d'élaguer les fonctionnalités inutilisées par un système donné seraient peut-être les plus à même de rendre ce type de systèmes exploitables?
Bon, du coup, ça exclue toute distribution (linux ou autre kernel) non spécialisée pour à la fois l'usage et le hard, et je doute que les gars de chez MS s'amusent à compiler une galaxie de versions?
Bon, d'un autre côté, si les OS binaires ne sont pas un minimum performants, il est peu probable que ça atteigne les foules, et donc que ça se répande dans le public.
[^] # Re: Le retour de gentoo?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si ARM n'est pas trop débile, il faut une jeu de CPU "server", un jeu de complément "desktop" ou "calcul", et qu'il ne s'amuse avec 36 combinaisons qui ne serait jamais alors utilisé. Un peu comme à l'époque de l'ARM9 qui n'avait pas de FPU, chacun avait son truc, et aucun code linux n'utilisait la fpu non standard présente. Ils ont refait la même blague avec leurs instruction SIMD.
"La première sécurité est la liberté"
[^] # Re: Le retour de gentoo?
Posté par Le Gab . Évalué à 4. Dernière modification le 04 avril 2018 à 13:44.
Le mythe du Genteux et Archeux pensant qu'une recompilation avec 3 flags == optimisation.
Le curseur de ta souris qui va plus vite, c'est un effet placebo.
Ce n'est pas parce que GCC support ARM, x86-n, RISC que l'application qui a été d'abords codée pour x86 se retrouve automagiquement optimisée pour ARMv99.
L'optimisation c'est un peu plus que -O4 -march=skylake. Si le code bas-niveau ne tire pas partie de l'architecture et du jeu d'instruction, ça relève juste du portage et ça Debian, Fedora le font.
[^] # Re: Le retour de gentoo?
Posté par freem . Évalué à 6.
Naturellement, puisqu'il faudrait déjà qu'elle soit écrite de manière portable, ce qui est loin d'être trivial à faire (pour une taille, on prend quoi? Un size_t dépendant du compilo qui lui-même dépendra du compilo, ou un uint64_t qui permettra d'avoir toujours le même résultat? On peut aussi considérer qu'on n'aura jamais plus de 0xFFFF éléments, et dans ce cas un uint16_t serait peut-être plus approprié?).
Ce que je voulais dire, c'est que recompiler pour une archi permets d'utiliser les spécificités de cette archi et les optimisations liées, plutôt qu'utiliser un tronc commun qui se basera probablement sur un dénominateur commun.
Et puis, il reste le fait de désactiver les dépendances dont on sait qu'elles ne seront jamais utilisées. Honnêtement, je ne pense pas que sur les machines x86 actuelle ou le CPU glande la plupart du temps ce soit pertinent, mais si les machines à base d'ARM sont sensiblement plus lentes, ça pourrait être pertinent de faire le propre dans les dépendances au lieu de viser le système universel, je suppose?
Parce qu'arch est basé sur l'idée de recompiler la plupart des composants? Je n'en ai pas eu l'impression au cours de mes lectures.
[^] # Re: Le retour de gentoo?
Posté par Le Gab . Évalué à -6.
Ben oui, c'est quand basé sur le partage de repos entre utilisateurs de la distribution, il faut bien les compiler ces applications, non?
Yahourt a été créé pour rendre la tâche plus facile.
Tu peux bien sûr vivre une vie d'Archiste sans jamais compiler mais du coup, Quid de la différence avec Debian/Ubuntu, Fedora/Centos?
[^] # Re: Le retour de gentoo?
Posté par patrick_g (site web personnel) . Évalué à 9.
Avoir des applis toujours à jour ?
[^] # Re: Le retour de gentoo?
Posté par totof2000 . Évalué à -3.
Avoir un système cassé à chaque mise à jour ?
[^] # Re: Le retour de gentoo?
Posté par Faya . Évalué à 8.
N'importe quoi… Le système sur lequel j'écris ce message actuellement a été installé fin 2012. Depuis j'ai juste fait les màj normales et régulières (pacman -Syu) avec de temps en temps (genre une fois par an mais je suis même pas sûr que ça soit si souvent…) une manip à faire pour poursuivre l'update , décrite en détails à l'accueil de https://archlinux.org . Et quelques yaourt pour rajouter des trucs plus exotiques (Telegram, Signal, Onlyoffice, …)
Là si je consulte cette page, les derniers updates nécessitant une intervention manuelle datent d'octobre 2016 puis mars 2017. La marche à suivre est indiquée noir sur blanc et simplissime.
J'ai passé 2 ans sous Gentoo à compiler mes ptits paquets mais pas besoin de ça sous Arch, ça juste marche.
[^] # Re: Le retour de gentoo?
Posté par totof2000 . Évalué à -1.
Je n'ai malhereusement pas eu la même expérience sur ce sujet. j'ai eu de gros problèmes quasiment à chaque mise à jour lorsque j'utilisais Arch.
[^] # Re: Le retour de gentoo?
Posté par Nibel . Évalué à 0.
Le problème c'est l'interface chaise-clavier alors.
Mon serveur à la maison a une Arch vieille de 7 ans installée dessus : jamais cassée.
Mes deux laptops : l'un 4 ans, l'autre 2 ans jamais cassés non plus.
Et le RPi2 en ArchARM depuid sa sortie jamais cassé non plus.
Les MAJ critiques, il suffit d'aller lire les news et c'est expliqué en quelques lignes.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le retour de gentoo?
Posté par Le Gab . Évalué à 2.
Houla, jeune fougueux, avant de tirer de telles conclusions à la hâte, peut-être faudrait-il considérer qu'il ait une configuraiton un peu plus complexe que toi. Un archiste, c'est tout de même le minimalisme avant tout, non? Ce n'est pas une critique cependant.
Mais encore une fois, le minimalisme, tu peux le faire avec une Debian ou une Fedora également.
As-tu un tatoo ArchLinux en ascii art quelque part sur ton anatomie? :P
[^] # Re: Le retour de gentoo?
Posté par Faya . Évalué à 3. Dernière modification le 05 avril 2018 à 17:36.
Pas si tu veux être à jour (Debian). Et j'ai bien tenté Fedora mais ça n'a pas été concluant. Comment j'en suis venu à choisir (et rester) sur Arch :
Tu connais pas la blague ? "Comment faire pour savoir si un internaute utilise Archlinux ? Y'a rien à faire, il vous le dira de toutes les façons".
Je suis conscient que c'est de l'ironie pour moquer les users d'Arch mais cette blague porte une part de vérité : les users de Arch en sont généralement très satisfaits et veulent le faire savoir au monde entier ;-)
[^] # Re: Le retour de gentoo?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Ici un ancien utilisateur de Arch pas satisfait, et qui ne voit pas l'intérêt de le faire savoir au monde entier →
(juste pour rappeler que ça existe aussi).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Le retour de gentoo?
Posté par nokomprendo (site web personnel) . Évalué à 1.
Pareil. Je l'ai utilisé quelques années avant de changer car je n'en étais pas complètement satisfait. Et j'ai deux collègues dans le même cas. Si ça intéresse tant que ça le monde entier, n'hésitez pas à le lui dire également.
[^] # Re: Le retour de gentoo?
Posté par freem . Évalué à 4.
Développes.
Tu parles d'être à jour sur quel niveau? Sécurité, fiabilité ou bling-bling?
Heureusement que tous les gens satisfaits de leur système ne font pas pareil, ça serait le bordel autrement.
[^] # Re: Le retour de gentoo?
Posté par Nibel . Évalué à 3.
Différente, sans aucun doute. Complexe, ça reste encore à juger. Mais sur du matériel x86 "standard" avec des technos "standards", y a vraiment aucune raison que ça casse si on sait lire. Ou alors un coup de padbol… Mais j'ai installé et maintenu, et maintiens toujours, une bonne trentaine d'Arch (j'ai converti la quasi-totalité de mon entourage technophobe dessus avec des utilitaires et interfaces user-friendly qui vont bien, comme quoi, il ne suffit pas d'être un barbu pour s'en sortir sous Arch) sans jamais avoir rencontré de problème venant ailleurs que de l'interface chaise-clavier, que je me permets de douter fortement quand on me dit "Arch ça casse pour rien". Mais peut-être que c'est le cas ici, pourquoi pas après tout, je n'ai pas rencontré tous les cas possibles.
C'est vrai que les Archeux, moi y compris, sont passionnés par leur distribution pour une raison que j'ignore. Je peux concevoir que l'on n'aime pas, les goûts et les couleurs comme on dit… Mais je vais réfléchir au tatoo Arch en ascii ;).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le retour de gentoo?
Posté par Le Gab . Évalué à 3.
Raaah ces 20-25 ans, quelle énergie. :)
Donc, récapitulons, tu as installé et tu maintiens une trentaine d'installations Rolling Release pour personnes technophobes, et tu en conclues que "ben elle est faite pour les lamdbas".
Rien que l'énoncé prête à sourire.
Tu t'es manifestement formé avec cette distribution, tes réflèxes de resolutions sont quasi instinctifs. Ça n'invalide pas les qualités d'Arch mais ça ne les confirme pas non plus.
Non, je ne vais pas marcher dedans.
openbox, dmenu, thun…. non j'ai dit que je ne marcherais pas dedans.
[^] # Re: Le retour de gentoo?
Posté par Nibel . Évalué à 1.
La maintenance que j'effectue pour ces gens aujourd'hui se limite à les aiguiller si une MAJ ne passe pas (généralement d'un paquet issu d'AUR).
Et pourtant non, ma première expérience sous Linux c'était Ubuntu Feisty Fawn. Et j'ai passé mes premières années linuxiennes sous Ubuntu en suivant le rythme de sortie des versions pendant plus ou moins 2 ans. J'ai ensuité migré sous Debian pendant plus ou moins 1 année, en essayant au passage assez furtivement Fedora, Mageia et OpenSUSE. Et ensuite je suis passé sous Arch, que je n'ai plus quitté.
Et si aujourd'hui j'ai acquis une certaine expérience avec cette distribution, c'est aussi en grande partie grâce à la doc' d'ArchLinux qui est la plus fournie et la plus à jour que j'ai rencontré. J'ai pu résoudre la quasi-totalité de mes problèmes de débutant avec.
Non ça c'est plus proche de ma config'… Qui n'a rien d'user-friendly. XFCE pour les machines les moins solides, Gnome ou Plasma selon les goûts pour les machines les plus costauds. Et des outils de MAJ en mode graphique. Bref, si quelqu'un a touché le vendredi du bout du doigt, ce n'est certainement pas moi pour le coup ;).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le retour de gentoo?
Posté par totof2000 . Évalué à 0.
Comme quoi ça ne se passe pas toujours bien … Pour ma part, je n'ai pas eu de problèmes avec Arch pendant quelques mois, puis il y a eu une phase ou ça se vautrait quasiment à chaque mise à jour. J'ai même connu des fois ou l'installation d'un nouveau soft nécessitait de mettre à jour des dépendances communes à d'autre softs installés et cassait l'existant. Ya des fois ou tenter une mise à jour le lendemain réglait les problèmes, mais d'autres fois ou ça ne suffisait pas (par exemple je me souviens vaguement d'un problème de mise à jour du à des clés qui avaient changé - j'ai d'ailleurs du faire un post dans un forum ici, ou ralé dans un journal). Difficile de lire sur les forums ou sur le net quand ta machine ne lance pas ton environnement graphique … Du coup j'ai laissé tomber.
[^] # Re: Le retour de gentoo?
Posté par Nibel . Évalué à 3.
Les paquets AUR ne sont pas des paquets maintenus officiellement par les mainteneurs d'Arch. Si ça ne se passe pas bien, c'est de la faute du mainteneur du-dit paquet, pas de Arch. Et c'est écrit en rouge clignotant qu'installer un paquet AUR peut être dangereux, il est toujours nécessaire de jeter un coup d'oeil au PKGBUILD avant. Oui, Arch demande un peu d'entretient et d'investissement, ça je n'ai jamais dit le contraire.
Concernant les clés, elles changent à peu près tous les ans et la solution à ce faux problème est dans le wiki d'Arch. Inutile de râler, juste d'aller chercher la réponse a la source… Mais quand tu l'as fait une fois, tu sais à quoi d'attendre pour la prochaine…
Cela dit, je pense que la majorité des gens ont au moins une deuxième machine pour accéder à Internet : smartphone, un autre ordinateur… Si ce n'est pas le cas, il existe toujours des navigateurs web en mode console qui fonctionne très bien et qui dépannent dans ce genre de situation.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le retour de gentoo?
Posté par totof2000 . Évalué à 2.
Dans l'absolu, on s'en fiche un peu: au final ça ne marche pas, et toujours quand tu en as absolument besoin.
Faux problème ? Pour l'utilisateur c'est loin d'être un faux problème. Ca marche plus à un instant T c'est tout.
Quand ça m'est arrivé, c'était sur mon portable, et je n'avais pas d'autre machine à portée de main. J'ai donc préféré laisser tomber.
[^] # Re: Le retour de gentoo?
Posté par Nibel . Évalué à 3.
Dans l'absolu tu es le seul responsable. Si tu décidés d'installer un paquet non maintenu, c'est ton problème. Quand ça casse sous Debian Sid, personne ne va pleurer, parce que tu es au courant que c'est instable. Et ça casse bien plus souvent que sous Arch pour le coup…
Quand tu installes Arch, tu fais le keyring. C'est une étape que tu es censée avoir apprise et ça fait partie de la maintenance nécessaire de la distro. On peut ne pas aimer mais dire qu'on savait pas, c'est un peu gros… Ou alors tu as utilisé un script d'installation… Dans ce cas, il ne faut pas se plaindre de ne pas maitriser sa distro.
Et tu as sans doute bien fait. Vu ce que tu me racontes, il est évident qu'Arch n'est pas une distribution adaptée pour toi.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Le retour de gentoo?
Posté par ff9097 . Évalué à 2.
Les applis sont à jour sur Fedora.
[^] # Re: Le retour de gentoo?
Posté par Moonz . Évalué à 4.
Je crois qu’il voulait dire "rolling release".
[^] # Re: Le retour de gentoo?
Posté par xcomcmdr . Évalué à 6.
C'est par là :
https://wiki.archlinux.fr/Arch_vs_autres_distributions#Arch_et_Debian
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le retour de gentoo?
Posté par David Demelier (site web personnel) . Évalué à 2.
Gentoo est largement plus utilisé dans l'optimisation en terme de découpage. C'est à dire quelqu'un qui ne souhaite ni wifi, ni nls, ni bluetooth, ni avahi, ni dbus aura un système ultra léger. Les performances en revanche sont largement moins perceptibles. De toute façon toutes les applications ne sont pas forcément développées en C, C++.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par oinkoink_daotter . Évalué à 3.
SnapDragon 835.
L'A11 le défonce (il y a un rapport de pas loin de 1 à 2 dans les benchs - certes, ça reste des benchs -).
Aujourd'hui, dans l'écosystème Apple, l'A11 serait grosso modo au niveau de perf ressentie du macbook.
Je pense qu'ils vont d'abord commencer par ce type de use case pour 2020, pour mettre en place tout l'écosystème AppStore (qui serait rendu obligatoire pour l'occasion), qui lui, nécessitera une compilation pour les deux environnements X86 et ARM, pour (autant que possible) éviter l'équivalent Rosetta.
…
…
…
Ou alors, ils n'ont pas réellement envie de le faire et ils font opportunément fuiter ça pour qu'intel baisse ses marges.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Zenitram (site web personnel) . Évalué à 7. Dernière modification le 04 avril 2018 à 12:44.
Apple a déjà fait 1 passage incompatible (obligé de recompiler) d'archi à une autre (PPC à x86), je ne vois aucune raison qu'ils ne refassent pas surtout qu'ils sont depuis encore plus en position de force (macOS a plus de parts de marché desktop qu'à l'époque du premier passage, et l'App Store est en place avec des règles si tu veux être accepté).
Les environnements deviennent hétérogènes, les développeurs doivent de toutes façons de plus en plus gérer des plate-formes différentes, les outils pour passer à une autre plate forme sont moins rares (même Microsoft s'y met), ça devient de moins en moins difficile de demander aux développeurs un changement de plateforme, et Intel risque de prendre vraiment mal à s'être reposé sur ses lauriers et profité du monopole de facto de x86 dans la dernière décennie (chaque "génération" de CPU des dernières années n'étant qu'une mini-évolution avec peu de gain) pendant qu'ARM se pointait en passant pas une "petite" porte (la mobilité, mais qui a fait qu'il s'est focalisé plus tôt sur la perf par watt dont on a besoin maintenant aussi sur le desktop maintenant que les développeurs se sont enfin mis au multi-threading et que donc il faut pour les fondeurs entasser le plus de cores possibles dans un CPU sans demander au client d'investir dans une centrale nucléaire).
Je prédis un réveil difficile pour Intel dans les années 2020 (pas par AMD dont je ne suis pas encore complètement convaincu par la nouvelle archi qui fait certes souvent mieux mais pas partout et donc faut voir leur "v2", mais par ARM et ses copies) si ils ne se donnent pas un gros coup de pied dans le derrière niveau R&D.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par ZeroHeure (site web personnel) . Évalué à 10.
Les environnements re-deviennent hétérogènes. Après avoir tout avalé, d'abord sur la micro perso des années 80, puis sur les serveurs (l'Alpha de Digital Equipment, le Sparc de Sun, le PowerPC de Motorola, le MIPS de Silicon Graphic, …), le x86 d'intel retrouve la concurrence.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Prosper . Évalué à 7.
Ils ont aussi fait 68k>PPC , System 7 et 8 existaient dans les 2 versions.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par oinkoink_daotter . Évalué à 3.
Fat binaries <3
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par freem . Évalué à 6.
Pire que les binaires electron?
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Guillaume Knispel . Évalué à 6.
Deux en fait ; avant ils ont fait 68k -> ppc
Concernant l'hétérogénéité c'est d'autant plus vrai que pour la majorité des programmes, le jeu d'instruction du processeur cible est un problème extrêmement trivial (jusqu'au point où le plus souvent on s'en bas complètement les couilles) par rapport aux différences soft des plateformes qui ont des vrais impacts.
Au final les seuls un peu impactés seraient les utilisateurs pendant une période de transition. Mais Apple a la stratégie (et les fanboys qui suivent et rachètent tout tout le temps) de ne pas laisser les transitions durer trop longtemps, et de faire disparaître "rapidement" la compat avec les technos obsolètes.
Le problème c'est qu'Intel a déjà voulu donner en quelque sorte un coup de pied dans le derrière de leur R&D, plusieurs même, mais aux derniers coups de pieds ils ont fort mal visé ou dosé la puissance AMA. De plus leur stratégie all-in x86 (et même là ou PERSONNE n'en a rien a battre) est tellement naze… d'ailleurs elle a lamentablement échouée dans le domaine des mobiles.
Quant à AMD, c'est vrai qu'ils n'ont que commencé a rattraper leur retard et leur propres erreurs stratégico-techniques passées (et oui, le temps d'incub d'un proco est long), mais honnêtement leur capacité à sortir quelques astuces et à obtenir un résultat qui a étonné tout le monde est classe. Ça va être dur de le refaire sur de la simple evol, mais bon on sait jamais, et en tous cas vu que tout le monde galère à obtenir de vraies accélérations ils vont rester dans la course un bout de temps.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Anonyme . Évalué à 2.
C'est ce que Apple veut faire croire mais quand on ne peut pas installer le même système sur deux machines différentes, aucune comparaison sérieuse n'est réellement possible. On ne peut pas changer plusieurs paramètres à la fois et espérer un résultat exploitable, c'est un manque de rigueur scientifique. Il n'est pas possible de croire aux résultats de Geekbench tant que Apple ne permet pas d'installer AOSP sur ses appareils ou que iOS soit disponible pour un appareil concurrent utilisant un SoC Qualcomm.
C'est plutôt mon avis : un coup de bluff pour négocier un meilleur accord commercial avec Intel. C'est d'ailleurs peut-être pour ce marché-là que Intel a sorti un APU contenant un GPU AMD il y a quelques semaines.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par oinkoink_daotter . Évalué à 3.
Quel marché ? Le truc ciblé par un possible Mac ARM ? Non ce sont deux produits différents pour des usages différents. Les APU sont des CPU avec un TDP à 35/45W+ xxW circuit graphique, donc ça ciblerait pour moi uniquement les machines avec CPU discrets : les "gros" 15 pouces à 2800€+ et certains iMac (l'iMacPro et MacPro, c'est un autre problème), car les perfs des Iris intel actuels sont déjà correctes, même sur les écrans retina (ce qui n'était pas le cas de la génération précédente) pour les 13 pouces et "petit" iMac. Passer à ces APU permettrait à Apple de régler des problèmes d'ingénierie sur ses cartes mères, mais ça ne règlerait pas le problème du CPU anémique du Macbook fanless de Jony "I want it thinner" Ive, ni vendrait du rêve aux utilisateurs (truc vraiment plus rapide, autonomie vraiment plus longue, machine vraiment plus légère). Un truc un peu convergent iOS/macOS, par contre …
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Guillaume Knispel . Évalué à 1.
Bof c'est impossible de comparer ça maintenant. Le truc vient de sortir alors que l'autre c'est une théorie potentiellement en développement pour 2020. Du coup tes hypothèses sur la théorie en question sont AMA complètement à côté de la plaque ; Apple sait déjà faire un CPU pour téléphone avec des perfs impressionnantes comparé avec certains CPU Intel pour… plus gros. S'ils ont un projet explicitement pour MBP (voire plus), il n'y a pas trop de raison qu'ils n'arrivent pas a concurrencer très largement Intel.
Quand à la convergence iOS/macOS, elle n'a pas strictement besoin d'une ISA commune pour se produire (même si ça peu un peu aider, voire servir de prétexte).
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Guillaume Knispel . Évalué à 2.
Nan, dans beaucoup de workloads l'OS importe peu. Et puis c'est pas comme ci Apple aller passer à Android ou Windows. Si vraiment ils arrivent a être en avance grâce à leur soft, ben tant mieux pour eux. (Et c'est le même noyau sous OS X et iOS.)
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Anonyme . Évalué à 4. Dernière modification le 05 avril 2018 à 11:04.
Euh on sait pas comment les benchmarks sont reçus sur ce système totalement fermé. On a déjà vu des tests en faveur de tel ou tel fabricant qui étaient soi truqués par le soft, soi truqués par l'OS qui voit que c'est tel benchmark et qui le met en priorité ultra haute. On a pu aussi voir des puces conçues pour passer certains benchs mais être à la traine sur d'autres.
Il y a soupçon de manipulation marketing parce que les mesures ne sont pas cohérentes avec la consommation et le dégagement thermique comparé à tous les SoC sur Android. Apple a certes une licence architecture qui permet d'avoir des gains sur ceux qui utilisent les plans de ARM Holdings mais il ne peut pas s'affranchir de la physique des semi-conducteurs, surtout quand son fondeur utilise le même procédé de fabrication pour ses autres clients sur archi ARM64.
Tant qu'il n'est pas possible de faire des mesures dans le même environnement logiciel que la concurrence, d'utiliser les mêmes binaires, ces chiffres sont invalidables.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Guillaume Knispel . Évalué à 2.
D'un autre côté, si iOS triche lors des bench en débridant des limites habituellement utilisées pour limiter la conso, ça donne une encore meilleure idée à ce qu'il sera possible de faire sur laptop.
Pour être franc je pense même pas qu'il y ait un tel comportement, et de toutes manières le ressenti des utilisateurs correspond globalement aux bench "synthétiques". Enfin les bench synthétiques sont consistant entre les différentes générations de proco Apple et d'avant. En plus c'est relativement facile de "débrider" les téléphones Android pour faire des bench et personne n'a réussi a les faire remonter au niveau de l'iPhone X avec cette technique… et encore une fois ça voudrait pas dire grand chose pour l'affaire qui nous intéresse, ça voudrait juste dire que en plus yaura ptet des laptops Windows ARM qui rament pas trop, du moins en code natif.
Après certes s'ils consomment déjà "trop" durant les bench, c'est plus dur pour Apple de progresser encore plus. Mais Intel est aussi soumis à la physique des semi-conducteurs, donc encore une fois rien d'impossible. Surtout que le plus important sera la microarch : pour le procédé, je pars du principe que l'écart avec Intel sur ce point, si toutefois il en reste un, est devenu plus que gérable et va continuer à le devenir encore plus ; concernant les facilités ou non de l'ISA j'aurais tendance à dire que l'ARM part avec un avantage théorique. Je continue à croire qu'absolument rien n’empêche, en faisant l'hypothèse d'une équipe compétente, qu'Apple conçoive un CPU concurrentiel pour MBP. Pour un MP évidemment c'est plus dur, mais si leur principe de base est scalable, pourquoi pas.
Enfin certaines pistes d'accélération sont évidentes en passant de ce CPU de téléphone portable à un pour laptop: par exemple augmenter la BP ram. Rien qu'avec des ajustements évidents et à "faible" coût de R&D ils peuvent "immédiatement" augmenter les perfs du CPU pour une nouvelle cible.
Bref du point de vue de la technique pure, je ne vois rien qui bloque. AMA ça sera pas ces aspects là de techniques pures qui seront décisifs, de toutes façons, et il est plus que probable que rien de soit tranché aujourd'hui.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Anonyme . Évalué à 0.
Si une commande nice est passée pour le benchmark qui réduit la priorité de fonctions usuelles de l'appareil (la pile réseau ou Siri par exemple) ce n'est pas une histoire de gain de consommation mais de conditions non réalistes par rapport à la charge CPU en conditions d'utilisation normale.
Plus mesquin encore : si l'OS triche sur l'horloge le benchmark courra au ralenti (comme dans la série Flash Gordon des années 50) et sous-évaluera la durée du test.
C'est un faux argument à la fois à cause des biais cognitifs (la fluidité donne une impression de vitesse et de confort) et du fait que certaines tâches ne sont pas mesurables précisément par un humain. Il y a aussi le biais d'auto-persuasion qu'a un consommateur vis à vis de ses achats.
Encore une fois, quand on pourra installer le même protocole de test sur tous les appareils on pourra établir une comparaison potable. Tout ce qui est comparable sont les tels Android.
Tu retournes l'argument : c'est Apple qui présente des résultats complètement fumés par rapport à toute l'industrie. Pas Intel, Qualcomm, Samsung ou Nvidia qui eux ont pour point commun de pouvoir fonctionner avec les mêmes OS et les mêmes benchmarks sans restriction d'un quelconque Store. Apple est en vase clos et ne vend même pas de cartes de développement pour ses SoC.
Les SoC ARM montent en performance mais indéniablement la consommation et le TDP augmentent dès que les fabricants veulent battre Intel sur autre chose que ses Atom "Celeron" N ou J et les Core-M.
Je ne doute pas non plus que Apple passera sur ARM dans quelques années mais leurs résultats Geekbench sont inexploitables.
# la guerre du perf/watt ... et du perf/€
Posté par trancheX . Évalué à 5. Dernière modification le 04 avril 2018 à 11:23.
Pour en remettre une couche sur les bookmarks : Cloudflare avait fait des bechmarks (pour leur cas d'utilisation) relativement détaillé entre intel vs qualcomm et ce qui en ressort c'est que à part quelque soft pas encore très optimisé pour ARM64 les puces serveur de Qualcomm sont très compétitive … en tous cas pour ce que CloudFlare utilise.
Le rapport perf/Watt est à l'avantage de ARM manifestement.
De plus il me semble que les puces ARM sont nettement moins chère que les x86 intel, le rapport perf/$ à l'achat et sans doute aussi à l'avantage de ARM.
Le patron de cloudflare avait déclaré que même avec des puces intel gratuites il leur serait toujours plus intéressant de passer à ARM :
Mais il n'y a pas que ARM, je ne sais pas si MIPS ne pourrait pas venir le concurrencer sur les serveurs avec des puces gérant le SMT, ce que à ma connaissance ne fait pas ARM.
[^] # Re: la guerre du perf/watt ... et du perf/€
Posté par Firwen (site web personnel) . Évalué à 5.
Le ARMv8.2 ThunderX2 est SMT avec 4 hardware threads par coeur.
[^] # Re: la guerre du perf/watt ... et du perf/€
Posté par trancheX . Évalué à 2.
Ha, j'avais pas vu ça : j'aurai du chercher avant de dire des âneries. C'est juste moi qui n’ai encore jamais vu de puces ARM smt dans les projets de ma boite (de MIPS non plus), mais en fait ça existe. Bon à savoir.
Ça a rien de bon pour MIPS qui n'a aucune chance de revenir dans la course du coup.
[^] # Re: la guerre du perf/watt ... et du perf/€
Posté par Anonyme . Évalué à 3.
Phoronix commence à sortir quelques comparatifs Power9 avec le Thalos II. Mais malheureusement pas de mesure de consommation.
# évolution nécessaire
Posté par Maclag . Évalué à 7.
Oui, Intel traverse une mauvaise passe, c'est difficile de rester #1 si longtemps tout en prenant les grands virages technologiques.
Mais Apple est passé près du gouffre, MS a eu sa mauvaise passe, et ces boites sont encore là. C'est juste très difficile de faire changer de cap à un super cargo.
La solution viendra peut-être d'une nouvelle archi interne, d'une gamme ARM ou d'une simple acquisition de boite qui a ces cartes en main.
Je ne les enterrerais pas si vite.
Par contre, Intel a la réputation d'être une boite assez bureaucratique et de forcer dans le moule les boîtes qu'elle absorbe. Là elle a pourtant besoin de s'ouvrir. Le plus difficile à changer dans une boite, ce n'est pas la gamme de produits, c'est la culture!
Bonne chance à eux. Ce serait triste de voir un acteur aussi important de l'histoire des semiconducteurs devenir une boite de second rang.
[^] # Re: évolution nécessaire
Posté par Le Gab . Évalué à 8. Dernière modification le 04 avril 2018 à 21:08.
Ça ne leur fera pas de mal de redescendre un peu sur terre. Ils se sont bien foutu de notre gueule durant la première décennie du millenaire, enfin, ça ne s'est jamais vraiment arrêté. :P
Ce sont les rois des CPU "valables" à 500/800 euro avec changement de chipset - et donc de carte mère - successif.
AMD n'a jamais pu résoudre son problème de consommation et ainsi a perdu la guerre du mobile, cela dit sur du fixe tu pouvais changer de génération de CPU sans jeter la carte mère.
Et puis, AMD c'est tout de même: 3DNow, premier controlleur mémoire intégré, premier 64bit et premier multi-coeur avant Intel.
Intel, c'est le Microsoft du CPU, il ne faut pas l'oublier.
[^] # Re: évolution nécessaire
Posté par Faya . Évalué à 2.
Bin tiens, j'ai lu la même phrase en suivant le lien du journal précédent sur "la fin de Windows" : https://stratechery.com/2018/the-end-of-windows/
[^] # Re: évolution nécessaire
Posté par Maclag . Évalué à 4.
C'est certainement parce que c'est vrai…
[^] # Re: évolution nécessaire
Posté par Faya . Évalué à 3.
Bin oui, je pense que c'est vrai… C'était sûrement mal exprimé mais j'abondais dans ton sens en fait
# Une stratégie floue ?
Posté par Physche . Évalué à 0.
Je ne comprend rien à la stratégie d'Apple. D'un côté ils veulent remplacer les processeurs Intel des processeurs par des ARM et de l'autre, ils veulent remplacer les processeurs ARM des processeurs par des Intel.
http://www.zdnet.fr/actualites/apple-qualcomm-remplace-par-intel-dans-les-iphone-39863696.htm
Quelqu'un peut-il m'expliquer ?
[^] # Re: Une stratégie floue ?
Posté par Anonyme . Évalué à 4.
L'article parle de la partie modem des iPhone. Apple conçoit la partie processeur depuis un moment et ça n'est pas prêt de changer.
[^] # Re: Une stratégie floue ?
Posté par Maclag . Évalué à 7.
Comme dit au-dessus, on parle ici du modem, pas du SoC.
Apple est en pleine bataille juridique avec Qualcomm, qu'elle accuse de pratiquer des tarifs exorbitants pour les précieuses licences sur leurs panel de brevets liés aux technos 3G/4G.
Apple a d'ailleurs
demandéexigé de 2 de ses gros fournisseurs qu'ils cessent de payer ces fameux royalties à Qualcomm. On suppose que ça vient avec des garanties sur le support juridique, parce que moi j'aimerais pas être une petite boite abandonnée devant QC…Qualcomm accuse en retour Apple de vouloir casser les prix à l'extrême en-dessous de toute raison.
Comme d'habitude, celui des deux qui a le plus raison est celui qui paiera les meilleurs avocats…
À l'appui de l'un, Qualcomm s'est aussi mangée des amendes salées un peu partout dans le monde pour abus de position dominante… à cause de ces royalties, justement.
À l'appui de l'autre, Apple est réputée pour réduire les marges de ses fournisseurs à 0 ou presque.
Dans ces conditions ou il n'y a plus de négociation mais une guerre d'avocats, difficile d'imaginer Apple tenter de négocier un rabais sur les modems Qualcomm…
Peut-être qu'ils avaient déjà pris la décision de remplacer les modems par du Intel, ou peut-être que c'est lié à la bataille juridique.
Sortez vos pop-corns!
[^] # Re: Une stratégie floue ?
Posté par oinkoink_daotter . Évalué à 3.
Il me semble que c'est un peu plus subtil que ça : les fournisseurs ne gardent pas l'argent, ils le versent sur un compte tiers bloqué au lieu de le verser à QC, ce qui est une manœuvre classique en cas de litige commercial.
# Xeon vous trouvez ça précis ?
Posté par marzoul . Évalué à 10.
Je rêve ou personne ne se pose la question clé : quel est exactement le CPU "Xeon" qui a été utilisé pour la mesure ? Il y en a des pléthores avec des perfs extrêmement variées, alors qu'il n'y a qu'un Qualcomm centriQ, qui est très récent et comme par hasard positionné low-power-toute.
Combien de coeurs, combien inutilisés, quel âge, déclinaison hi-perf ou low-power, quid du reste de la carte mère, etc.
Qu'on prenne le dernier CPU Intel pour laptop par exemple, en série ultra-low power, et ça pourrait surprendre des gens.
Je n'ai de parti pris arbitraire pour aucun fabricant. Mais ces annonces populistes où on joue surtout à ne pas donner les informations importantes me donneront toujours des haut-le-coeur.
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Anonyme . Évalué à 1.
Faut creuser un peu dans les messages Twitter. C'est l'un des plus gros Xeon actuel et qui malheureusement se met trop rapidement en sécurité thermique.
Après c'est aussi une charge de travail spécifique à l'entreprise, c'est un usage extrêmement multithreadé favorable pour le système de Qualcomm.
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
ça c'est juste une histoire de dissipateur thermique pourris, non ? (sous dimensionné)
"La première sécurité est la liberté"
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Zenitram (site web personnel) . Évalué à 4.
Si tu dois dissiper plus alors que ça consomme déjà beaucoup quand le CPU se protège, ça ne va pas aider au gain financier (coût de l’électricité).
Et tout le monde n'a pas envie de mettre son serveur en Antarctique pour pouvoir l'utiliser.
Non, le problème n'est pas la, le problème est qu'Intel ne sait pas faire mieux en ne perdant pas tant d’énergie en chaleur inutile, c'est tout (on parle par exemple d'AVX-512 qui est trop bien à paralléliser mais qui réduit sa vitesse automatiquement de 25% si tu l'utilises, le gain est alors plus faible que dans la pub "x2 par rapport à AVX2" car Intel sait que ça chauffe à mort mais "oublie" de le dire publiquement, quelque soit le dissipateur thermique que tu mets)
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
En fait si, car le rendement d'un cpu baisse avec la baisse de fréquence. Tu as un cpu à 2 Ghz avec 10 étages de pipelines, tu en fais un nouveau, plus gros, pour le mettre sur 20 étages, et le faire tourner à 4Ghz. Le rendement énergétique d'instruction par cycle d'horloge est le même car tu utilise une fab plus récente. Par contre, si il a trop chaud et retombe à 2Ghz, tu y perds car tu as 2 fois plus de flip-flop dans ton pipeline qui ne servent à rien.
Jusqu'à présent, les gros XEON Intel avait un meilleur rendement énergétique que l'équivalent en ARM, mais on parle de puce de 100W, c'est pour cela que c'était difficile d'imaginer ce genre de puce qui chauffe, plus rentable que les puces ARM de 10W.
"La première sécurité est la liberté"
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Guillaume Knispel . Évalué à 3.
D'un autre côté, le rendement énergétique diminue aussi à très haute fréquence, probablement principalement parce qu'on doit aussi augmenter la tension, et peut être aussi à causes d'autres effets.
Il y a un donc un sweet spot au niveau duquel le rendement est maximum pour un design donné, et certains modèles de Xeon (beaucoup?) privilégient ptet un peu les perfs au rendement.
[^] # Re: Xeon vous trouvez ça précis ?
Posté par totof2000 . Évalué à 1.
Non … En gros, ce sont les phases de transitions de ton signal (passage de l'état bas à l'état haut et vice-versa) qui consomme le plus d'énergie. Plus tu augmentes la fréquence, plus tu consommes. Une des manières de réduire cette consommation est de réduire la tension de ton signal (tu diminues ainsi les temps de passages entre les divers états donc la consommation d'énergie).
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est fini aussi ça, depuis 10 ans. Les fuites sont bien plus importante que la consommation dynamique, et ses fuites sont proportionnelles à la tension, d’où la course à la baisse.
"The dynamic power (switching power) dissipated per unit of time by a chip is C·V²·A·f, where C is the capacitance being switched per clock cycle, V is voltage, A is the Activity Factor[3] indicating the average number of switching events undergone by the transistors in the chip (as a unitless quantity) and f is the switching frequency."
Donc, si tu diminues V, tu diminues beaucoup la consommation, mais tu diminues aussi la vitesse de ta logique.
La mode est de faire varier tension et fréquence en même temps pour ajuster la consommation, et de tout couper quand on a pas besoin du module. Varier la fréquence a peu d’intérêt, car beaucoup de bloc ne peuvent pas varier en interne (cache et interconnexion), donc la perte de performance est réelle, le gain en consommation faible.
"La première sécurité est la liberté"
[^] # Re: Xeon vous trouvez ça précis ?
Posté par totof2000 . Évalué à 2.
Merci pour cette rectification, il est vrai que je ne suis plus de très près ce genre de sujet depuis quelques années (et 10 ans mine de rien ça passe vite …). mais comme le sujet m'intéresse, aurais-tu des sources ? Par exemple, la référence d'ou tu tires ta citation ?
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
La citation vient de wikipedia https://en.wikipedia.org/wiki/Dynamic_frequency_scaling
Pour le reste, je ne sais plus trop. J'ai commencer ma carrière dans la basse conso, en faisant du clock gating en 2000, et de gestion de power domaine et gestion d'état en 2006 (problème marrant : comment couper un bloc sachant qu'il va perdre son état interne ?).
"La première sécurité est la liberté"
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Guillaume Knispel . Évalué à 3.
L'augmentation de la conso due aux switch est linéaire avec f. L'augmentation due à la tension est quadratique avec V. Au delà d'une certaine f il est nécessaire d'augmenter V.
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Anonyme . Évalué à 1.
Ça m'étonnerait parce que c'est sensé être prévu pour cet usage et les fermes de serveur gardent déjà une température ambiante de l'ordre de 15°C.
Dans un rack tu n'as pas la même place que dans une tour, tu ne peux pas mettre de watercooling ou de gros radiateur avec un ventilateur de 140mm. Aussi avoir un U4 qui fait la même chose qu'un U3 ou U2 n'est pas rentable en terme d'espace. La nuisance sonore de petits ventilateurs qui tournent à fond n'est pas un problème pour ces structures mais ils en ont moins sous le pied que les grands ventilos de tours.
Puis on se rend bien compte avec la miniaturisation que plus un die est dense, plus il est important de pouvoir extirper rapidement sa température et il y a des limites physiques au niveau de l'inertie thermique des dissipateurs. Tout le jeu actuellement est de trouver la bonne densité de transistors pour éviter le throttle, chose que Intel n'a apparemment pas fait et qui la fout mal sur un tel produit HDG pour entreprise.
[^] # Re: Xeon vous trouvez ça précis ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
OVH est entièrement en watercooling, par exemple.
C'est peut être plus un problème de densité d'énergétique que de rating du radiateurs, tu as raisons. Les "points chauds" ont toujours été évité sur les puces.
"La première sécurité est la liberté"
# Disponibilité "grand public" de serveurs avec CPU Qualcomm Centriq ?
Posté par galactikboulay . Évalué à 2.
J'ai peut-être mal regardé mais je ne vois pas pour l'instant la possibilité d'acheter des serveurs équipés de ces CPU.
CloudFlare a eu accès à des prototypes j'imagine, quelqu'un sait quand la diffusion sera moins restreinte ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.