FLOAT EN HEXA (WIN32, ASM)

Signaler
Messages postés
402
Date d'inscription
mardi 1 mai 2001
Statut
Membre
Dernière intervention
15 août 2011
-
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/41170-float-en-hexa-win32-asm

BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
18
"Je laisse aussi de côté le fait que SSE n'est pas une plateforme stable (déjà abandonnée en 64bits)"

Ce n'est pas un "abandon" pour l'IA64 (Itanium), simplement que l'architecture est radicalement différente du x86. SSE est par contre bien présent en mode x64 et c'est même ainsi qu'on l'exploite au mieux.

En ce qui concerne cet "abandon", regarde ici:
http://www.silicon.fr/fr/news/2008/05/26/serveurs_hp_devance_ibm
2,27 millions de serveurs x86 vendus au 1er trimsetre 2008 rien que pour HP. Faudrait plutot parler du quasi abandon du IA64.
SSE est en très bonne santé et installé pour un bon bout de temps.
verdy_p
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Justement, c'est ce qui manque qui fait toute la différence: la totale non-gestion de la compatibilité (et aussi l'oubli de traitement des valeurs spéciales comme les NaN, infinis, et dénormaux).

Note: je n'ai fait aucune attaque contre les auteurs mentionnés ici dans mon message initial et je ne vois pas pourquoi on m'a ensuite répondu vertement. Mon commentaire était franchement gentil et n'avait rien à voir avec un "archarnement". Il était même plus sympatique que les autres commentaires postés par d'autres avant moi.

Cependant je critiquais directement une "solution" proposée qui consiste à remplacer une copie mémoire par une affectation simple: cela ne marche pas avec la précision native des flottants sur 80 bits (voire plus). Le SSE n'est pas non plus un modèle excellent en terme de précision des calculs, il vaut mieux le savoir: le SSE n'est PAS conforme IEEE, et la précision varie même d'un modèle de processeur à l'autre!

Je laisse aussi de côté le fait que SSE n'est pas une plateforme stable (déjà abandonnée en 64bits): nombre de registres indéfini, design assez mal fichu des instructions. Au vu de la durée de vie demandée au logiciel, c'est déjà une mauvaise solution de l'utiliser sans prévoir dès le début une solution de repli en cas d'absence.

Enfin l'utilité du SSE pour convertir des chaines isolées en nombres ou l'inverse me dépasse! Ce n'est pas là qu'un logiciel perd du temp, s'il y a des goulots d'étranglement à résoudre c'est bien ailleurs: les boucles de traitement de signal, les calculs complexes, etc...

Qui effectue des conversions de format dans des boucles de calcul massif ,sachant les problèmes de perte de précision que ce genre de conversion implique, ainsi que l'inefficacité totale des formats chaine pour effectuer des calculs ou transmettre des valeurs et résultats? Les chaines c'est pour les entrées-sorties et ce n'est pas le format utilisé sans les entrées-sortie qui étranglent les performance mais bien l'opération d'I/O elle-même (où de toute façon le processeur n'a rien d'autre à faire qu'à attendre ou passer la main à un autre thread: les différents jeux d'instructions SSE, SSE2, MMX, 3DNow!, etc... sont couteux pour les performances en multithreading car ils allongent le temps de commutation et augmente les ressources nécessaires pour que la commutation se passe correctement d'un thread à l'autre; leur support même par les constructeuurs ne dépasse guère 5 ans: le temps de développer le logiciel avec, ils sont déjà obsolètes avant même d'avoir été utilisés).
draluorg
Messages postés
625
Date d'inscription
vendredi 23 avril 2004
Statut
Membre
Dernière intervention
25 novembre 2010

verdy_p >
Bon je dis ca je dis rien, mais tu n'installeras pas Adobe CS3 si tu n'as pas un cpu gerant le jeu d'instructions SSE2.
Peut etre que dans ton domaine la portabilité est d'une importance capitale, mais dans bien des cas, elle n'est qu'un freins aux performances!

Je trouve ca bizarre que tu t'obstine avec de tels arguments! Donc pour toi les instructions SSE2 &co sont la juste pour garnir et ne doivent pas etre utilisees ?

Puis une autre chose, rien n'empeche si besoin est de fournir des routines "generique" en plus et de faire if (!instrunctions_specific) then loadLibrary(generic_routine.dll) else LoadLib(sse2lib.dll)

Que dire des cpu multicore ? doit on ne pas faire de prog otpimises pour les multi sous pretexte que beaucoup de personnes tournent encore en mono core ?

A ce rithme la je ressorts mon commodore moi!

++
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
18
Mais ouvre donc un site sur la philo du code générique, moi je m'en fous royalement. Je ne vais pas mettre tout le bureau au chomage parce qu'on n'a pas le même taf.
Dans tout autre domaine professionnel on voit des spécialités. Il n'y a qu'en informatique qu'on trouve pareil sectarisme, que soit pour l'OS ou le codage.