Nicolas Boulay a écrit 15824 commentaires

Les niagara sont des "petits" cpu. Leur but est de maximiser la performance par W. Sur un data center, cela peut faire la différence. Google s'était montré intéressés un moment.

J'imagine qu'un niagara avec 16 cores doit donner de bonne performance pour les serveurs avec plein de de clients.

"La première sécurité est la liberté"

POWER != powerpc ...

Même rien à voir.

powerpc est l'architecture la plus courante dans le cpu embarqué "puissant" (bref, quand un arm ne suffit pas)

"La première sécurité est la liberté"

J'ai travailler un peu avec Ion, et j'ai surtout trouvé cela inutilisable.

Cela marche bien pour 2/3 xterm d'ouvert et un editeur, mais si tu ouvres et ferme souvent des logiciels différents, ils ne sont jamais là ou tu veux. Je ne parle même pas de l'utilisabilité de gimp...

Ce qu'il faudrait c'est plutôt une fusion de fenètre dans KDE. En gros que l'on puisse mettre des applications dans une seul fenètre avec un moyen simple par clic d'indiquer le comportement à l'agrandissement (taille fixe ou proportionnel pour chaque tile)

On aurait l'avantage des 2 systèmes.

"La première sécurité est la liberté"

Je crois que Duval était loin de la communauté...

"La première sécurité est la liberté"

l'idée de base est que "a+b" est un résultat sur 33 bits et qu'il y a perte. Tu t'en sors avec les propriétés des modulos, j'ai l'impression.
Par ce que en math non signé, 0x0-0x1 = 0xFFFFFFF; n'a pas vraiment de sens.

"La première sécurité est la liberté"

Dans ma boite, c'est changement tous les 3 mois mais sans le choix du mots de passe.

Ils sont généré aléatoirement et on le choisis parmis ceux proposé. (un mixte de lettre et de chiffres)

Par contre, ils sont assez gentil pour que la majeur partie des logiciels utilisent les mêmes mots de passes.

"La première sécurité est la liberté"

oui mais c'est 100% la faute du management/de l'IT, si l'infrastructure ne tient pas compte des besoins de ses utilisateurs !

"La première sécurité est la liberté"

Pour le processeur, c'est le "Flush to zero":

C'est uniquement ça ? Il me semblait que cela pouvait aller bien plus loin. Par exemple, les règles d'arrondies un peu assouplie (moins/pas de garde bit).

A moins que le mode dont tu parles, c'est le fonctionnement sur x86 ?

"La première sécurité est la liberté"

Ne confonds pas la norme et la toutouille des compilos.

"La première sécurité est la liberté"

C'est exactement ça :)

(a+b)-a
se comprend
((a+b) & 0xFFFFFFFF - a) & 0xFFFFFFFF

Or c'est différent de b & 0xFFFFFFFF selon la valeur de a et de b.

"La première sécurité est la liberté"

Vivement les class action, il y a des proces qui manquent !

"La première sécurité est la liberté"

Oui mais c'est en violation de la spec du C.

"La première sécurité est la liberté"

icc est connu pour inclure --fast-math dans -o2, ce que ne ce permet pas gcc.

Sinon, on semble dire la même chose. Quand il y a execution en parrallèle on ne peut plus vraiment parler d'ordre. Le flot d'instruction est déterminé par leur liaison par les registres et par les accès à la mémoire.

"La première sécurité est la liberté"

Si on fournis au codeur un moyen d'estimer la précision, et/ou d'optimiser en lui garantissant la précision qu'il demande, je ne pense pas qu'il nous en veulent beaucoup...

"La première sécurité est la liberté"

Il pourrait mais il ne le fait pas.

a+b+c+d équivaux à (((a+b)+c)+d)

C'est à vérifier mais je suis sur à 90% que le compilo C ne doit pas y toucher.

Car a+b+c+d veut en fait dire :
trunc<32>(trunc<32>(trunc<32>(a+b)+c)+d)

Ce qui est non équivalent à :
trunc<32>(trunc<32>(a+b)+trunc<32>(c+d))

