Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 31 à 53 sur 53
  1. #31
    Citation Envoyé par fefe Voir le message
    Ton exemple c/(a-b) peut aussi etre source de problemes meme si tu supportes les denormaux, a moins que ton hypothese de depart est que ni a,b,c ne soient denormaux.
    Si c est grand/petit et a-b petit/grand je peux avoir un overflow/underflow dans la division. Par contre mon dénominateur ne sera jamais nul (au pire NaN ou infini, mais pas 0).
    J'ai la flemme de faire la preuve et j'ai pas mon cours d'arith sur moi, mais avec une étude de cas plus ou moins fastidieuse ça doit se montrer.
    (en gros soit a et b sont éloignés et on montre facilement que a-b /= 0, soit ils sont proches et on applique le lemme de Sterbenz pour dire que l'opération est exacte)

    Je suis d'accord avec toi que ca arrivera moins souvent mais ca ne fait que repousser le probleme.
    Je suis contre cette démarche fataliste qui dit que puisqu'on n'arrivera jamais à calculer exactement, autant laisser tomber tout de suite et calculer n'importe comment.

    Meme si la plupart des processeurs ont toujours eu la possibilite de supporter la norme, il y en a plus d'un qui ne la supportait pas dans son mode d'operation par defaut, le plus connu etant l'alpha qui ne respectait pas la norme pour les overflow/NaN en hard jusqu'a EV6 (une option de compilation permettait de l'activer et le soft gerait ces cas la).
    Ça n'est pas très éloigné de comment fonctionnent les x86, on a juste du soft au lieu du microcode pour intercepter les exceptions...


    Je ne sais pas vraiment ce que font les GPUs mais je suppose que tu n'as pas l'option de trap et de gerer l'exception a la main en soft, d'ou pas mal de problemes.
    Tu as tout compris.
    Les traps ne sont pas une feature qui intéresse les programmeurs graphiques, et avec les SIMD de 16 ou 32 voies et les pipelines monstrueux qu'on a les perfs seraient vraiment désastreuses.


    PS: j'ai vu plus de problemes lies a la presence de denormaux que de problemes de DAZ/FTZ parmi les utilisateurs qui utilisaient le flottant sans comprendre. Certes le resultat avec les denormaux a des chances d'etre plus proche du resultat vise (mais c'est un peu comme utiliser double a la place de float en esperant avoir un meilleur resultat), mais ce n'est pas systematique, et on y arrive beaucoup plus lentement.
    Peut-être parce que DAZ et FTZ sont pas activés par défaut on a pas de problème avec?

    Certes, à partir du moment où on a des dénormaux qui apparaissent c'est que le code à un problème de stabilité numérique. Mais c'est pas pour autant l'auteur de compilateur doit se prendre pour un héro ou un donneur de leçons en massacrant volontairement le code qu'on lui donne. Ou alors à la limite en -O5.
    Sinon le débugger pourrait intercepter les underflows pour afficher des warnings dans sa console, comme ça le programmeur spammé verra que quelque chose cloche.

  2. #32
    Peut-être parce que DAZ et FTZ sont pas activés par défaut on a pas de problème avec?

    Sauf que beaucoup de monde a tendance a mettre fastmath pour que ca aille plus vite .


    Sinon le débugger pourrait intercepter les underflows pour afficher des warnings dans sa console, comme ça le programmeur spammé verra que quelque chose cloche.
    C'est interessant comme idee, je ne sais pas si quelqu'un a deja applique.

    PS: je ne suis pas vraiment fataliste, j'ai juste ete trop confronte a la realite...
    fefe - Dillon Y'Bon

  3. #33
    Question utilisateurs:

    Est-ce que les utilisateurs de calcul numériques sont en géneral sensibilisés aux problématiques de précisions et dénormaux?
    J'espère que oui, mais on ne sait jamais...

    En tous cas il est clair que le programmeur lambda n'y est pas sensibilisé (mais en général n'en a pas besoin).

    Ca ne me dérange pas qu'un programmeur de simulation d'IA pour un jeu ne se soucie pas de ça, mais je trouverais un peu dérangeant qu'un programmeur de simulation de criblage ne s'en soucie pas.

  4. #34
    ben je me souviens que le bouquin sur matlab commençait par 1-0.2-0.2-0.2-0.2-0.2

    juste pour montrer le problème...

    Et d'un td de calcul numérique de série entière qui se barait en couille a cause de la multplication des erreurs.
    Mes propos n'engagent personne, même pas moi.

  5. #35
    Dans a peu pres tous les cursus informatiques il y a en theorie au moins un TD qui en parle. Apres je ne sais pas si c'est le cas en pratique dans toutes les universites (a Paris XI je sais que c'est enseigne en 2nd cycle).
    fefe - Dillon Y'Bon

  6. #36
    j'ai pas un cursus informatique
    Mes propos n'engagent personne, même pas moi.

  7. #37
    En général j'ai l'impression que les gens sont plutôt bien au courant des problèmes que peuvent poser l'arithmétique flottante, mais beaucoup moins des solutions.

    Du coup il règne une sorte de peur superstitieuse mélée de fatalisme façon "c'est normal que ça marche pas, c'est du flottant".

    Faut dire que les histoires qu'on (les numériciens) raconte le soir à la veillée genre Ariane 5, la batterie de Patriot à Dhahran, l'indice de la bourse de Vancouver, le FDIV du Pentium, etc. sont pas pour rassurer les gens...

  8. #38
    Citation Envoyé par Møgluglu Voir le message
    En général j'ai l'impression que les gens sont plutôt bien au courant des problèmes que peuvent poser l'arithmétique flottante, mais beaucoup moins des solutions.

    Du coup il règne une sorte de peur superstitieuse mélée de fatalisme façon "c'est normal que ça marche pas, c'est du flottant".

    Faut dire que les histoires qu'on (les numériciens) raconte le soir à la veillée genre Ariane 5, la batterie de Patriot à Dhahran, l'indice de la bourse de Vancouver, le FDIV du Pentium, etc. sont pas pour rassurer les gens...
    Les gens qui ont peur a cause de ce genre d'évènements sont des abrutis...

    Un jour, j'ai vu un mec tombé à cause de son lacet, du coup, je prend plus que des velcro pour ne jamais tomber.
    Mes propos n'engagent personne, même pas moi.

  9. #39
    Léger déterrage de topic, parce que à l'occasion de la sortie de Cuda 2.0 beta, j'apprends qu'un prochain GPU (au hasard, GT-200?) supportera un FMA en double précision dans les 4 modes d'arrondi IEEE (avec le mode d'arrondi encodé dans l'instruction).

    Du coup, pour peu que ce GPU sorte avant Bulldozer et Haswell, Cuda deviendrait plus intéressant que les X86 pour la prog numérique : multiprécision, fonctions élémentaires, arithmétique d'intervalles, etc. (si on laisse la question des dénormaux de côté...)
    La question qui reste est de savoir si le MAD avec arrondi intermédiaire sera supporté aussi. Ça me parait vraisemblable, mais là je n'ai aucune info.

    Ah et pour les autres GPU, la double et le FMA sont émulés en soft (façon 8086 sans copro arithmétique, avec des perfs du même ordre).

    (puisqu'on parle de GeForce, j'aurai bien fait un mauvais jeu de mots avec double, fused multiply-add et la phase préférée de JohnClaude, mais j'ose pas )

  10. #40
    Un suport de FMA en double precision sans perte de bande passante en exec et les arrondis qui vont bien (en gros sans astuces utilisant 2 unites) donnerait effectivement des resultats assez impressionants sur du code numerique.
    Sachant que de passer de simple a double precision et de gerer l'arrondi correctement multiplie les besoin en hard par environs 2 on peut se demander si leur chip sera au choix enorme pour conserver les perfs en SP ou si la puissance de calcul en double ne sera pas divisee par 2+ par rapport a SP (comme sur les CPUs).
    En tout cas Nvidia prepare pas mal de trucs interressants pour les annees qui viennent .
    fefe - Dillon Y'Bon

  11. #41
    Citation Envoyé par fefe Voir le message
    Sachant que de passer de simple a double precision et de gerer l'arrondi correctement multiplie les besoin en hard par environs 2 on peut se demander si leur chip sera au choix enorme pour conserver les perfs en SP ou si la puissance de calcul en double ne sera pas divisee par 2+ par rapport a SP (comme sur les CPUs).
    À vrai dire la première possibilité ne m'était même pas venue à l'esprit. Pour moi sur un GPU moderne les perfs sont essentiellement limités par l'accès aux registres, pas par le calcul ni le décodage et scheduling d'instructions (8192 registres par SP, l'Itanium ressemble à un X86 à côté ).
    Garder les mêmes perfs en double qu'en simple voudrait dire multiplier la largeur de tous les datapaths par 2. Mais à ce moment-là, autant modifier les unités pour qu'elles puissent aussi traiter 2 simples à la place d'1 double pour un surcoût très faible (comme SSE). Le corps de métier de nVidia c'est toujours le rendering traditionnel, après tout...

    Il semblerait que ce soit aussi comme ça chez AMD-ATI (rapport 2 à 4 entre simple et double).

    Pour ce qui est des dénormaux, dans Cuda la version soft du FMA les supporte. Indice un peu léger pour conclure quoi que ce soit, certes...

    En tout cas Nvidia prepare pas mal de trucs interressants pour les annees qui viennent .
    Yep. Larrabee va avoir un sérieux concurrent...

  12. #42
    Aller je vais sortir mon ânerie : si on passe de simple à double précision on divise de toute façon mécaniquement les performances par deux, parce qu'un double fait 2x la taille. Donc même si on double la taille des registres (je suppose du SIMD), ou si on double la bande passante mémoire, on pourrait toujours faire 2x plus de calculs en simple précision.

    J'ai raté quoi, chuis un peu explosé là

  13. #43
    Citation Envoyé par newbie06 Voir le message
    Aller je vais sortir mon ânerie : si on passe de simple à double précision on divise de toute façon mécaniquement les performances par deux, parce qu'un double fait 2x la taille. Donc même si on double la taille des registres (je suppose du SIMD), ou si on double la bande passante mémoire, on pourrait toujours faire 2x plus de calculs en simple précision.

    J'ai raté quoi, chuis un peu explosé là
    Si tu executes une instruction par cycle, que ce soit en simple ou en double tu as les memes perfs. Dans un CPU x86 moderne le hard qui est consacre a la gestion des instructions est tres gros en regard de ce qui est proportionnel a la largeur du datapath. Dans un GPU ce qui domine c'est la largeur du datapath (les registres et les unites d'exec, le stockage des donnees ne prenant pas plus d'1/3 de la surface dans mes souvenirs, l'execution prenant plus). Dans un CPU tu n'as pas besoin d un doublement de la bande passante memoire tant que tes caches ont encore assez de bande passante.

    Donc proportionellement passer de simple a double a quad precision dans un cpu te coute quelques % de la surface du chip (doubler le debit d'instructions te coutera probablement 50+% de la surface), dans un GPU passer de simple a double te coutera pas loin d'un doublement du hardware, sauf si tu divises le debit d'instructions en DP par 2 ou la ca ne te coutera pas grand chose. Donc effectivement pour les GPUs je disais une banalite en supposant qu'ils diviseraient la bande passante SP par 2 pour faire du DP vu le peu de sens que ca a de faire autrement.

    Sinon pour Nvidia, il y a pas mal de rumeurs qu'ils developpent du x86, donc ca risque d'etre doublement interressant .
    fefe - Dillon Y'Bon

  14. #44
    Oui, ça fait un moment que ces rumeurs vont bon train, et c'est vrai que vu la direction prise par AMD et Intel, ce n'est pas comme s'ils avaient le choix à moyen terme.
    D'ailleurs ils commencent à bosser avec VIA, qui détient Centaur, ceux qui ont récemment sorti l'Isiah, qui a l'air pas mal du tout (plus intéressant à mes yeux que le Silverthorne en tout cas ).
    D'un autre côté ils font aussi le forcing sur l'embarqué avec leur APX2500 et ils ont pris le Cortex-A9

  15. #45
    Je crois que c'est le bon topic pour poster ça…

    Une faille de sécurité a été trouvée dans PHP :
    http://www.exploringbinary.com/php-h...85072011e-308/

    La raison : une boucle dans le code de conversion décimal->binaire qui ne converge pas quand les calculs sont effectués en précision double-étendue.
    Comme c'est le cas avec gcc qui par défaut utilise le x87 dans ce mode sur IA-32.

    Note amusante, le fichier source concerné écrit il y a 20 ans (http://svn.php.net/viewvc/php/php-sr...pathrev=307095) contient un commentaire au début disant en substance : "ne pas utiliser sur de la double-étendue". Mais c'est pas comme si les programmeurs savaient lire les commentaires (surtout dans du code comme ça).

  16. #46
    Si le programmeur original avait mis un assert au lieu d'un commentaire ca ne serait jamais arrive , c'est de sa faute !
    fefe - Dillon Y'Bon

  17. #47
    Je doute que les utilisateurs aient accepté que le code lance tous les tests de Gentleman-Malcolm et ceux de Paranoia pour vérifier que l'arithmétique machine a les bonnes propriétés à chaque fois qu'on fait un strtod.

    D'autant que ça ne prouve rien en soi. Rien ne garantit que l'optimiseur de gcc gardera les variables dans les registres ou pas sur 2 codes différents, voire sur le même code dans 2 contextes différents.

    Bref, faut brûler x87, stou.
    Dernière modification par Møgluglu ; 10/01/2011 à 19h19.

  18. #48
    Citation Envoyé par Møgluglu Voir le message
    Bref, faut brûler x87, stou.
    Je ne pense pas qu'il y ait grand monde qui soit en desaccord avec ca, le probleme est que si tu le brules, l'essentiel des programmes crasheront parce qu'ils l'utilisent toujours (au lieu d'utiliser SSE scalar).
    fefe - Dillon Y'Bon

  19. #49
    Deja, étape une, il faudrait déprécier toutes les ABI qui renvoient des flottants en ST(0).
    Et déjà, c'est baisé

    Enfin je dis ça mais le passage en amd64 va nous sauver. Un jour.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  20. #50
    La seule solution définitive propre est de brûler x87, mais ça ne veut pas dire qu'il n'y a rien d'autre à faire dans l'immédiat.

    Dans le cas de la faille de PHP, c'est causé par le fameux bug 323 de gcc, qui garde le mode de précision du x87 sur 80 bits.

    Ça ne serait pas arrivé sous Windows avec Visual Studio, ni sous certains BSD, qui fonctionnent en mode 64 bits.
    Oui, ça ne résout pas le problème de l'intervalle d'exposants étendu, mais c'est déjà nettement moins pire que le comportement de gcc.

  21. #51
    Dans la famille "déterminisme des calculs flottants", je suis tombé sur ce papier:
    Why do we need a floating-point arithmetic standard ?
    Il date un peu (1981: avant la première release de l'IEEE 754 en 1985), mais très interessant (du moins pour un newbie du flottant comme moi).
    Dam

  22. #52
    Kahan est celui qui a aide Intel a definir x87 si je me souviens bien . J'avais assiste a une de ses lectures lors d'une conf a Stanford il y a une dizaine d'annees et ca valait le coup (et je m'etais retrouve a lire exactement ce meme papier juste apres).
    fefe - Dillon Y'Bon

  23. #53
    Oui, pour peu qu'on accepte le ton condescendant, le fait que ça parte dans tous les sens, qu'il tire au jugé sur un peu tout le monde, et que ses papiers soient tapés à la machine à écrire jusqu'à ce que 20 ans après un de ses thésards ayant pitié de lui les lui reformatte en LaTeX, c'est intéressant.

    Mais oui, Kahan était la référence en arithmétique des ordinateurs dans les années 80 et 90.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •