Greboca  

LinuxFr.org : les journaux  -  Dix ans après : acheter un CPU Intel Ivy Bridge, était-ce judicieux ?

 -  16 juillet - 

Sommaire

Singe se prenant la tête, comme pour exprimer des regrets. Regret, par Jason Hickey, sous licence CC BY 2.0

Un peu d'histoire (la mienne)

En octobre 2011 je publiais, avec l’enthousiasme de la jeunesse, ce journal vantant les processeurs Sandy Bridge pour une utilisation sous Linux : Intel Sandy Bridge et Linux : état des lieux.

Le rendement du processeur et l'excellence de la prise en charge de la partie graphique sous Linux par l'Intel Open Source Technology Center me séduisaient alors. Je n'avais pas en tête alors le problème des firmware non-libres nécessaires au fonctionnement du processeur qui sont encore aujourd'hui un obstacle aux BIOS libres pour les machines à processeurs Intel.

J'avais même publié un billet dans le quel je m'extasiais du rapport performance/prix de cette génération de processeur, camembert à l'appui : Quelle configuration matérielle milieu de gamme en cette fin 2011 et à quel prix ?

Ayant opté pour le successeur du Sandy Bridge (un Tock dans la stratégie industrielle Tick-Tock du fondeur, tous deux étant des Core de 3ème génération), je rédigeais ce journal en avril 2012 avec le même enthousiasme : Intel Ivy Bridge et Linux : ça juste marche.

Le prix de l'upgrade restait relativement raisonnable, comme je le détaillais sur mon blogue.

En effet, j'avais fait le choix, entre Sandy Bridge, Ivy Bridge ou d'attendre le suivant, d'un processeur de la famille Ivy Bridge notamment parce que Eugeni Dodonov, ingénieur à l'Intel Open Source Technology Center, avait très gentiment pris le temps de me répondre et de m'expliquer que, si la partie CPU était un Tock, la partie graphique était d'avantage un Tick tellement les changements étaient significatifs, et les performances améliorées.

Et comme je souhaitais acheter du matériel durable et sans carte graphique externe, ça m'a paru une bonne idée de sauter le pas à cette occasion ; j'ai alors choisi un dual core (pour des questions de sobriété énergétique, un point sur lequel Intel était alors en avance sur ses concurrents) avec hyperthreading avec le plus musclé des IGP de génération Ivy Bridge (le HD Graphics 4000), soit un i3-3225.

Il faut savoir qu'Intel avait repris ses investissements dans les IGP (qui stagnaient quelque peu depuis le légendaire GMA 950) sous la pression de son concurrent AMD et que les HD Graphics progressaient nettement à chaque génération (dans le prolongement d'un mouvement qui avait précédé et par lequel Intel intégrait de plus en plus ses contrôleurs sur la puce elle-même et non plus sur un chipset séparé comme c'était l'usage jusqu'alors. Les plus vieux d'entre nous se souviendront que nous choisissions alors, outre le meilleur processeur, le meilleur chipset pour chaque processeur selon nos budgets).

J'ajoute que malheureusement Eugeni Dodonov est mort d'un accident de vélo à peu très peu de temps après que j'ai échangé avec lui : ça m'a fait un choc.

Bilan des années qui ont suivies (aka les années folles)

Depuis, je n'ai pas eu beaucoup d'occasions de regretter mon achat :

  • Dix ans après je suis toujours satisfait de la puissance CPU offerte par ma machine (d'ailleurs je m’apprête à gonfler la RAM pour prolonger ma configuration) ;
  • La partie graphique a bénéficié d'une très bonne prise en charge native sous Linux, en grande partie grâce aux efforts des ingénieurs d'Intel eux-même, ce qui m'a permis (d'éviter moult problèmes et) de tester toutes les innovations de la pile graphique Linux de ces dernières années : accélération 3D, accélération vidéo, Wayland… Je précise toutefois que je ne joue pas sur ma machine, c'est sans doute pourquoi la puissance graphique de ma machine me suffit.
  • J'ai pu bénéficier d'une configuration non seulement économe en énergie, mais aussi silencieuse compte tenu de sa faible dissipation thermique (une seul ventilateur dans ma machine : à l’arrière de la tour, le reste étant des dissipateurs passifs).
  • Je n'ai pas pu réaliser mon souhait de passer sur un BIOS libre (les gros firmwares propriétaires d'Intel n'aident pas).

Bilan actuel dans un monde post-Spectre (bon courage pour le prononcer ce mot-là)

Le bilan actuel n'est plus si favorable.

L'avalanche de vulnérabilités matérielles révélées depuis Spectre liées à l'implémentation YOLO de l'exécution spéculative du code dans les microprocesseurs Intel de la dernière décennie a nécessité de nombreuses rustines au prix d'une dégradation des performances des processeurs.

Comme ces performances, désormais en partie évanouies, servaient à Intel à justifier le prix de vente de ses processeurs, vous comprenez bien que, si quelqu'un l'a dans le baba, c'est visiblement le client, aka moi, toi, nous.

Mais, comme si cela ne suffisait pas, à l'occasion d'échanges sous le récent Lien Benchmarking The Linux Mitigated Performance For Retbleed: It's Painful, je me rends compte qu'une (pour commencer) faille post-Spectre (identifiée CVE-2020-0543 aka Special Register Buffer Data Sampling ou SRBDS), pourtant comblée dans le noyau Linux, reste béante chez moi pour la simple raison qu'intel a décidé, sans honte aucune, de ne plus mettre à jour les microcodes des processeurs Ivy Bridge à compter de juin 2020 [1]. Voilà, comme si c'était une décision normale, de fin de prise en charge au bout d'une dizaine d'années. Comme si Intel n'était pas à l'origine des trous de sécurité chez ses clients et qu'il n'avait aucune responsabilité à réparer les trous de sécurité de ses processeurs défaillants.

Je tâcherai de m'en souvenir lors de mon prochain achat.

Et, justement : toi lecteur, qui a un ancien processeur AMD, bénéficies-tu d'un meilleur suivi des failles de ton processeur ?


Illustration en tête du journal : Regret, par Jason Hickey, sous licence CC BY 2.0.

Pour aller plus loin, lire aussi sur Wikipédia : Mitigation de la vulnérabilité spectre.

[1] Si vous êtes dans le même cas, activez le mode Fission de Firefox pour vous protéger.

Commentaires : voir le flux Atom ouvrir dans le navigateur

par antistress

LinuxFr.org : les journaux

LinuxFr.org : Journaux

Plaidoyer pour la NPI et la gamme Woodstock

 -  10 juillet - 

Sommaire vive les HP 1ère complète de bureau 1ère scientifique de poche éternel roc solide 1ère financière de poche 1ère programmable de poche 1er (...)


Un utilitaire pour formater la sortie de avr-objdump

 -  4 juillet - 

… ou l'heure de l'auto-promo a sonné :-D.Bonjour à tous.Un de mes passe-temps est le développement embarqué, notamment avec les micro-contrôleurs (...)


CISSP, sécurité, il faut que je vous raconte un truc...

 -  2 juillet - 

Il faut que je vous parle d’un truc. Fin 2019, trois mois avant le confinement, il m’est arrivé quelque chose. La crise des 40 ans 4 ans plus tard, (...)


Cartes marquées, magie et triche aux jeux...

 -  29 juin - 

NdM: traduction non sourcée de https://twitter.com/CoderMiddy/status/1541965867671494656 (potentiellement sans autorisation) Télécharger ce contenu (...)


Anvil le retour

 -  27 juin - 

Bonjour NalCe journal est avant tout une question, sur un framework qui m'intéresse beaucoup : ANVILCela permet de coder avec python coté (...)