"La première sécurité est la liberté"

"Mais en réalité, les mêmes instructions SSE servent aussi au calcul entier. "

euh, non il me semble pas.

Le SSE2 à ajouter les doubles. SSE3 a définit des opérations binaire sur le vecteurs 128 bits. Je ne pense pas qu'il y est des opérations entières.

Le SSE2 introduit aussi des opérations flottantes scalaires.

"La première sécurité est la liberté"

La question général, c'est plus sur la méthode actuellement utilisé pour avoir un code correct sachant la difficulté de départ.

Le but est évidement de rafiner tout ça pour trouver un modèle propre pour Lisaac.

"La première sécurité est la liberté"

Effectuer une premiere estimation en precision simple, puis affiner en precision double.

Pour la mise au point du calcul, j'imagine pas à l'utilisation ? Sinon, je ne vois pas l'interet de faire 2x ce calcul.

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

C'est encore la supériorité de la fpu x87 par rapport à SSE. Le x87 contient toute la trigo en hardware, contrairement à SSE. D'ailleurs, AMD était connu pour avoir une implémentation x87 musclé par rapport au processeur Intel qui favorisait plutot le SSE. Cela se voyait dans certain tests "scientifiques".

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).

Cela revient à une étude d'interval, non ?

Reussir a prouver l'implementation de son calcul, c'est deja pas mal. On repasse generalement plus tard pour reduire la precision.

- Je trouve l'algo
- Je prouve qu'il est stable numériquement
- Je regarde les cas bizarre par expérimentation
- si cela roule en double, j'essais de passer à la vecorisation ou au float 32 bits ?

J'ai bon ?

"La première sécurité est la liberté"

En C, c'est parfaitement interdit de toucher à l'ordre des opérations même en entier. Le problème se pose avec les overflows possibles.

J'avais fais un paquet de tests, il y a quelques années et gcc ne faisait rien du tout dans ce domaine.

Tout ceci sans parler des processeurs qui exécutent les instructions dans le désordre, bien entendu.

Sauf avec les dépendances RAW où tu ne peux rien faire du tout !

"La première sécurité est la liberté"

Cela marche toujours cette approche ? On ne risque pas de tomber rapidement dans un [-infini;+infini] ?

J'imagine que cela peut arriver vite dans un 1/(a-b), avec a et b proche.

"La première sécurité est la liberté"

ça au moins, c'est complet :)

Je peux résumé par :
"On veut de la répétabilité, et parfois on veut une idée précise de la précision." ?

Par contre, concernant les arrondis, l'utilisation de fonction explicite ou des mode de fpu influe sur quoi ? Uniquement la vitesse ? Ou il existe encore des subtilités ?

Comment utilises-t-on les modes "fast" ? En général, ces modes sont taxés de mal calculer. Je crois que l'itanium en a un. Les cartes graphiques utilisent aussi ces modes.

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. Mais si j'ai bien compris d'autres interventions, cela n'est génant que pour la detection d'errreur et non pour le fonctionnement nominal. J'ai bon ?

"La première sécurité est la liberté"

vu les nombres que tu manipules dans ton exemple, est-ce que tu ne cherches pas plutôt à faire du "fixed point", ce qui revient à faire des calculs entiers.

Si tu prends tout tes nombres et que tu les multiplies par 16, tu as 4 bits après la virgules.

"La première sécurité est la liberté"

Un autre truc qui ralentit monstrueusement le code c'est les nombres denormalisés, tous ceux qui font du traitement du signal avec des filtres récursifs en font l'experience un jour ou l'autre.

Quand est-ce qu'arrive ses nombres ? Je croyais que les fpu IEEE754 normalisait le nombre tout seul comme des grands.

"La première sécurité est la liberté"

Je ne vois pas bien comment ta bibliothèque peut écrire des équations à ta place.

Imagines n'importe quel filtre numérique.

"La première sécurité est la liberté"

Je ne comprends pas trop. Les gros systèmes type IBM utilise des formats infini entier justement pour ne jamais avoir de problème. Le support est même hardware.

"La première sécurité est la liberté"