Le but de cette dépêche n’est pas de présenter l’ensemble des nouveautés de la dernière architecture de processeurs lancée par Intel sous le nom de code « Sandy Bridge » (nous vous renvoyons à vos sites habituels spécialisés dans le matériel pour cela), mais plutôt de s’attarder sur les nouveautés internes qui demandent une prise en charge logicielle.
Ce qu’il faut savoir des processeurs Intel de la famille Sandy Bridge
Processeur 64 bits
Les processeurs de la famille Sandy Bridge sont des processeurs d’architecture x86-64, c’est‐à‐dire l’évolution 64 bits des traditionnels processeurs x86 déclinés depuis l’origine du PC. Un processeur x86-64 pourra faire tourner aussi bien une version 32 bits que 64 bits de votre distribution GNU/Linux. Les versions 32 bits sont nommées iX86 (par exemple i386, i586, i686), et les versions 64 bits, amd64 (AMD ayant été le premier à adapter le jeu d’instructions x86 au 64 bits).
Architecture multicœurs
Suivant les modèles, les processeurs de cette famille peuvent avoir plusieurs cœurs (qui peuvent eux‐même gérer plusieurs threads via la technologie Hyperthreading). Le noyau Linux les prend en charge de longue date, sans qu’il soit besoin d’intervenir. Au niveau des applications elles‐mêmes, certaines sont conçues pour exploiter au mieux ces architectures : soit automatiquement, soit sur demande de l’utilisateur (vérifier les paramètres de configuration du logiciel, ou les arguments permis dans le cas d’une interface en ligne de commande – par exemple, pour l’encodage vidéo, FFmpeg permet de spécifier le nombre de threads via l’argument de même nom).
MMX, SSE et maintenant AVX
Au fur et à mesure des nouveaux modèles, les processeurs de la famille x86 se sont dotés de nouvelles instructions devant permettre d’accélérer les calculs dans des domaines particuliers (traditionnellement ce que l’on appelle le traitement multimédia). Le jeu d’instructions MMX a ainsi été complété par les jeux d’instructions SSE, SSE 2, SSE 3, puis SSE 4, pour un bénéfice pas toujours évident.
Sandy Bridge apporte de nouvelles fonctions d’opérations vectorielles en 256 bits, sous le nom Advanced Vector Extensions (AVX). Celles‐ci sont prises en charge depuis la version 2.6.30 du noyau Linux.
GPU intégré
Avec cette famille de processeurs, Intel réunit véritablement (physiquement et logiquement) le processeur central (CPU) et le processeur graphique (GPU) sur un même circuit. Le GPU existe en deux versions : selon les processeurs, on trouvera un GMA HD 2000 ou un GMA HD 3000. Ces GPU sont identiques, sauf en ce qui concerne le nombre d’unités d’exécution (respectivement 6 contre 12).
Pour utiliser le GPU, il vous faudra au minimum :
- un noyau Linux 2.6.38 ;
- Mesa 7.11 ;
- le pilote xf86-video-intel 2.15.0.
Technologie Quick Sync Video
Cette famille de processeurs embarque un circuit dédié au décodage‐encodage vidéo, dont les tests révèlent une belle efficacité, supérieure à celle d’un CPU ou d’un GPU en la matière.
Hélas, cette partie du processeur est en sommeil sous Linux, faute de support. Intel nous dit que la question est à l’étude…
Conclusions
Les processeurs de la famille Sandy Bridge restent un choix intéressant pour les utilisateurs de GNU/Linux, à plusieurs titres :
- ils ont un très bon rendement : ceux qui cherchent une solution ne consommant ni ne chauffant trop trouveront chaussure à leur pied avec ce tout‐en‐un ;
- ils sont bien pris en charge : Intel, fidèle à ses habitudes, développe ses pilotes graphiques pour Linux sous licence libre, en collaboration avec le reste de la communauté.
Reste un point négatif : alors que Linux a été le premier système d’exploitation à prendre en charge les instructions AVX, il est aujourd’hui honteusement privé de l’intéressante technologie Quick Sync Video.
À noter toutefois que les utilisateurs de processeurs de la famille Sandy Bridge ne seront pas pour autant privés d’accélération vidéo : les pilotes graphiques Intel supportent la [Video Acceleration API] qui permet (avec les logiciels supportant cette API), en utilisant le GPU, d’accélérer le décodage et prochainement l’encodage vidéo pour les formats les plus courants (VP8/WebM manque à l’appel toutefois) (lire sur Phoronix : Intel Sandy Bridge Video Encode For Linux et Intel Proposes Major Additions To VA-API Acceleration).
Enfin, si vous êtes particulièrement intéressés par la partie graphique de ces processeurs, sachez que leur successeur à venir, nommé Ivy Bridge, devrait justement mettre l’accent sur les parties Quick Sync Video (la belle affaire) et GPU.
# Quels modèles ?
Posté par gUI (Mastodon) . Évalué à 3.
En lisant cette dépĉhe, on ne sait pas si il existe déjà des processeurs sur cette archi, ou si c'est la toute dernière qui doit sortir d'ici peu. Même si je m'intéresse un peu aux nouveaux processeurs, je ne connais pas forcément les noms des architectures, mais plutôt les "familles" de nouveaux modèles. Pour la date, la page Wikipedia française explique rapidement que les processeurs existent depuis janvier 2011.
Pour la liste des processeurs en question, rien dans la dépêche, et rien dans la page Wikipedia française. Il faut alors aller sur la page Wikipedia anglaise pour trouver les processeurs concernés.
Sans aller jusqu'à tous les lister, quelques exemples de références (et leur date de dispo) en desktop/server et mobile permettraient je pense de fixer les idées.
Sinon merci à l'auteur de la dépêche d'avoir pris soin de travailler sur la page Wikipedia française !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quels modèles ?
Posté par madhatter (site web personnel) . Évalué à 3.
J'ai un Core i5 2500K (desktop donc), qui embarque un GPU HD 3000 et fonctionne très bien sous Linux (Debian Wheezy, kernel Linux 3.0) en lecture HD (mkv 1080p), accélérée via GPU, sans tearing et en 24p (24 img/sec).
There is no spoon...
[^] # Re: Quels modèles ?
Posté par antistress (site web personnel) . Évalué à 0.
Oui, c'est une bonne remarque. En effet la liste des processeurs est disponible sur la Wikipédia EN : http://en.wikipedia.org/wiki/Sandy_Bridge#Desktop_processors
# [:mouaif]
Posté par claudex . Évalué à 6.
Sauf qu'ils ne publient pas la documentation de leurs puces graphiques. Ce qui fait que le jour où ils arrêteront de maintenir le pilote, il risque de devenir vite inutilisable : on pourrait faire des retouches pour l'adapter aux changement d'API mais si un bug se présente à cause de la puce, on ne pourra rien y faire. Cf. ce qu'il s'est passé avec les pilotes iwl2200.
« 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: [:mouaif]
Posté par ʭ ☯ . Évalué à 10.
Tu cherches ça? Oui pour le WiFi il y a un problème, mais non, pour les puces graphiques dévelopées en interne, c'est complètement libéré.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: [:mouaif]
Posté par claudex . Évalué à 0.
Ah, c'est génial ça. J'avais vu des développeurs de la pile graphique se plaindre, soit ils étaient mal informé, soit il manque des trucs là-dedans.
« 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
# Opérations vectorielles ?
Posté par Paul Chavent (site web personnel) . Évalué à 4.
Je ne vois pas le rapport avec le noyau... Ce n'est pas plutôt un support offert par le compilateur ? Est-ce que le noyau contient des morceaux de codes qui sont liés à cela (code d'initialisation, ou utilisation de calcul vectoriels directement par le noyau) ?
[^] # Re: Opérations vectorielles ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Le changement de contexte nécessite sa sauvegarde. il faut donc que le noyau connaisse l'existence des registres AVX pour les sauver.
"La première sécurité est la liberté"
[^] # Re: Opérations vectorielles ?
Posté par Guillaume Knispel . Évalué à 1.
Ça serait bien que les processeurs proposent une option avec laquelle ils indiquent à l'OS quel est l'espace nécessaire pour sauvegarder tous les registres des extensions, et une instruction pour le faire, histoire d'éviter d'avoir a ajouter un support spécifique à chaque fois que des registres apparaissent. (Bon, il faudrait peut-être régler quelques détails comme laisser la possibilité de faire des sauvegardes partielles et paresseuses si c'est une technique toujours employée.)
[^] # Re: Opérations vectorielles ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Tu es encore un softeux qui croit que le hardware est magique ? :)
Il y a toujours des effets de bords à ce genre de chose : bit de l'alu, status de fpu, etc... De plus, cela impose une instruction très spécial qui peut être trop longue à exécuter, il y a aussi le problème de la gestion d'erreur en cas de recopie à moitié sur une page non mappé.
"La première sécurité est la liberté"
[^] # Re: Opérations vectorielles ?
Posté par lasher . Évalué à 3.
C'était pas le PowerPC qui avait une instruction pour faire des loads (resp. stores) multiples depuis (vers) une adresse mémoire?
Je ne me souviens plus très bien, mais quelque chose du genre
ldmul 1,31,uneAdressequi chargerait 31 mots de 32 bits vers les registres r1 à r31?
[^] # Re: Opérations vectorielles ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
si, et idem pour ARM. Mais la différence est que tu connais à l'avance la quantité de donné copié, ce qui n'est pas le cas, si le but est de fonctionner aussi avec de futur registre en plus.
D'ailleurs, je ne comprends pas que Intel ou AMD ne rajoute pas un paquet de registre genre 256 en SIMD avec un accès mémoire en lecture/écriture sur une taille fixe (8 16 32 64 128 256 bits) et ensuite un transfert morceau par morceau vers les registres normaux (en gros avec un adressage interne au registre). Le but serait de mieux utiliser le preload et de masquer la latence de la DRAM sans les inconvénients du code SSE et les contraintes d'alignement qui vont avec.
"La première sécurité est la liberté"
[^] # Re: Opérations vectorielles ?
Posté par Guillaume Knispel . Évalué à 2.
Aie ça me fait un peu mal là, étant donné que je fais ce genre de choses : http://blog.xivo.fr/index.php?post/2011/10/04/PCB-prototypes-and-flash-SPI-testing
# QuickSync, intéressant .... bof
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 4.
Mouais, ça encode vite, ... mais mal, ou du moins pas aussi bien que de l'encodage purement CPU.
Exemple de test ici: http://www.hardware.fr/articles/imprimer/815/
[^] # Re: QuickSync, intéressant .... bof
Posté par zebra3 . Évalué à 4.
Il me semble que c'est pareil pour tout ce qui est encodage par GPU, notamment chez Nvidia.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: QuickSync, intéressant .... bof
Posté par Sclarckone . Évalué à 7.
Tout à fait et ce n'est pas mieux chez AMD...un article complet et intéressant sur le sujet: Encodage H.264 - CPU vs GPU : Nvidia CUDA, AMD Stream, Intel MediaSDK et x264 en test
[^] # Re: QuickSync, intéressant .... bof
Posté par Guillaume Knispel . Évalué à 1.
Mais si on veut filmer+encoder un truc a l'arrache en temps réel c'est ptet intéressant niveau conso ?
# Merci
Posté par Anonyme . Évalué à 3.
Je comptais justement monter une config Corei7, cet article arrive à pic pour moi.
Petite sous-règle de la loi de Moore : attendre un an après la sortie d'une config pour ne pas pleurer à chaudes larmes sur le plancher.
[^] # Re: Merci
Posté par maderios . Évalué à 2.
J'ai un core I7+P8P67 depuis 6 mois, utilisé d'abord avec Debian. Je suis passé récemment à Gentoo et heureusement que le Core I7 était là pour les compilations .....
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: Merci
Posté par bubar🦥 (Mastodon) . Évalué à 6.
ccache, tmpfs, cgroups et cpulimit sont nos amis
# Intel Insider et Vpro
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
J'avais déjà regardé les fonctions du Sandy Bridge en terme d'aspects éthiques (donc notamment les dangers DRM et informatique déloyale, qui contrôle votre processeur) et bidouillabilité. Voir https://listes.april.org/wws/arc/informatique-deloyale/2011-01/msg00000.html et https://listes.april.org/wws/arc/informatique-deloyale/2011-01/msg00002.html
Quelle « prise en charge logicielle » pour :
- l'Intel Insider, une restriction matérielle pour faciliter le DRM sur le streaming ?
- le VPro qui permet de désactiver un ordi à distance ou d'effacer ses disques (par 3G, ethernet ou via internet) ?
(Source http://en.wikipedia.org/wiki/Sandy_Bridge_%28microarchitecture%29 )
[^] # Re: Intel Insider et Vpro
Posté par Guillaume Knispel . Évalué à 2.
Si t'utilises un OS libre tu peux sûrement te servir des trucs TPM and co en les contrôlant complètement toi-même. Pour les trucs de sécurité à distance, les BIOS ont typiquement une option de désactivation irréversible sans doute car beaucoup de grosses boites considèrent ça comme un risque dans certains cas (même si je ne sais pas comment cette désactivation irréversible est implémentée, il faudrait reverse chaque bios différent pour en être sûr, d'un autre côté si on est parano il faudrait déjà reverse chaque bios pour vérifier l'absence de backdoor par toutes les autres manières possible, ainsi que reverse le hard pour vérifier l'absence de backdoor matérielle)
[^] # Re: Intel Insider et Vpro
Posté par antistress (site web personnel) . Évalué à 2.
Les questions soulevées sont intéressantes, je n'en avais pas connaissance.
Il me semble également que tout ce qui est DRM dans le processeur est vain si l'OS ne l'implémente pas également ?
Enfin, avec un BIOS en tout cas, parce qu'avec ces saloperies d'UEFI on n'est plus sûr de rien, hein...
Pour le coup, il me semble qu'AMD est plus coopératif avec le projet Coreboot (ex LinuxBIOS) si on devait remplacer l'UEFI, mais quand on regarde la liste des carte supportées c'est assez maigre pourtant ? www.coreboot.org/
# hd3000 dans le cpu
Posté par Yao Kuramoto . Évalué à 2.
ça donne quoi en terme de perfs 3d par rapport à nvidia et ati ?
d'une manière générale, le faite d'intégrer le gpu dans le cpu ça apporte beaucoup ?
j'ai trouvé ça comme photo : http://www.notebookcheck.net/typo3temp/pics/61e62d7671.gif
bon en fait j'ai trouvé des infos ici :
http://www.notebookcheck.net/Review-Intel-HD-Graphics-3000-graphics-solution.43710.0.html
mais mon anglais est un peux rouillé.... il semble que ce soit pas trop mal ? (à confirmer)
[^] # Re: hd3000 dans le cpu
Posté par Yao Kuramoto . Évalué à 2.
ah ben j'ai ma réponse :
"Intel a par ailleurs profité de Sandy Bridge pour étendre sa stratégie d’intégration d’un cœur graphique au sein de ces CPU. Ce dernier est désormais présent au sein du même die, et le nouveau HD Graphics offre des performances qui sont jusqu’à doublées par rapport à la génération précédente, désormais du niveau d’une carte graphique de type Radeon HD 5450 pour la version la plus rapide. C’est bien entendu insuffisant pour jouer, mais cela permet de se passer d’un GPU dans les autres cas, y compris pour un HTPC."
de http://www.hardware.fr/articles/imprimer/815/
[^] # Re: hd3000 dans le cpu
Posté par antistress (site web personnel) . Évalué à 2.
Sous Linux le Sandy Bridge se positionne bien mieux par rapport à la concurrence si on regarde les perfs avec les drivers libres AMD/Nvidia/Intel (cf tests sur Phoronix)
[^] # Re: hd3000 dans le cpu
Posté par claudex . Évalué à 2.
Comme ce n'est pas la même génération de puce, c'est difficile de comparer, peut-être que les résultats auraient été les même s'ils avaient garder l'ancien mode de fonctionnement tout en améliorant la puce graphique. (même si je n'y crois pas, je souligne que la comparaison est biaisée).
« 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: hd3000 dans le cpu
Posté par Anonyme . Évalué à 2.
Excusez mon ignorance, mais ça veut dire que peut importe la CM qu'on prend avec un SandyBridge, on n'a pas besoin d'y brancher une carte graphique (sauf un affichage plus puissant) ?
[^] # Re: hd3000 dans le cpu
Posté par Highlander . Évalué à 2.
Il me semble que le GPU intégré ne fonctionne que sur des carte-mères ayant les chipsets H67 et Z68, mais pas avec le chipset P67.
[^] # Re: hd3000 dans le cpu
Posté par antistress (site web personnel) . Évalué à 5.
Je ne suis expert sur la question, mais je peux te dire que certaines cartes mères exploitent la partie graphique du Sandy Bridge, d'autres non.
C'est assez confus chez Intel à ce niveau, on s'y perd facilement, il faut l'avouer :-/
Déjà tu peux filtrer pour ne garder que les cartes mères LGA 1155.
Ensuite tu as différent chipsets, mais pour exploiter la partie graphique il t'en faut un avec support FDI.
Donc si tu regardes ici https://secure.wikimedia.org/wikipedia/en/wiki/List_of_Intel_chipsets#Core_i_Series_chipsets en recoupant les deux critères (LGA 1155+FDI support), ça donne au choix : H61, H67, Z68 et B65 (Q67 et Q65 c'est pour les stations de travail il me semble)
Après je pense que c'est pas mal d'en prendre un qui gère le SATA 6 Gbit/s si tu dois prendre un SSD un jour, ce qui exclut le H61 et il reste alors les H67, Z68 et B65.
Ensuite si tu as des cartes PCI à réutiliser, il te reste alors seulement le B65.
En revanche, pour le RAID c'est H67 et Z68.
En revanche si tu veux overclocker, il faut un processeur avec la lettre K et un chipset Z68.
Voir aussi pour des tableaux récapitulatifs : http://motherboardnews.com/2011/04/07/comparison-of-intels-lga-1155-chipsets/
et pour le détail par chipset http://ark.intel.com/#desktopchipsets
[^] # Re: hd3000 dans le cpu
Posté par warwick . Évalué à 1.
Petite correction: Il y a un port PCI présent sur le modèle de CM DH67GD (pour lequel j'ai opte, puisqu'il dispose du firewire, nécessaire pour de l'audio sérieux sous Linux).
Il ne lui manque que le wifi et le bluetooth.
Je me suis fait plaisir avec un 2600K (je me fous du pseudo-overclocking, mais la différence de performance accrue de la vidéo sur la série K m’intéressait, pour être peinard et surtout ne voulant pas de carte graphique distincte), 16Go de RAM et un SSD Intel série 510 en 120G.
Un make -j9 de kernel vanilla prends à peu près 4 minutes (avec un .config ne contenant que les modules nécessaires). L’amorçage du noyau jusqu’à Gnome avec quelques applications démarrées prends 6 secondes. Ça boot tellement vite que je ne peux même pas voir les 8 Tux :(
[^] # Re: hd3000 dans le cpu
Posté par Anonyme . Évalué à 1.
Ce sont donc des Tux soufflés.
Merci pour vos retours :)
Sans vouloir abuser, tu/vous as/avez essayé Inkscape ou Blender avec ? Ou fait quelques benchmarks avec par exemple glxgears ?
[^] # Re: hd3000 dans le cpu
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
Vérifie juste la présence des sorties hdmi/dvi sur la carte mère avant l'achat, toutes n'en ont pas (lié au chipset).
J'ai ça depuis hier soir, et j'ai un bureau KDE4 fluide avec tous les effets activés pour l'occasion.
# À propos de SSE et AVX
Posté par jseb . Évalué à 7.
Plus précisément, le MMX opère sur des entiers, et le SSE sur des flottants. À l'origine, l'extension SSE était la réponse du berger à la bergère (en l’occurrence l'extension «3DNow!» de AMD).
Le SSE pouvait remplacer avantageusement le FPU, sauf pour la précision (64 bits pour le SSE et 80 bits pour le FPU). De même, l'architecture du FPU (l'accès à ses registres ne pouvait se faire que par une pile, et sans concurrence avec le CPU) ne facilitait pas l'optimisation.
Je me souviens encore avec émotion de ma compilation de xpdf, avec le support SSE2.
xpdf s'est mis à fonctionner environ 30% plus rapidement sur un pdf d'une lenteur extrème (un manuel rempli de photos). Et encore, je n'avais même pas recompilé la lib jpeg avant de faire ce premier essai.
Je n'ai pas besoin d'une grande précision arithmétique, ne mettant pas de fusées sur orbite. J'ai donc toujours été très satisfait des performances de SSE2 et suivants, par rapport au support FPU par défaut.
AVX est destiné à remplacer SSE, et semble déja prometteur.
Un test avec Blender 2.59 sur un Core i5-2400.
(avec ce bench: http://www.eofw.org/bench/ )
Version binaire générique: 9,73 secondes
Version compilée avec support AVX (GCC 4.6.1): 6,53 secondes.
Le gain est là, et bien là.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: À propos de SSE et AVX
Posté par Guillaume Knispel . Évalué à 3.
Concernant la précision en calcul FPU sur x86, elle est la plupart du temps concrètement limitée à 64-bits (lors des sauvegardes des registres en mémoire) de toute façon.
[^] # Re: À propos de SSE et AVX
Posté par antistress (site web personnel) . Évalué à 1.
En effet avec l'AVX Intel semble aller au bout de son idée cette fois.
Ça na pas toujours été le cas, on se souvient du MMX, excellent coup marketing mais mauvaise technologie : son utilisation rendait indisponible l'unité de calcul en virgule flottante !
Quand aux versions successives du SSE, des développeurs relativisent l'apport des ajouts successifs : les optimisations internes dans le traitement des SIMD peuvent s'avérer bien plus efficaces que l'ajout de nouvelles instructions (cf l'introduction du Super Shuffle) http://www.outsourcingi.com/articles_content.php?id=454&art=The%20Future%20of%20Linux%20with%20Intel%20Core%202%20%E2%80%9CPenryn%E2%80%9D%20and%20SSE4&cat=Hardware
De ce point de vue, AVX semble aller dans le bon sens.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Attention tout de même, Intel a volontairement sacrifié sa fpu x87, quand AMD propose une version avec 3 niveaux de pipelines. C'est particulièrement visible sur les pentium 4. Le x87 ne propose pas que des long double mais aussi des fonctions comme tan/sin/cos, etc... qui peuvent être plus rapide que leur version avec du code SSE surtout si la précision importe.
Cela a changé avec les core i car intel a doubler les ressources pour le SSE (datapath de 128 bits au lieu de 64).
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 5.
En pratique c'est faux. Ces instructions sont très couteuses en cycles. Une version soft de ces fonctions bien codée est souvent plus rapide que la version hardware des processeurs.
C'est particulièrement le cas depuis que la multiplication flottante est devenue rapide. À l'époque ou la multiplication prenait plusieurs dizaine de cycles ce n'était pas le cas, mais maintenant je ne pense pas qu'il reste des processeurs ou la version hardware soit plus rapide que la version software.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De mémoire, une fonction trigo prend de l'ordre d'une cinquantaine de cycles, dans le cas de fonction a résultat précis, il faut remplacer l'instruction spécifique par des tests pour aller dans un domaine restreint, puis des suite de MACC issue de fraction régulière (de mémoire?) ou de développement limité puis ensuite, une correction pour retourner dans le domaine d'origine.
Tout cela en moins de 50 cycles, avec des accès mémoire et des sauts. Cela me parait super chaud.
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 10.
Pour tous le message suivant, je prend comme exemple un processeur intel core i7. Sur ce processeur, une multiplication flotante prend 5 cycles mais il est possible de démarrer une nouvelle multiplication à chaque cycles avec un maximum de 3 multiplication en même temps. Pour les additions et soustraction c'est la même chose mais en 3 cycles.
Pour prendre un exemple que je connais bien : la fonction exponentielle. L'exemple est un peu biaisé mais j'y reviendrais à la fin. Son calcul avec les fonctions interne repose sur l'instruction f2xm1 qui prend 58 cycles.
Sont calcul en soft ce fait par une réduction de e^x vers 2^k * e^f avec f dans l'intervalle [-0.5,0.5] :
Si on rajoute la gestions des NaN et autres Inf, on arrive à un 47 cycles une fois bien tassé. Si on a besoin de la gestion des nombres dénormalisés, on rajoute 4 cycles au cas standard. (le cas dénormalisé prenant lui beaucoup plus de temps...)
On peut ce dire que l'économie est faible, mais ce qu'il faut voir c'est que l'instruction f2xm1 seule ne suffie pas à calculer l'exponentielle. L'exponentielle est calculée avec la formule e^x = 2^(x * log2(e)), il faut rajouter au final une audition, une soustraction et une multiplication ainsi que quelque petits détails et prendre en compte que f2xm1 bloque les port 0 1 et 5 de l'unitée de calcul et que donc on ne peut rien faire d'autre pendant 58 cycles. On arrive à 73 cycles auxquels il faut rajouter 3 cycles pour être sûr que tout ce passe bien avec les dénormalisés.
Au final la version soft est nettement gagnante. Principalement car la multiplication est très rapide et à un reciprocal throughput d'un seul cycle.
Par contre, cet exemple est biaisé : les deux fonction sin et cos sont globalement aussi rapide en hard qu'en soft mais ce sont les seules avec la fonction sincos qui calcule les deux en même temps car ce sont les seule ou la version hardware est vraiment très proche de la version software. Pour toutes les autre fonctions du même genre, il y a souvent une réduction à faire à l'aide de quelques instructions avant. Et cette réduction est nécessaire aussi bien en hard qu'en soft.
Mais la version soft conserve l'avantage de ne pas occuper tout les ports et donc de permettre de dispatcher quelques autres instruction en même temps si possible ainsi que d'être beaucoup plus portable que de l'assembleur.
Et juste pour terminer, l'instruction fsin ne prend un peu moins que 50 cycles que dans le cas ou tu veux une précision sur 32 bits. Pour une précision complète elle demande 100 cycles, il y a moyen de faire énormément de choses pendant ce temps la notament environs 30 multiplication s'il n'y a pas de dépendances trop fortes.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
As-tu fais des mesures ou est-ce juste une estimation pour la version soft ?
Dans ton calcul, tu ne parles pas du tout de la gestion des constantes que tu retrouves dans toute approximation polynomiale. Ces constantes doivent être chargé depuis quelques part et parfois, ce n'est vraiment pas efficace et surtout pas gratuits. 9 loads, cela peut prendre 1 ou 2 x9 cycles depuis le cache L1, et beaucoup plus sinon.
Il semble que la fonction f2xm1 soit vraiment une des fonctions x87 les plus lente.
Si j'ai bien compris la description x87, à l'origine ce genre de fpu, est fait à partir de l’algorithme cordic rapide uniquement si on ne dispose pas de multiplieur rapide. On pourrait penser que le microcode sache utiliser le multiplier disponible mais cela ne semble pas le cas.
Ensuite, il est peut-être possible de faire faire des travaux sse pendant que la fpu x87 tourne ?
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par Troy McClure (site web personnel) . Évalué à 2.
ici il y a des mesures: http://gruntthepeon.free.fr/ssemath/ , tu peux comparer sincosf (l'instruction asm x87) et cephes_sinf qui est juste une implementation en C de sinf, sur toutes les machines la version cephes est plus rapide et pourtant c'est du C pas particulierement optimisé
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 2.
Attention avec ce benchmark, il à deux problèmes.
Tout d'abord les calculs sont fais avec une précision de 32bits uniquement pour les versions soft là ou la FPU va faire les calculs au moins partiellement en 80bits. Pour l'exponentielle par exemple, l'appel à f2xm1 sera fais avec 80bits de précision.
Les résultats ne sont donc valable que si tu as besoin de peu de précisions. (dans ce cas tant pis pour la FPU, elle n'avait qu'a savoir faire le calcul en 32bits...)
Les bench sont réalisés sur de très gros vecteurs puisque l'objectif est de comparer avec des versions vectorielles, l'impact des accès mémoire n'est pas négligeable et les résultats sur des appels fréquents mais plus espacés peuvent être très différents.
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 7.
J'ai pris l'exemple de l'exponentielle car justement j'ai beaucoup bossé dessus et sur les différentes manières de l'approximer. Les valeurs en nombre de cycles que je donne sont les valeur réellement mesurées pour l'approximation software dans le cas ou les constantes sont dans le cache L1. Si les constantes ne sont que dans le cache L2, il y a un trou de 17 à 22 cycles en moyenne à rajouter.
Pour la version hardware, ce sont les valeurs théoriques maximum que l'on peut atteindre mais je n'ai pas trop de doute dessus. Le f2xm1 bloque vraiment les ports flottants donc il y a peu de difficultés à prédire la durée.
Pour ce qui est des loads, ils n'ont que peu d'impact lorsqu'ils se font depuis le cache L1. Le port de lecture est saturé sur le début du calcul mais il n'y a pas de cycles perdus, et il est disponible pendant l'étape finale pour charger les données des instructions qui suivent le calcul de l'exponentielle.
Si les constantes ne sont pas dans le cache L1, ça veux généralement dire que tu fais peu appel à ces fonctions et que donc une différence d'une vingtaine de cycles ne changera rien de manière globale.
Pour ce qui est de l'instruction f2xm1, c'est loin d'être la plus lente. Si on oublie fnsave et frstor qui sont un peu hors de propos mais qui culminent à plus de 150 cycles ; on trouve quand même parmi les instructions complexes :
Dans les fonctions complexes, il n'y a que fsqrt et fscale qui prennent moins (27 et 12 cycles respectivement). La fonction exponentielle est un peu particulière car la réduction est simple et peu se calculer très rapidement. Si on prend le calcul de tan() comme exemple, on peut être en dessous des 115 cycles en soft aussi, mais la réduction est plus complexe et donc l'exemple est moins facile à expliquer.
Ce qu'il faut bien voir c'est que d'un point de vu hardware, la FPU x87 ne fait que survivre comme elle peut et les instructions complexes sont elles bien mortes. Le seul intérêt qu'il reste au x87 c'est la précision sur 80bits, pour tout le reste il faut passer à SSE qui ne dispose pas d'instructions complexes et donc nécessite des implémentations hardware.
Les processeurs récents ont encore de très bon multiplieurs dans la FPU car ce sont les mêmes que pour le SSE mais pour les instructions complexes ça dépend vraiment des générations. Elle sont découpée en un très grand nombre de micro-instructions et leur efficacité varie beaucoup. L'idée c'est de les coder en ajoutant le moins possible de micro-instruction, donc suivant ce qui est disponibles dans le reste du processeur ça deviens très variable.
Par exemple, f2xm1 qui prend 58 cycles sur un core i7 ne prenait que 45 cycles sur un core 2 en 45nm. C'est l'avantage des versions soft, on connais leur comportement de manière beaucoup plus fiable.
Pour ce qui est de faire des calculs sur la FPU et le SSE en même temps je te le déconseille, les deux utilisent les mêmes ports pour leurs micro-instructions et les mêmes unités de calcul. Tu ne peux que perdre en performances de manière globale.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Est-ce que "des gens" essayent d'utiliser des expressions complètes avant de passer aux développements limités ou cela ne se fait que sur des fonctions de base ?
A près tout, il y aurait peu de différence de performance entre l'implémentation de e^x et une expression avec plusieurs e^x, le résultat de développement limité pourrait "fusionner", le problème reste la réduction de domaine.
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 2.
Tu as plein de méthode pour calculer toutes ces fonctions et la bonne méthode dépend de beaucoup de choses. En pratique, le gros problèmes c'est toujours la précision. Les différentes méthode ne sont généralement applicable de manière raisonnable que sur un intervalle de valeurs petit, il faut donc trouver le meilleur compromis entre :
Les développement limités ont plusieurs avantages : ont peu généralement obtenir la précision que l'on veux sur n'importe quel intervalle pas trop gros et avec un peu de bol le polynôme peu ce mettre sous une forme sympa pour faire plusieurs opérations en parallèle et profiter au maximum du processeur.
Mais le sujet est vaste et des livres entiers ont étés écris dessus...
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En fait, je suis étonné qu'il n'existe pas d'outil automatique pour faire se genre de travaux.
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 3.
Le gros problème c'est que pour trouver la manière la plus rapide de calculer une de ces fonctions il faut tenir compte à la fois de l'aspect mathématique et de l'aspect informatique.
J'ai vu un cas ou ajouter une division qui prend 40cycles permettait d'obtenir un code plus rapide car pendant que le processeur s'occupait de la division dans l'unité flottante il y avait suffisamment d'autres calculs à faire en parallèle. Au final ce code était presque trois fois plus rapide que la version plus classique avec la même précision car la réduction était triviale.
Il y a moyen de produire automatiquement différentes alternatives, mais il faut toujours regarder à la main comment chacune d'entre elles peut être implémentée pour choisir la meilleure. Quand j'ai bossé sur l'exponentielle par exemple, j'avais du code pour me produire différentes formes d'approximations sur les intervalles qui m'intéressait pour différentes précisions. Ensuite je regardait à la main comment je pouvais m'arranger pour organiser au mieux le calcul.
J'ai fais des version FPU et SSE2 à l'époque et elles utilisent des méthodes de calcul différentes. Je me penche en ce moment sur une version AVX et à priori ce sera encore différent.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le gros problème c'est que pour trouver la manière la plus rapide de calculer une de ces fonctions il faut tenir compte à la fois de l'aspect mathématique et de l'aspect informatique.
Je dirais que c'est un peu la raison d'être des compilateurs : tenir compte de la cible. Même si un travail manuel serait meilleur, il est infiniment plus long qu'une compilation.
Concernant la précision, comme la définis-tu ? En relatif uniquement ? Avec une petit touche d'absolue pour gérer autour de zéro ?
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 3.
C'est même pour cela que la libm est avant tout codée en C avec de très bonnes performances. Le passage à l'assembleur n'est fait que pour certaines architectures et que pour certaines fonctions. Réussir à faire mieux que le compilateur est même souvent très difficile.
Par contre, il n'y a pas de magie, le compilateur ne trouvera pas tout seul la bonne réduction et la bonne approximation. L'humain reste indispensable à ce niveau là. (pour l'instant en tout cas)
De manière générale et pour la libm, la précision est définie par le standard IEEE754. En gros ça veux dire que tu dois renvoyer un résultat identique à ce que donnerais le calcul exact puis arrondis de manière à être représentable.
La ou c'est chiant c'est qu'il y a différent mode d'arrondis...
Dans mon cas, l'optimisation ce justifiais car mon code passait près de 46% de son temps à calculer des exp() et des log(). Le truc c'est que je n'avais pas besoin de gérer les nombres démoralisés, un seul type de NaN, pas d'infinis en entrée et surtout les valeurs d'entrée ne pouvait couvrir qu'un intervalle plus réduit.
Donc dans ce cas là, même avec une précision complète, on gagne déjà beaucoup : presque un facteur x2 sur les deux fonctions.
Pour ce qui est de la précision, une partie du code avais besoin de la précision complète, c'est elle qui garde le code FPU avec ses 80bits et qui fait le calcul en long double. Par contre, une grosse partie du code travail sur des doubles mais peut tolérer environs 3bits d'erreurs. Cette portions utilise le code SSE2 avec un polynôme tronqué qui fournis juste ce dont le code à besoin et permet en plus de profiter du SIMD. Au final les exp() et log() ne représentent plus que 6% du temps de calcul.
Par contre, avant de jouer avec ces fonctions il faut bien faire attention et bien mettre des gros warning. Dans mon cas, si tu leur donnes des valeurs qu'elles n'attendent pas, elles te renvoie du bruit. Leur utilité est donc très liée à mon programme. Dans le cas général ou tu dois respecter le standard IEEE 754 tu n'auras jamais de tels gains. Une bonne fonction exp() à un gain non-négligeable par rapport à la version FPU pour le cas général, par contre, si l'entrée ou la sortie est un NaN ou un Inf, ce n'est souvent pas le cas.
Pour les nombre dénormalisé, c'est souvent kifkif car la FPU à une pénalité de près de 200 pour ces cas là elle aussi.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le problème des nombres IEEE754, c'est qu'il ne représente pas grand chose, ce n'est pas un anneau ou un groupe au sens mathématique du terme. L'associativité et autre égalité pratique ne marche plus.
Je comprend tout de même ta démarche.
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par beagf (site web personnel) . Évalué à 3.
C'est en effet un problème. Mais c'est ce que l'on a de mieux actuellement. L'avantage de IEEE 754 c'est que l'on dispose d'une norme précise qui offre de bonnes garanties et qui est implémentée en hard donc qui permet de faire des calculs rapide.
Le choix qui ont été fais dans la norme n'ont pas été fais de manière arbitraire mais pour permettre de réellement faire du calcul mathématique. Il existe des représentations qui ont de meilleur propriété d'un point de vue mathématique, mais le résultat est toujours le même : elles ne sont pas vraiment utilisables.
Garantir l'associativité par exemple entraine toujours de gros problèmes lors de l'analyse de la propagation d'erreurs.
Je rêve d'une représentation des réels qui soit un vrai corps commutatif avec les mêmes garantie que l'IEEE 754 mais c'est tout simplement impossible. Actuellement au moins, l'IEEE 754 reste le meilleur compromis. Il y a quelques principes à bien garder en tête, et pour les passage critique du code, il est relativement simple de calculer l'erreur maximale que l'on obtient.
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pour avoir travaillé avec des specs écrit par des matheux, ils écrivent en pensant réel avec un précision donnée.
Donc, le code d'algo est pensé avec des réels, un range et une précision. Pourquoi ne pas partir de cela, pour simplifier et pour ensuite aller vers le IEEE754 ?
Suite à la mise en sommeil du dev de Lisaac, je m'était demandé le boulot que cela pourrait représenter.
"La première sécurité est la liberté"
[^] # Re: À propos de SSE et AVX
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Une autre question, si on prend ta fonction e^x, j'imagine qu'elle est présente dans une fonction f(x).
Cette fonction, sur quel genre de donnée, est-elle exécuté ? Un gros vecteur de X ou un tableau à 2 dimension (image) ? Ou alors est-ce une fonction itérative ?
"La première sécurité est la liberté"
# .
Posté par CrEv (site web personnel) . Évalué à -1.
Nan mais vous trouvez pas que c'est un peu lourd comme solution ? Mettre le GPU dans le CPU ?
Parce que bon, Sandy kilos sur un pont, quand même...
hop hop ~~~> []
[^] # Re: .
Posté par MTux . Évalué à -2.
Malheureusement ces solutions tout en un ont incité les fabricants à proposer des produits hybrides, un GPU à leur sauce rajouté sur la carte mère (AMD ou Nvidia).
Je trouve ça stupide surtout quand celui-ci est minable et ne fait que provoquer des bugs sur l'OS sans réellement réellement apporter un gain de performances.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.