J'ai oublie de repondre a cela: Aux etats-unis je pense que c'est encore plus limité à ce niveau-là, et les gangs sont beaucoup plus forts et dangereux. Posséder ce genre de matériel doit vite te mettre dans la liste des gens à voler/tabasser.
La nouvelle tendance est une organisation en Units separant different niveau de comportements/dangerosites. Suivant ton comportement, tu es reaffecte a une autre section, plus ou moins "dur". En gros, tu te comportes bien, on te bouge chez les plus gentils. Si tu te comportes mal, chez les mechants. Les gentils, eux, ont plus de droit en terme d'activites. Je parle pas basket ou 15h de plus dans la cours, mais bien d'acces a un atelier, formations voir meme travail.
Certains s'en foutent et resteront a jamais avec les sections ou se trouvent les gangs. Par contre, ceux qui veulent s'en sortir sont vachement motives, et ils savent que cela ne tient qu'a eux.
Interessant. Je voudrais juste preciser que tu melanges dans ton argumentaire Penal et Civil. La compensation/reparation aupres des victimes, c'est le role du Civil. Le payment vis a vis de la societe, incluant eventuellement une peine de reclusion criminelle pour les crimes, cela releve du Penal. Donc lister les peines possibles au Penal, et montrer que ca ne resoud pas le schmilblick pour les victimes, c'est evident, puisque ce n'est pas l'objectif.
Je suis d'accord avec toi sur le fond, meme si je rajouterais que c'est le risque de la peine qui devrait etre le facteur t'empechant de commettre une infraction, pas la punition effective qui en decoule. Car au fond, la priorite c'est l'abscence d'infraction, pas l'abscence de son iteration.
En effet comme tu le dis, on peut simuler un processeur. Donc on a une equivalence dans la theorie, sous reserve de resource illimitee, que l'on reste dans le calculable, et que le compilo soit capable de non pas optimiser le simulateur, mais le couple (simulateur, code). Mais avec tout ce que ton compilo est capable de faire, pourquoi pas...
Apres y avoir repense, tu as raison. Si je devais re-repondre, je dirais: Le raisonnement est correct, mais la situation initiale reste a prouver.
Un compilo travaille sur plusieurs niveaux. L'optimisation de code pour une plateforme donnee en est un mais pas le seul. Celles de haut-niveau sont generiques et ne dependent pas de la plateforme.
En terme d'optimisation de code, tu as deux approches compatibles:
- Faire moins
- Faire plus vite
Si une approche de haut niveau est capable d'eliminer du code, peux importe l'optmisation de la plateforme: ne rien faire est plus rapide que quelque chose d'optimise. Un exemple pratique: Une classe A avec appel de methode virtuelle. A chaque appel de la methode, le code genere doit d'abord determiner quelle methode doit etre effectivement appele. Si une analyse pousse prouve que seule une sous-classe B est utilisee, et que la methode correspondante est statique, alors tu peux supprimer la recherche: tu connais la methode au moment de la compilation.
Pour info, les compilos avec une sortie en C n'effectue pas une traduction code machine vers C. La traduction s'effectue depuis la representation intermediaire, avant l'optmisation pour la plateforme.
Si je ne me trompe pas, un systeme turing-complet est un systeme qui est capable de calculer tout ce que la machine de Turing peut calculer.
C'est different de Turing-equivalent, qui inclue en plus le fait qu'une machine de Turing soit capable de calculer ce que ton system peut calculer [L'autre sens, en gros].
Si Turing-complet n'implique pas Turing-equivalent au sens strict, il s'observe dans la pratique que les systemes Turing complet sont aussi Turing-equivalent.
Ca ne change pas ce que j'ai dit. Mais on peut preciser: Le compilateur peut faire tout ce qu'il veut tant que le resultat final correspond exactement a ce qui aurait ete obtenu si il n'avait pas fait de modifications. Tu le dis toi meme dans ta reponse: "
L'essentiel est bien qu'étant donné une entrée le calcul soit le même que celui spécifié par le langage".
Je parlais de l'expression du resultat final: Si je ne peux pas decrire ce que je veux exactement, par exemple je desire obtenir un resultat satisfaisant certaintes contraintes que le langage ne me permet pas d'exprimer. Je me trouve donc dans l'obligation d'ajouter certaines contraintes de tel sorte que le resultat soit satisfaisant, mais avec un cout supplementaire de calcul.
Genre un compilateur qui est capable d'effectuer des optimisations poussees en terme d'analyse inter-procedurales mais qui n'a pas de backend pour ta plateforme?
Ou que le resultat reinjecte dans GCC, avec moins d'ambiguite permet a GCC de rajouter un couche d'optimisation?
Raisonnement correct sur des bases fausses: Tu sous entends que tu es capable d'exprimer avec chacun des langages exactement ce que tu veux faire et rien de plus.
Quelque soit le compilateur, il se doit de retranscrire ce que tu as exprime en utilisant un langage. Mais parfois le langage manque de nuance dans un cas precis et tu lui dit plus que ce que tu penses, volontairement ou pas.
Un algorithme ecrit sur papier permet de mieux expliquer ce que l'algorithmicien veut faire, ce qui donne suffisement d'information au developeur pour ecrire le meilleur code possible, incluant le choix des des structures de donnees.
Pour avoir travaille pendant plus de 5 ans dans le domaine de l'optimisation de code, mon experiece m'a montre que meme un algorithme ecrit dans un language de haut niveau ne retranscrit pas necessairement exactement ce que l'algorithme etait cense faire. La retranscription en code inclue parfois de devoir utiliser des fonctions de bases du language qui ont parfois beaucoup trop de semantique associe et de ce fait limite les optimisations possibles.
Idem pour la documentation du choix de l'implementation. On arrive a determiner par les commentaires ce que le developeur a voulu faire, mais on ne sait rien sur ce qu'il n'a pas fait: Quels etaient les autres solutions envisagees et pourquoi ont-elles ete ecartees? Ca permet de ne pas forcement se retapper tout le boulot de verification, ou meme de se rendre compte que le developeur a l'origine n'a pas tenu compte de quelque chose.
La recherche est internationale, mais le context local se ressent dans l'ecriture des articles de recherche. Je n'ai pas pour habiture de lire les auteurs d'un papier avant de lire le contenu. Cependant, il m'arrive en lisant le contenu de dire "tient ca c'est francais" et immanquablement, et regardant l'origine des auteurs (le centre de recherche ou universite, pas l'origine de l'auteur en lui-meme) je me surprend en etant dans le vrai.
Un mot clef qui est souvent discriminateur: "meta". Si "meta" est utilise plus d'une fois dans le resume ou l'introduction de l'article, c'est imparable.... C'est francais. [l'alternative "abstraction" semblerai etre adopte par les autres]. Je suggererai meme a quelqu'un de faire une these sur l'identification de mot-clefs et leur association avec l'origine de l'article...
Après si je trouve une fille ici, je sens que ça va encore diminuer ma motivation.
Ce peut avoir un effet contraire. Avant j'etais 50/50 sur rester ou revenir en France. Lorsque j'ai trouve "une fille ici", je pensais que ca diminuerai ma motivation pour revenir. Neni! Elle veut venir en France....
Ton post est assez representatif de ce que l'on peut lire sur ce thread...
patrick_g parle ici de la forme et n'essaye pas d'etailler le fond de la discussion.
Tout comme le flame war qui a lieu et dont la pluspart des argumentations est basee sur des elements exterieurs a ceux fournis par RMS dans son mail initial.
On remarque effectivement qu'il y a une difference entre ce qu'il a dit dans son interview et ce qu'il ecrit dans son mail. Il eut ete plus sain d'annoncer qu'il s'agissait d'une correction de sa boulette, mais il ne l'a pas fait. Ca faute. Mais cela n'empechait pas ceux qui ont repondus de lire ce qu'il avait a dire. Comme il le dit plus tard dans une des reponses, chacun est libre d'adherer ou non a sa vision. De meme cela ne l'a pas empeche de reconnaitre la contribution d'OpenBSD au libre.
Je viens de me retaper la doc...
Donc en fait y a 2 autres cas qui sont lies a l'implementation de frcpa et frcsqrta, qui fournissent une approximation de la fonction inverse et racine:
- La definition de l'architecture garantie que ces deux instructions retournent une valeur approchee dont l'erreur maximale est fixee.
- Si la valeur est exacte un bit est mis a 1 pour signaler qu'il n'y a pas lieu d'affiner
- Si l'implementation (en gros une micro-architecture) ne peut pas fournir une valeur approchee satisfaisant l'erreur max, alors le proc doit faire un "Software Assist Fault" qui delegue a une implementation logicielle la tache de calculer la valeur reelle (ce qui mettre le but de precision a 1).
J'ai pas encore vu (mais j'ai pu le louper) d'implementations de l'Itanium qui ai eu besoin de demander assistance pour ces deux instructions.
Pour ce qui est des arrondis un peu assouplie (ou parfois plus stricte), c'est une affaire d'implementation logicielle des fonctions, pas du processeur.
A propos des arrondis et de la vitesse:
Cela depend. Pour des operations elementaires genre addition, multiplication et al, cela ne devrait pas influencer.
La ou ca devient un peu plus tordu c'est pour les fonctions trigonometriques: Comme certains resultats doivent arrondis car la precision d'un flottant, simple ou double ne suffit pas a stocker la valeur exacte, le resultat est arrondi. Cependant: Le resultat arrondi doit etre le meme que si tu arrondissais la valeur exacte de la meme facon.
Si tu es capable de faire une operation dans un format avec une plus grande precision, et que l'implementation de ta fonction est capable de garantir un resultat interne avec une assez bonne approximation, alors tu sais que quelque soit la regle d'arrondissement utilise pour stocker ta valeur arrondie, tu es coherent avec l'arrondissement du resultat reel.
Si ton implementation arrive a cette precision, alors la regle d'arrondissement n'influe pas la vitesse. Par contre, si tu ne peux pas, alors tu peux avoir a implementer differentes implementations pour chaque cas, pas toujours tous de la meme vitesse.
Dans la pratique, choisit la regle d'arrondissement qui convient a ce que tu cherches a calculer, pas pour des questions de vitesse d'execution.
En général, ces modes sont taxés de mal calculer.
Ils calculent tres bien avec les regles etablies. C'est juste que ces regles ne correspondent pas a IEEE. Donc pour etre plus precis:
En general, ces modes sont taxes de ne pas calculer comme IEEE le definit.
Si j'ai bien compris, il ne détecte pas les NaN dans le pipelines flottant pour éviter de gérer des interruptions en plein milieu.
Il y a deux modes "Fast": Y en a 1 c'est pour le processeur, l'autre c'est le compilateur.
Pour le processeur, c'est le "Flush to zero": Considere un nombre denormalise comme etant 0 et ne vient pas faire une exception logicielle pour deleguer le calcul a une implementation logicielle.
Pour le compilateur, c'est tout une suite d'optimisations qui ne sont pas valables par rapport a la norme mais dont beaucoup de programmes se foutent: Propagation de constantes, simplification d'operations, combination d'operations...
Oui, il faut utiliser -fltconsistency
Ca a un avantage dans le sens ou cela suit strictement la norme.
Dans le cas ci-dessus, c'est plus precis.
L'inconvenient c'est que parfois c'est moins precis aussi. Par exemple sur Itanium, a*b+c sera desormait encode avec une multiplication et une addition separee, plutot qu'avec un fma (fused multiply and add). Or comme il n'y a que fma de disponible, on se retrouve avec:
temp <- a*b + 0
res <- temp*1+c
au lieu de:
res <- a*b + c
La difference c'est qu'il y a potentiellement deux erreures d'arrondis dans le premier cas, au lieu d'une seule dans le second.
Maintenant tu as tout a fait raison: Ne confonds pas la norme et la toutouille des compilos.
Le compilo fait ce qu'on lui demande. Il faut lui dire ce que l'on attend de lui.
Mais tout n'est pas bon a jeter dans la toutouille d'un compilo, et on est parfois bien content que le compilo n'applique pas la norme dans sa version stricte.... Sinon adieu le multithreading.
Imagine que a soit une variable qui est accessible par plusieurs thread et que ton code utilises par exemple un semaphore.
Maintenant tu as la sequence:
c=e+f
g=h+i
Tu n'utilises pas a. Donc pas de pb. Oui, parce que les compilos sont gentils et ils ont surtout autre chose a faire que de nous embeter avec la lecture strict de la norme.
Parce que d'apres la norme, il est tout a fait correcte pour un compilo de generer la sequence suivante:
j=a
c=e+f
g=h+i
a=j
La sequence etant equivalente a la precedente, c'est valable. Tu vois le drame? Ben des fois Gcc fait des trucs bizarre dans ce genre. Linus c'est un peu fache.
C'etait juste pour ouvrir un peu le debat entre l'adequation d'un compilateur a une norme. Meme si les deux cas sont differents.
Dans ce cas, la spec C autorise tout compilateur a faire ce qu'il veut tant que le resultat est similaire a ce qui aurait ete obtenu en executant la version fournie par le code. Si une optimization existe et prouve que, en fonction de contraintes decouvertes lors de la compilation a+b-a est bien egal a b, alors le compilateur ne viole rien.
apparement ma reponse est dans la nature quelque part.
Donc je recommence: Pour la mise au point du calcul, j'imagine pas à l'utilisation ? Sinon, je ne vois pas l'interet de faire 2x ce calcul.
Je parlais bien de l'implementation. et je n'ai pas dit "refaire" le calcul mais "affiner".
Pour illustration, prenons un exemple concret: l'implementation de la fonction inverse en double precision sur une machine n'implementant pas la division directement. Pour info le calcul de a/b se fait en calculant 1/b puis en effectuant la multiplication avec a. Donc 1/b n'est pas la simple division de 1 par b.
Imaginons que tu saches calculer 1/b avec une faible precision. On dira que c'est y.
On note que la fonction f(x)=1/x - b a une racine pour x=1/b
En utilisant Newton-Ramson pour trouver la racine de f, on obtient la serie:
x_{n+1} = x_n(2-b*x_n)
Cette serie converge vers 1/b, ce que l'on cherche.
La convergence dans notre cas est quadratic, et le nombre d'etapes necessaire pour obtenir un resultat avec une prevision inferieure a une erreur donnee depend de la difference entre x_0 et 1/b.
A noter que cette serie n'utilise que des multiplications et des additions/soustractions.
Plus x_0 est proche de 1/b, moins d'etapes sont necessaires pour obtenir 1/b avec une precision voulue.
Dans beaucoup de CPU, la fonction inverse est implementee de cette facon, le CPU ne fournissant qu'une valeur approchee de la division...
Idem pour la racine carree.
C'est la meme methodologie utilisee pour la methode hybride simple et double precision:
- La serie est etablie sur papier et l'etude de la convergence de l'erreur etablit le nombre maximal d'iteration a effectuer pour obtenir un resultat correct en double precision pour un x_0 initial avec une precision inferieure ou egale a ce que l'on aurait au pire avec une implementation en simple precision. Evidement, on tient compte du fait que la multiplication et addition sont arrondies.
- Le calcul en precision simple etabli x_0 afin d'avoir une valeur approchee dont on majore l'erreur.
- On applique les n iterations necessaire
C'est effectivement plus complexe a etablir que de tout faire en double, mais ca peut avoir un gain enorme dans certains cas.
C'est encore la supériorité de la fpu x87 par rapport à SSE.
Tout depend de la methode d'evaluation de ce qui est meilleur a un autre. Cependant:
- En terme de transistor, n'implementer que des multiplications et addition, c'est moins couteux.
- De meme, si tu as besoin d'une precision plus fine que simple mais pas autant que double, tu y gagnes.
- Si quelqu'un trouves une meilleur implementation, ben c'est logiciel. Idem pour les bugs (le bug du Pentium sur la FP etant une mauvaise implementation de la fonction "approchee" de 1/x).
- Si pour un calcul unique c'est pas superieur a une fonction hardware, le fait que la multiplication et l'addition peut etre implemente dans un micropipeline, appliquer la meme fonction sur plusieures valeurs peut etre plus rapide que l'application sequentielle de cette operation sur chacune des valeures.
Cela revient à une étude d'interval, non ?
Oui mais on verifie deja dans les cas dont on sait que les sous operations de la fonction ont des discontinuites avant de se prendre la tete a verifier quelque chose dont on est pas sur que ce soit verifiable.
J'ai bon ?
Oui, mais je rajouterais les etapes initiales:
- Je definis quels sont mes besoins en terme de precision.
- Je verifie que quelqu'un l'a pas deja fait, parce que une prise de tete enorme s'annonce
A la fin:
- Je cree une doc avec mes formules mathematiques comme ca cela servira a quelqu'un d'autre. Les capacites de formatage etant limite dans un code source pour prouver mon erreur, faire ca dans un fichier a part. Genre avec LaTeX.
En général c'est double précision pour tout le monde
Une nouvelle tendance pour les processeurs ou il y a une difference en terme de temps de calcul entre precision simple et precision double:
Effectuer une premiere estimation en precision simple, puis affiner en precision double.
es 80 bits du fpu ont du plomb dans l'aile puisque sur x86_64, tous les calculs se font en SSE2, cad en 64 bits maxi.
Au dela de cette demonstration douteuse:
IEEE precise non seulement un format de stockage de nombre flottans (simple, double), mais aussi une precision sur un certain nombre d'operations, incluant evidement multiplication, division, racine carree, mais aussi certaines fonctions comme les fonctions trigonometriques.
Comme les processeurs ne supportent generalement pas ces dernieres (et encore parfois meme pas la division), le resultat s'obtient par une serie de calcul (rappelez vous les developements limites, lagrange, polynomes de tchebychev....). Afin d'obtenir la precision specifiee par IEEE, il est necessaire d'utiliser une precision plus grande pour les calculs intermediaires. Ceci est le cas jusqu'au jours quelqu'un prouve qu'une telle precision n'est pas necessaire.
La racine carree et la division est generalement prouvee en etudiant la valeur maximale de l'erreur. Mathematiquement, on sait prouver pour la totalite des valeurs sauf certains cas limites. Ces cas limites sont verifies experimentalement.
Pour les autres, c'est plus du "Jusqu'a ce jour, en tenant compte des cas extremes identifies theoriquements, nous avons obtenu une erreur maximale de x. Il n'est pas impossible que l'on en ai manque dans la liste".
Il existe des possiblites ou on peut utiliser des valeurs avec moins de precision pour les calculs intermediare, mais cela necessite plus d'operations, et a la fin cela ne vaut pas le coup.
Dans le poste original: Comment s'écrit un code ? Par essais erreurs ? On doit évaluer "à la main" les fuites de précision et écrire l'algorithme en conséquence ?
Tout a fait. Une etude de l'erreur est effectuee. Mais auparavant, on effectue une etude de stabilite: quel est la variation du resultat si l'on ajoute sur l'une des donnees en entree une petite valeur (epsilon).
J'imagine que c'est la démarche des codes scientifiques pour éviter d'utiliser des nombres étendus plus lent.
Reussir a prouver l'implementation de son calcul, c'est deja pas mal. On repasse generalement plus tard pour reduire la precision.
[^] # Re: coupable
Posté par mdlh . En réponse au journal Hans Reiser déclaré coupable. Évalué à 1.
Aux etats-unis je pense que c'est encore plus limité à ce niveau-là, et les gangs sont beaucoup plus forts et dangereux. Posséder ce genre de matériel doit vite te mettre dans la liste des gens à voler/tabasser.
La nouvelle tendance est une organisation en Units separant different niveau de comportements/dangerosites. Suivant ton comportement, tu es reaffecte a une autre section, plus ou moins "dur". En gros, tu te comportes bien, on te bouge chez les plus gentils. Si tu te comportes mal, chez les mechants. Les gentils, eux, ont plus de droit en terme d'activites. Je parle pas basket ou 15h de plus dans la cours, mais bien d'acces a un atelier, formations voir meme travail.
Certains s'en foutent et resteront a jamais avec les sections ou se trouvent les gangs. Par contre, ceux qui veulent s'en sortir sont vachement motives, et ils savent que cela ne tient qu'a eux.
[^] # Re: coupable
Posté par mdlh . En réponse au journal Hans Reiser déclaré coupable. Évalué à 1.
[^] # Re: coupable
Posté par mdlh . En réponse au journal Hans Reiser déclaré coupable. Évalué à 2.
[^] # Re: coupable
Posté par mdlh . En réponse au journal Hans Reiser déclaré coupable. Évalué à 2.
L'emprisonnement est une peine pour une faute que tu as commises. Pas une therapie ou un moyen pour t'empecher de le refaire.
Maintenant, tu as le droit de ne pas etre d'accord, mais la distinction explique peut-etre ton etonnement.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 1.
En effet comme tu le dis, on peut simuler un processeur. Donc on a une equivalence dans la theorie, sous reserve de resource illimitee, que l'on reste dans le calculable, et que le compilo soit capable de non pas optimiser le simulateur, mais le couple (simulateur, code). Mais avec tout ce que ton compilo est capable de faire, pourquoi pas...
Apres y avoir repense, tu as raison. Si je devais re-repondre, je dirais: Le raisonnement est correct, mais la situation initiale reste a prouver.
[^] # Re: Hum
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
En terme d'optimisation de code, tu as deux approches compatibles:
- Faire moins
- Faire plus vite
Si une approche de haut niveau est capable d'eliminer du code, peux importe l'optmisation de la plateforme: ne rien faire est plus rapide que quelque chose d'optimise. Un exemple pratique: Une classe A avec appel de methode virtuelle. A chaque appel de la methode, le code genere doit d'abord determiner quelle methode doit etre effectivement appele. Si une analyse pousse prouve que seule une sous-classe B est utilisee, et que la methode correspondante est statique, alors tu peux supprimer la recherche: tu connais la methode au moment de la compilation.
Pour info, les compilos avec une sortie en C n'effectue pas une traduction code machine vers C. La traduction s'effectue depuis la representation intermediaire, avant l'optmisation pour la plateforme.
[^] # Re: Hum
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 1.
[^] # Re: Hum
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 0.
C'est different de Turing-equivalent, qui inclue en plus le fait qu'une machine de Turing soit capable de calculer ce que ton system peut calculer [L'autre sens, en gros].
Si Turing-complet n'implique pas Turing-equivalent au sens strict, il s'observe dans la pratique que les systemes Turing complet sont aussi Turing-equivalent.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 0.
L'essentiel est bien qu'étant donné une entrée le calcul soit le même que celui spécifié par le langage".
Je parlais de l'expression du resultat final: Si je ne peux pas decrire ce que je veux exactement, par exemple je desire obtenir un resultat satisfaisant certaintes contraintes que le langage ne me permet pas d'exprimer. Je me trouve donc dans l'obligation d'ajouter certaines contraintes de tel sorte que le resultat soit satisfaisant, mais avec un cout supplementaire de calcul.
[^] # Re: Hum
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
Ou que le resultat reinjecte dans GCC, avec moins d'ambiguite permet a GCC de rajouter un couche d'optimisation?
Hum.... llvm avec le backend cbe.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 1.
Quelque soit le compilateur, il se doit de retranscrire ce que tu as exprime en utilisant un langage. Mais parfois le langage manque de nuance dans un cas precis et tu lui dit plus que ce que tu penses, volontairement ou pas.
[^] # Re: Tout mauvais...
Posté par mdlh . En réponse au journal Lisaac plus rapide que le C !. Évalué à 5.
Un algorithme ecrit sur papier permet de mieux expliquer ce que l'algorithmicien veut faire, ce qui donne suffisement d'information au developeur pour ecrire le meilleur code possible, incluant le choix des des structures de donnees.
Pour avoir travaille pendant plus de 5 ans dans le domaine de l'optimisation de code, mon experiece m'a montre que meme un algorithme ecrit dans un language de haut niveau ne retranscrit pas necessairement exactement ce que l'algorithme etait cense faire. La retranscription en code inclue parfois de devoir utiliser des fonctions de bases du language qui ont parfois beaucoup trop de semantique associe et de ce fait limite les optimisations possibles.
Idem pour la documentation du choix de l'implementation. On arrive a determiner par les commentaires ce que le developeur a voulu faire, mais on ne sait rien sur ce qu'il n'a pas fait: Quels etaient les autres solutions envisagees et pourquoi ont-elles ete ecartees? Ca permet de ne pas forcement se retapper tout le boulot de verification, ou meme de se rendre compte que le developeur a l'origine n'a pas tenu compte de quelque chose.
[^] # Re: Bonne idée ?
Posté par mdlh . En réponse au journal Bientôt du pingouin dans l'hémicycle ?. Évalué à 3.
[^] # Re: Le libre c'est aussi...
Posté par mdlh . En réponse à la dépêche Prix Turing 2007 pour la vérification de modèles. Évalué à 2.
[^] # Re: Et après ça ..
Posté par mdlh . En réponse à la dépêche Prix Turing 2007 pour la vérification de modèles. Évalué à 3.
Un mot clef qui est souvent discriminateur: "meta". Si "meta" est utilise plus d'une fois dans le resume ou l'introduction de l'article, c'est imparable.... C'est francais. [l'alternative "abstraction" semblerai etre adopte par les autres]. Je suggererai meme a quelqu'un de faire une these sur l'identification de mot-clefs et leur association avec l'origine de l'article...
[^] # Re: Et après ça ..
Posté par mdlh . En réponse à la dépêche Prix Turing 2007 pour la vérification de modèles. Évalué à 5.
Ce peut avoir un effet contraire. Avant j'etais 50/50 sur rester ou revenir en France. Lorsque j'ai trouve "une fille ici", je pensais que ca diminuerai ma motivation pour revenir. Neni! Elle veut venir en France....
[^] # Re: Enooorme !
Posté par mdlh . En réponse au journal La Flame War de l'année ?. Évalué à 1.
patrick_g parle ici de la forme et n'essaye pas d'etailler le fond de la discussion.
Tout comme le flame war qui a lieu et dont la pluspart des argumentations est basee sur des elements exterieurs a ceux fournis par RMS dans son mail initial.
On remarque effectivement qu'il y a une difference entre ce qu'il a dit dans son interview et ce qu'il ecrit dans son mail. Il eut ete plus sain d'annoncer qu'il s'agissait d'une correction de sa boulette, mais il ne l'a pas fait. Ca faute. Mais cela n'empechait pas ceux qui ont repondus de lire ce qu'il avait a dire. Comme il le dit plus tard dans une des reponses, chacun est libre d'adherer ou non a sa vision. De meme cela ne l'a pas empeche de reconnaitre la contribution d'OpenBSD au libre.
[^] # Re: Ecrire du code avec des flottants
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Donc en fait y a 2 autres cas qui sont lies a l'implementation de frcpa et frcsqrta, qui fournissent une approximation de la fonction inverse et racine:
- La definition de l'architecture garantie que ces deux instructions retournent une valeur approchee dont l'erreur maximale est fixee.
- Si la valeur est exacte un bit est mis a 1 pour signaler qu'il n'y a pas lieu d'affiner
- Si l'implementation (en gros une micro-architecture) ne peut pas fournir une valeur approchee satisfaisant l'erreur max, alors le proc doit faire un "Software Assist Fault" qui delegue a une implementation logicielle la tache de calculer la valeur reelle (ce qui mettre le but de precision a 1).
J'ai pas encore vu (mais j'ai pu le louper) d'implementations de l'Itanium qui ai eu besoin de demander assistance pour ces deux instructions.
Pour ce qui est des arrondis un peu assouplie (ou parfois plus stricte), c'est une affaire d'implementation logicielle des fonctions, pas du processeur.
[^] # Re: Ecrire du code avec des flottants
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 1.
Cela depend. Pour des operations elementaires genre addition, multiplication et al, cela ne devrait pas influencer.
La ou ca devient un peu plus tordu c'est pour les fonctions trigonometriques: Comme certains resultats doivent arrondis car la precision d'un flottant, simple ou double ne suffit pas a stocker la valeur exacte, le resultat est arrondi. Cependant: Le resultat arrondi doit etre le meme que si tu arrondissais la valeur exacte de la meme facon.
Si tu es capable de faire une operation dans un format avec une plus grande precision, et que l'implementation de ta fonction est capable de garantir un resultat interne avec une assez bonne approximation, alors tu sais que quelque soit la regle d'arrondissement utilise pour stocker ta valeur arrondie, tu es coherent avec l'arrondissement du resultat reel.
Si ton implementation arrive a cette precision, alors la regle d'arrondissement n'influe pas la vitesse. Par contre, si tu ne peux pas, alors tu peux avoir a implementer differentes implementations pour chaque cas, pas toujours tous de la meme vitesse.
Dans la pratique, choisit la regle d'arrondissement qui convient a ce que tu cherches a calculer, pas pour des questions de vitesse d'execution.
En général, ces modes sont taxés de mal calculer.
Ils calculent tres bien avec les regles etablies. C'est juste que ces regles ne correspondent pas a IEEE. Donc pour etre plus precis:
En general, ces modes sont taxes de ne pas calculer comme IEEE le definit.
Si j'ai bien compris, il ne détecte pas les NaN dans le pipelines flottant pour éviter de gérer des interruptions en plein milieu.
Il y a deux modes "Fast": Y en a 1 c'est pour le processeur, l'autre c'est le compilateur.
Pour le processeur, c'est le "Flush to zero": Considere un nombre denormalise comme etant 0 et ne vient pas faire une exception logicielle pour deleguer le calcul a une implementation logicielle.
Pour le compilateur, c'est tout une suite d'optimisations qui ne sont pas valables par rapport a la norme mais dont beaucoup de programmes se foutent: Propagation de constantes, simplification d'operations, combination d'operations...
[^] # Re: Quelques infos
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Ca a un avantage dans le sens ou cela suit strictement la norme.
Dans le cas ci-dessus, c'est plus precis.
L'inconvenient c'est que parfois c'est moins precis aussi. Par exemple sur Itanium, a*b+c sera desormait encode avec une multiplication et une addition separee, plutot qu'avec un fma (fused multiply and add). Or comme il n'y a que fma de disponible, on se retrouve avec:
temp <- a*b + 0
res <- temp*1+c
au lieu de:
res <- a*b + c
La difference c'est qu'il y a potentiellement deux erreures d'arrondis dans le premier cas, au lieu d'une seule dans le second.
Maintenant tu as tout a fait raison:
Ne confonds pas la norme et la toutouille des compilos.
Le compilo fait ce qu'on lui demande. Il faut lui dire ce que l'on attend de lui.
Mais tout n'est pas bon a jeter dans la toutouille d'un compilo, et on est parfois bien content que le compilo n'applique pas la norme dans sa version stricte.... Sinon adieu le multithreading.
Imagine que a soit une variable qui est accessible par plusieurs thread et que ton code utilises par exemple un semaphore.
Maintenant tu as la sequence:
c=e+f
g=h+i
Tu n'utilises pas a. Donc pas de pb. Oui, parce que les compilos sont gentils et ils ont surtout autre chose a faire que de nous embeter avec la lecture strict de la norme.
Parce que d'apres la norme, il est tout a fait correcte pour un compilo de generer la sequence suivante:
j=a
c=e+f
g=h+i
a=j
La sequence etant equivalente a la precedente, c'est valable. Tu vois le drame? Ben des fois Gcc fait des trucs bizarre dans ce genre. Linus c'est un peu fache.
C'etait juste pour ouvrir un peu le debat entre l'adequation d'un compilateur a une norme. Meme si les deux cas sont differents.
[^] # Re: Quelques infos
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Par contre bon courage.
[^] # Re: plop again
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 4.
Donc je recommence:
Pour la mise au point du calcul, j'imagine pas à l'utilisation ? Sinon, je ne vois pas l'interet de faire 2x ce calcul.
Je parlais bien de l'implementation. et je n'ai pas dit "refaire" le calcul mais "affiner".
Pour illustration, prenons un exemple concret: l'implementation de la fonction inverse en double precision sur une machine n'implementant pas la division directement. Pour info le calcul de a/b se fait en calculant 1/b puis en effectuant la multiplication avec a. Donc 1/b n'est pas la simple division de 1 par b.
Imaginons que tu saches calculer 1/b avec une faible precision. On dira que c'est y.
On note que la fonction f(x)=1/x - b a une racine pour x=1/b
En utilisant Newton-Ramson pour trouver la racine de f, on obtient la serie:
x_{n+1} = x_n(2-b*x_n)
Cette serie converge vers 1/b, ce que l'on cherche.
La convergence dans notre cas est quadratic, et le nombre d'etapes necessaire pour obtenir un resultat avec une prevision inferieure a une erreur donnee depend de la difference entre x_0 et 1/b.
A noter que cette serie n'utilise que des multiplications et des additions/soustractions.
Plus x_0 est proche de 1/b, moins d'etapes sont necessaires pour obtenir 1/b avec une precision voulue.
Dans beaucoup de CPU, la fonction inverse est implementee de cette facon, le CPU ne fournissant qu'une valeur approchee de la division...
Idem pour la racine carree.
C'est la meme methodologie utilisee pour la methode hybride simple et double precision:
- La serie est etablie sur papier et l'etude de la convergence de l'erreur etablit le nombre maximal d'iteration a effectuer pour obtenir un resultat correct en double precision pour un x_0 initial avec une precision inferieure ou egale a ce que l'on aurait au pire avec une implementation en simple precision. Evidement, on tient compte du fait que la multiplication et addition sont arrondies.
- Le calcul en precision simple etabli x_0 afin d'avoir une valeur approchee dont on majore l'erreur.
- On applique les n iterations necessaire
C'est effectivement plus complexe a etablir que de tout faire en double, mais ca peut avoir un gain enorme dans certains cas.
C'est encore la supériorité de la fpu x87 par rapport à SSE.
Tout depend de la methode d'evaluation de ce qui est meilleur a un autre. Cependant:
- En terme de transistor, n'implementer que des multiplications et addition, c'est moins couteux.
- De meme, si tu as besoin d'une precision plus fine que simple mais pas autant que double, tu y gagnes.
- Si quelqu'un trouves une meilleur implementation, ben c'est logiciel. Idem pour les bugs (le bug du Pentium sur la FP etant une mauvaise implementation de la fonction "approchee" de 1/x).
- Si pour un calcul unique c'est pas superieur a une fonction hardware, le fait que la multiplication et l'addition peut etre implemente dans un micropipeline, appliquer la meme fonction sur plusieures valeurs peut etre plus rapide que l'application sequentielle de cette operation sur chacune des valeures.
Cela revient à une étude d'interval, non ?
Oui mais on verifie deja dans les cas dont on sait que les sous operations de la fonction ont des discontinuites avant de se prendre la tete a verifier quelque chose dont on est pas sur que ce soit verifiable.
J'ai bon ?
Oui, mais je rajouterais les etapes initiales:
- Je definis quels sont mes besoins en terme de precision.
- Je verifie que quelqu'un l'a pas deja fait, parce que une prise de tete enorme s'annonce
A la fin:
- Je cree une doc avec mes formules mathematiques comme ca cela servira a quelqu'un d'autre. Les capacites de formatage etant limite dans un code source pour prouver mon erreur, faire ca dans un fichier a part. Genre avec LaTeX.
[^] # Re: plop again
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 4.
http://www.gpgpu.org
Ils s'amusent comme un fou.
[^] # Re: plop again
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 5.
Une nouvelle tendance pour les processeurs ou il y a une difference en terme de temps de calcul entre precision simple et precision double:
Effectuer une premiere estimation en precision simple, puis affiner en precision double.
es 80 bits du fpu ont du plomb dans l'aile puisque sur x86_64, tous les calculs se font en SSE2, cad en 64 bits maxi.
Au dela de cette demonstration douteuse:
IEEE precise non seulement un format de stockage de nombre flottans (simple, double), mais aussi une precision sur un certain nombre d'operations, incluant evidement multiplication, division, racine carree, mais aussi certaines fonctions comme les fonctions trigonometriques.
Comme les processeurs ne supportent generalement pas ces dernieres (et encore parfois meme pas la division), le resultat s'obtient par une serie de calcul (rappelez vous les developements limites, lagrange, polynomes de tchebychev....). Afin d'obtenir la precision specifiee par IEEE, il est necessaire d'utiliser une precision plus grande pour les calculs intermediaires. Ceci est le cas jusqu'au jours quelqu'un prouve qu'une telle precision n'est pas necessaire.
La racine carree et la division est generalement prouvee en etudiant la valeur maximale de l'erreur. Mathematiquement, on sait prouver pour la totalite des valeurs sauf certains cas limites. Ces cas limites sont verifies experimentalement.
Pour les autres, c'est plus du "Jusqu'a ce jour, en tenant compte des cas extremes identifies theoriquements, nous avons obtenu une erreur maximale de x. Il n'est pas impossible que l'on en ai manque dans la liste".
Il existe des possiblites ou on peut utiliser des valeurs avec moins de precision pour les calculs intermediare, mais cela necessite plus d'operations, et a la fin cela ne vaut pas le coup.
Dans le poste original:
Comment s'écrit un code ? Par essais erreurs ? On doit évaluer "à la main" les fuites de précision et écrire l'algorithme en conséquence ?
Tout a fait. Une etude de l'erreur est effectuee. Mais auparavant, on effectue une etude de stabilite: quel est la variation du resultat si l'on ajoute sur l'une des donnees en entree une petite valeur (epsilon).
J'imagine que c'est la démarche des codes scientifiques pour éviter d'utiliser des nombres étendus plus lent.
Reussir a prouver l'implementation de son calcul, c'est deja pas mal. On repasse generalement plus tard pour reduire la precision.
# en avance, en avance...
Posté par mdlh . En réponse au journal Le plan de Barack Obama en ce qui concerne la technologie et l'innovation. Évalué à 2.
Les primaires commencent en Janvier...