Des nouvelles instructions sont régulièrement ajoutées aux processeurs Intel et AMD.
Ces instructions appelées MMX, SSE 1, 2, 3, 4 permettent d'accélérer certaines taches
bien spécifiques comme le traitement video par exemple.
Je ne pense pas que les fabricants de logiciels fournissent autant de version de leurs
programmes qu'il y a de pack d'instructions additionnelles par rapport au jeu d'instruction
historique x86. En tout cas je n'ai jamais vu plusieurs versions d'un binaire executable,
une version si vous avez SSE4, une autre si vous n'avez que SSE3 etc.
Reste donc à savoir comment un processeur avec SSE3 se comporte lorsque qu'une instruction
SSE4 se présente. C'est l'objet de mon post. J'ai une idée sur la question mais j'attends de voir
vos réponses.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
"ast" wrote in message <47ce7fc0$0$871$:
Bonjour,
Des nouvelles instructions sont régulièrement ajoutées aux processeurs Intel et AMD. Ces instructions appelées MMX, SSE 1, 2, 3, 4 permettent d'accélérer certaines taches bien spécifiques comme le traitement video par exemple.
Je ne pense pas que les fabricants de logiciels fournissent autant de version de leurs programmes qu'il y a de pack d'instructions additionnelles par rapport au jeu d'instruction historique x86. En tout cas je n'ai jamais vu plusieurs versions d'un binaire executable, une version si vous avez SSE4, une autre si vous n'avez que SSE3 etc.
Moi si.
Il faut bien voir que la vitesse apportée par ces nouvelles instructions n'est que très rarement critique. La plupart des programmes sont limitées par leurs entrées-sorties (interaction avec l'utilisateur ou réseau). Pour les programmes qui restent, chacun adopte la politique qui l'intéresse.
Premier exemple : OpenSSL : c'est de la crypto qui sert en flux ; les performances peuvent limiter le débit plus que le réseau sur des machines un peu lentes. Le paquet Debian i386 vient avec 4 versions de la bibliothèque : sans optimisation particulière, optimisé pour 486, pentium, et pentium 3 + CMOV. C'est le chargeur dynamique qui sélectionne automatiquement la bonne version à utiliser.
Deuxième exemple : les outils d'encodage vidéo libres. Les développeurs de MPlayer et ffmpeg recommandent vivement de ne pas utiliser de binaires précompilés, et de se compiler soi-même sa propre version. Les scripts de configuration détectent le processeur sur lequel c'est censé tourner, et activent les optimisations qui vont bien.
Reste donc à savoir comment un processeur avec SSE3 se comporte lorsque qu'une instruction SSE4 se présente. C'est l'objet de mon post. J'ai une idée sur la question mais j'attends de voir vos réponses.
Sur le principe, c'est très facile à tester : il suffit de trouver une machine un peu vieille, d'y compiler un programme un peu complexe avec des options incompatible, et regarder.
En pratique, ce qui se passe, c'est que le processeur déclenche une exception (de même nature que s'il rencontre une instruction complètement inconnue, ce qui pour lui est effectivement est le cas), cette exception est rattrapée par le système d'exploitation, qui va soit interrompre le programme en signalant une erreur, soit, si le programme est prévu pour, déclencher une routine de gestion d'erreur dans le programme.
"ast" wrote in message <47ce7fc0$0$871$ba4acef3@news.orange.fr>:
Bonjour,
Des nouvelles instructions sont régulièrement ajoutées aux processeurs
Intel et AMD. Ces instructions appelées MMX, SSE 1, 2, 3, 4 permettent
d'accélérer certaines taches bien spécifiques comme le traitement video
par exemple.
Je ne pense pas que les fabricants de logiciels fournissent autant de
version de leurs programmes qu'il y a de pack d'instructions
additionnelles par rapport au jeu d'instruction historique x86. En tout
cas je n'ai jamais vu plusieurs versions d'un binaire executable, une
version si vous avez SSE4, une autre si vous n'avez que SSE3 etc.
Moi si.
Il faut bien voir que la vitesse apportée par ces nouvelles instructions
n'est que très rarement critique. La plupart des programmes sont limitées
par leurs entrées-sorties (interaction avec l'utilisateur ou réseau). Pour
les programmes qui restent, chacun adopte la politique qui l'intéresse.
Premier exemple : OpenSSL : c'est de la crypto qui sert
en flux ; les performances peuvent limiter le débit plus que le réseau sur
des machines un peu lentes. Le paquet Debian i386 vient avec 4 versions de
la bibliothèque : sans optimisation particulière, optimisé pour 486,
pentium, et pentium 3 + CMOV. C'est le chargeur dynamique qui sélectionne
automatiquement la bonne version à utiliser.
Deuxième exemple : les outils d'encodage vidéo libres. Les développeurs de
MPlayer et ffmpeg recommandent vivement de ne pas utiliser de binaires
précompilés, et de se compiler soi-même sa propre version. Les scripts de
configuration détectent le processeur sur lequel c'est censé tourner, et
activent les optimisations qui vont bien.
Reste donc à savoir comment un processeur avec SSE3 se comporte lorsque
qu'une instruction SSE4 se présente. C'est l'objet de mon post. J'ai une
idée sur la question mais j'attends de voir vos réponses.
Sur le principe, c'est très facile à tester : il suffit de trouver une
machine un peu vieille, d'y compiler un programme un peu complexe avec des
options incompatible, et regarder.
En pratique, ce qui se passe, c'est que le processeur déclenche une
exception (de même nature que s'il rencontre une instruction complètement
inconnue, ce qui pour lui est effectivement est le cas), cette exception est
rattrapée par le système d'exploitation, qui va soit interrompre le
programme en signalant une erreur, soit, si le programme est prévu pour,
déclencher une routine de gestion d'erreur dans le programme.
Des nouvelles instructions sont régulièrement ajoutées aux processeurs Intel et AMD. Ces instructions appelées MMX, SSE 1, 2, 3, 4 permettent d'accélérer certaines taches bien spécifiques comme le traitement video par exemple.
Je ne pense pas que les fabricants de logiciels fournissent autant de version de leurs programmes qu'il y a de pack d'instructions additionnelles par rapport au jeu d'instruction historique x86. En tout cas je n'ai jamais vu plusieurs versions d'un binaire executable, une version si vous avez SSE4, une autre si vous n'avez que SSE3 etc.
Moi si.
Il faut bien voir que la vitesse apportée par ces nouvelles instructions n'est que très rarement critique. La plupart des programmes sont limitées par leurs entrées-sorties (interaction avec l'utilisateur ou réseau). Pour les programmes qui restent, chacun adopte la politique qui l'intéresse.
Premier exemple : OpenSSL : c'est de la crypto qui sert en flux ; les performances peuvent limiter le débit plus que le réseau sur des machines un peu lentes. Le paquet Debian i386 vient avec 4 versions de la bibliothèque : sans optimisation particulière, optimisé pour 486, pentium, et pentium 3 + CMOV. C'est le chargeur dynamique qui sélectionne automatiquement la bonne version à utiliser.
Deuxième exemple : les outils d'encodage vidéo libres. Les développeurs de MPlayer et ffmpeg recommandent vivement de ne pas utiliser de binaires précompilés, et de se compiler soi-même sa propre version. Les scripts de configuration détectent le processeur sur lequel c'est censé tourner, et activent les optimisations qui vont bien.
Reste donc à savoir comment un processeur avec SSE3 se comporte lorsque qu'une instruction SSE4 se présente. C'est l'objet de mon post. J'ai une idée sur la question mais j'attends de voir vos réponses.
Sur le principe, c'est très facile à tester : il suffit de trouver une machine un peu vieille, d'y compiler un programme un peu complexe avec des options incompatible, et regarder.
En pratique, ce qui se passe, c'est que le processeur déclenche une exception (de même nature que s'il rencontre une instruction complètement inconnue, ce qui pour lui est effectivement est le cas), cette exception est rattrapée par le système d'exploitation, qui va soit interrompre le programme en signalant une erreur, soit, si le programme est prévu pour, déclencher une routine de gestion d'erreur dans le programme.
ast
"Nicolas George" <nicolas$ a écrit dans le message de news: 47ce85b5$0$9030$
"ast" wrote in message <47ce7fc0$0$871$:
Je vous remercie pour votre réponse détaillée
En pratique, ce qui se passe, c'est que le processeur déclenche une exception (de même nature que s'il rencontre une instruction complètement inconnue, ce qui pour lui est effectivement est le cas), cette exception est rattrapée par le système d'exploitation, qui va soit interrompre le programme en signalant une erreur, soit, si le programme est prévu pour, déclencher une routine de gestion d'erreur dans le programme.
Je peux maintenant dire qu'elle était mon idée.
Je pensais que le programme d'interruption déclenché par l'arrivé d'une instruction inconnue pouvait émuler la nouvelle instruction. Ainsi un binaire éxécutable pourrait être compatible avec tous les processeurs.
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de news: 47ce85b5$0$9030$426a74cc@news.free.fr...
"ast" wrote in message <47ce7fc0$0$871$ba4acef3@news.orange.fr>:
Je vous remercie pour votre réponse détaillée
En pratique, ce qui se passe, c'est que le processeur déclenche une
exception (de même nature que s'il rencontre une instruction complètement
inconnue, ce qui pour lui est effectivement est le cas), cette exception est
rattrapée par le système d'exploitation, qui va soit interrompre le
programme en signalant une erreur, soit, si le programme est prévu pour,
déclencher une routine de gestion d'erreur dans le programme.
Je peux maintenant dire qu'elle était mon idée.
Je pensais que le programme d'interruption déclenché par l'arrivé d'une instruction
inconnue pouvait émuler la nouvelle instruction. Ainsi un binaire éxécutable pourrait
être compatible avec tous les processeurs.
"Nicolas George" <nicolas$ a écrit dans le message de news: 47ce85b5$0$9030$
"ast" wrote in message <47ce7fc0$0$871$:
Je vous remercie pour votre réponse détaillée
En pratique, ce qui se passe, c'est que le processeur déclenche une exception (de même nature que s'il rencontre une instruction complètement inconnue, ce qui pour lui est effectivement est le cas), cette exception est rattrapée par le système d'exploitation, qui va soit interrompre le programme en signalant une erreur, soit, si le programme est prévu pour, déclencher une routine de gestion d'erreur dans le programme.
Je peux maintenant dire qu'elle était mon idée.
Je pensais que le programme d'interruption déclenché par l'arrivé d'une instruction inconnue pouvait émuler la nouvelle instruction. Ainsi un binaire éxécutable pourrait être compatible avec tous les processeurs.
Nicolas George
"ast" wrote in message <47ce890f$0$874$:
Je pensais que le programme d'interruption déclenché par l'arrivé d'une instruction inconnue pouvait émuler la nouvelle instruction. Ainsi un binaire éxécutable pourrait être compatible avec tous les processeurs.
C'est ce qui se passe, au moins sous Linux, quand on insiste pour faire tourner des programmes utilisant les flottants sur un processeur dénué de FPU. Mais c'est abominablement lent (le changement de contexte lié à l'exception est très coûteux), et ce ne serait pas du tout rentable pour les cas d'optimisations fines.
PS : ton newsreader envoie des lignes trop longues.
"ast" wrote in message <47ce890f$0$874$ba4acef3@news.orange.fr>:
Je pensais que le programme d'interruption déclenché par l'arrivé d'une
instruction inconnue pouvait émuler la nouvelle instruction. Ainsi un
binaire éxécutable pourrait être compatible avec tous les processeurs.
C'est ce qui se passe, au moins sous Linux, quand on insiste pour faire
tourner des programmes utilisant les flottants sur un processeur dénué de
FPU. Mais c'est abominablement lent (le changement de contexte lié à
l'exception est très coûteux), et ce ne serait pas du tout rentable pour les
cas d'optimisations fines.
PS : ton newsreader envoie des lignes trop longues.
Je pensais que le programme d'interruption déclenché par l'arrivé d'une instruction inconnue pouvait émuler la nouvelle instruction. Ainsi un binaire éxécutable pourrait être compatible avec tous les processeurs.
C'est ce qui se passe, au moins sous Linux, quand on insiste pour faire tourner des programmes utilisant les flottants sur un processeur dénué de FPU. Mais c'est abominablement lent (le changement de contexte lié à l'exception est très coûteux), et ce ne serait pas du tout rentable pour les cas d'optimisations fines.
PS : ton newsreader envoie des lignes trop longues.
