URL: https://linuxfr.org/users/patrick_g/journaux/les-bloat-cpu
Title: Les bloat-CPU
Authors: patrick_g
Date: 2005年07月22日T12:13:41+02:00
Tags: debian
Score: 0
Après l'abandon de la course à la fréquence par Intel on croyait que l'avenir des CPU passerait par le multi-core. Cela reste vrai mais s'y ajoute une autre tendance bien plus étrange et discutable : l'intégration dans le microprocesseur de fonctions auparavant prises en charge en externe.
Quand il s'agit, comme pour les AMD, d'intégrer le contrôleur mémoire dans le CPU on ne peut qu'applaudir à l'initiative. Après tout c'est du hardware mis dans du hardware : on avait déjà fait ceci lors de l'intégration des coprocesseurs arithmétiques dans les CPU sous forme d'unités FPU… conceptuellement banal et technologiquement sensé et profitable.
D'ailleurs pour illustrer ceci on apprend qu'AMD veut continuer sur sa lancée et va intégrer le contrôleur PCIexpress dans ses futures puces pour diminuer encore les temps de latence ([http://www.theinquirer.net/?article=24756(...)](http://www.theinquirer.net/?article=24756) ).
Par contre ce qui est moins banal et potentiellement plus gênant pour moi c'est l'intégration dans le CPU de choses qui devraient êtres effectuées en software.
Regardez cet article : [http://www.theinquirer.net/?article=24781(...)](http://www.theinquirer.net/?article=24781) on y découvre la nouvelle lubie d'Intel :** Rockton Technology**
Il s'agit d'intégrer en hardware dans ses puces futures des routines spéciales pour accélérer le code Java et .Net !
En gros c'est un nouveau jeu d'instruction (comparable au SSE ou au MMX) pour prendre en charge en hard les instructions spécifiques et courantes propres à ces langages managés. Il y aura aussi une partie software pour faire la jonction avec le kernel (un compilateur Just In Time).
Vous allez me dire que c'est cool et que ça va booster les programmes Java et .Net…et je vous réponds qu'à mon avis c'est une grosse connerie !
1) Les ajouts de nouveaux jeux d'instructions sur une archi ancienne c'est laid : ça bloque souvent la concurrence (lock-in au profit d'Intel) et ça pose le problème de l'adaptation des programmes pour en tirer partie (des IFDEF partout ?)
2) Cela favorise arbitrairement certains langages aux détriment d'autres déjà existants ou futurs…et en plus Java et .Net dans une perspective libriste c'est le pire choix possible !
3) L'interface software avec le kernel pose également problème : quelle sera la licence ? Est-ce qu'une alternative libre sera possible ou bien l'API d'interface hardware restera-elle non documentée ? Un compilo JIT en interface avec le kernel est-ce que c'est propre du point de vue technique ?
4) Sur un plan philosophique le CPU ne devrait prendre en charge que des opérations de base sur les entiers et les flottants et ne pas se transformer en bloat-CPU qui dit papa-maman et fait le café !
Avec la puissance marketing et financière d'Intel il est probable que cette solution s'impose dans le monde de l'entreprise (qui ne jure que par Java et .Net) et que donc le libre devra s'adapter qu'il le veuille ou non pour rester compétitif : Si une appli Java ou .Net tourne 35 fois plus vite sur le "Windows 2007 RocktonEdition" que sur le noyau 2.6.26 d'une Debian Etch y'aura pas photo pour le DSI de la boite !
Comme la course à la fréquence n'est plus trop possible, comme le multi-core l'ensemble des fondeurs le font ou le feront, comme l'informatique quantique est encore dans les limbes…et bien le seul vrai différenciateur technique c'est **LA** fonction spécifique que ne propose pas le concurrent ! Donc le bloat-CPU est une tendance lourde qui semble inévitable.
Via met des modules hardware de crypto dans ses puces (AES et RSA et SHA), IBM met ou va mettre des modules hardware qui câblent les instructions SQL courantes dans ses puces POWER…et maintenant Intel avec JAVA et .NET !
Prochaine étape Outlook et Internet Explorer directement gravés dans votre CPU ?