On 22. 01. 18 06:51, Dominik Madon wrote:
L'Itanium est un processeur VLIW (very large instruction word) embarquant
plusieurs opérations dans une seule instruction. L'idée était de simplifier le
dispatch dans les unités de calcul (ALU, Ld/St, FP) par un précalcul du
processeur. Le microcode est apparu bien avant l'Itanium, notamment pour
exécuter les instructions à virgule flottante qui nécessitent, pour certaines,
plusieurs micro-instructions.
Petite rectification... Itanium n'est pas à proprement parlé un
processeur VLIW. Cette dénomination lui est régulièrement faussement
attribuée par le simple fait que les gens se contente de voir que les
"mots" d'instructions font 128 bits. Il est vrai que certains
processeurs (des protos dans des unis) manipulaient des instructions de
128 bits et revendiquaient la classification de VLIW (à juste titre).
Or, les "mots" de 128 bits de l'Itanium contiennent en fait trois
instructions et le processeur peut charger 2 mots (de 128 bits) à chaque
cycle, offrant le potentiel d'exécuter 6 instructions en parallèle à
chaque cycle. Ce qui change avec Itanium par rapport à un bête
processeur VLIW est la fonction dévolue au compilateur. Alors que les
autres processeurs VLIW compte toujours à OOOE (Out-Of-Order Execution),
Itanium en est dépourvu et l'à remplacé par la notion d'EPIC (Explicit
Parallel Innstruction Computing) et l'utilisation des prédicats. C'est
parce que, tout seul et sans les techniques de compilation, Itanium
exécute mal les opération en // qu'il est catégorisé comme EPIC en
combinaison avec le compilateur (dont il dépend).
Le microcode est bien apparu avant Itanium, puisqu'on en retrouve les
prémices au début des années 50, avec l'introduction de la notion de
"conditional execution"; qui n'était que l'extension des développements
datant de 1947 au MIT. Dans les années 70, son usage était indispensable
à toute personne qui développait un CPU à base de "bit slice". Avec
l'arrivée des processeurs RISC dans les années 80, sont usage a diminué
et il est resté utilisé de manière sporadique pour des parties
spécifiques, comme le traitement des exceptions en cas d'absence de FPU
ou l'émulation de IA-32 sous Itanium justement.
Je ne suis pas d'accord pour entendre que la "misprediction" ne coûte
rien...
Sachant que la majorité du code se résume à l'exécution de LOAD & STORE
(mesure sur des millions de lignes de code ayant permit de définir
l'architecture HP-PA, ~80% !!!), je demande à voir l'effet sur un
serveur WEB ou de base de données... Le monde se focalise
essentiellement sur des micro-benchmarks débiles qui n'ont quasi aucun
impact dans le monde réel. Soyons sérieux, si les techniques de
limitation du "branch misprediction" sont utiles dans certain cas, sont
impact est souvent largement surévalué. Qui plus est, la plupart du
temps ces "techniques" se résument à faire une moyenne sur les trois
derniers branchements à cette adresse... et encore ne faut-il pas en
avoir trop... car les registres de "misprediction" sont très limités...
La taille, et surtout l'architecture, de la cache et du TLB ont beaucoup
plus d'impact que cette fameuse technique de "misprediction".
en temps écoulé peut-être mais c'est oublier la consommation
énergétique et la dissipation de chaleur et partant probablement la
durée de vie de la puce.
Faut-il se préoccuper de la consommation des "misprediction" lorsque
l'on voit que la majorité des gens dans les transports publiques jouent
a Candycrush ou regarde des vidéos... :-) Sans compter que la batterie
(ou le clavier) rendra l'âme bien longtemps avant la puce... :-)
Et les OS qui mettent 15 minutes à s'éteindre ? Je suis d'accord que
l'on doit chercher à minimiser l'impact de chaque instruction sur la
durée de vie de la batterie. Mais les GPUs sont sans doute 10 fois plus
gourmands; et là, rien n'est trop beau... il suffit de voir l'hystérie
de certains quand on leur montre des emojis qui bougent... très utile !
Oui, c'est vrai, cela consomme de l'énergie en plus.
Disons, que je vais choisir un autre système de chauffage chez moi :-)
dc
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull
