Reprise du message précédent :

Moui, effectivement ça a voir avec le fait de traiter des POD ou pas, mais en fait pas seulement: comment produire un +/- infinie dans un initialiseur? Ou un NaN?
 
 
 
 
 

Pas de lien sous la main. Tu as differentes caches, je ne parles que de celles pour les instructions & données, de differents niveaux 1/2/3/etc en ordre croissant de taille. En general tout cela fonctionne par 'ligne' avec une regle du genre MRU (Most Recently Used). En gros.
Par exemple sur un K8 (Opteron, AMD64) les lignes de cache de donnée font 64 octets, chacune étant plus ou moins independante des autres. Quand il manque de place, le cpu évince celle qui a été utilisée en dernier. En gros.
Il faut aussi noter qu'il n'y a pas d'unité plus petite que la ligne de cache. Quand tu fais une operation d'écriture au mileu d'une ligne, c'est tout la ligne qui est marquée comme tripotée. Moralité il ne faut pas mélanger ce qui est en lecture seule et ce qui est en écriture.
 
Donc il se peut que tu ais en cache tout un jeu de donnée provenant des 4 coins de la mémoire, tout est affaire de flux.
 

Tout est possible. De toute façon gcc sait generer fld1, fldpi etc... pour peu qu'il reconnaisse la constante, qu'il estime que ça permet de gagner du temps (ou de la place si tu optmises pour la taille) etc...

C'est le proposal que j'évoquais plus haut. Il a le statut de "No interest, or superseded by other proposals".

> Non, non et non. Il n'y a rien de gratuit en ce bas monde. Si une constante est 'inlinée' comme vous dites, au lieu d'un accès mémoire explicite vous payez pour de la bande passante de decodage car l'instruction requiert plus de place pour etre encodée.
 
ok, ça j'imprime, choix entre cache et prefetch, mais...
 
...dans un programme compilé où tu est sûr que le cache va être saturé, autant du fait que tu as des mégas de données, et une grosse boucle de 3 kilomètres, est-ce que prefetch n'est pas plus performant pour de petites constantes (quelques octets seulement) à utiliser dans une seule sous-fonction?
 
Je veux dire, la constante devra de toutes façon être chargée dans un registre. Qu'elle le soit à partir du code ou des données, comme un tour de boucle ne tient absolument pas en cache, cette constante vient de toutes façons de la mémoire centrale. Ou bien le cache est capable de garder la constante d'un tour de boucle à l'autre? dans ce cas pour une petite constante ça ne pose pas de problème majeur, pour une grande si.
 
(note: avec -finline-limit=1Méga et un disque dur complet de swap pour compiler)

edit: posté trop tot, tu as répondu en grande partie à ma question.

oui je vois ça, je cherche les paliatifs. mais le problème évoqué est réel.

bon va falloir que je ne considère plus le cache comme une boîte noire. ya des astuces à trouver.

 
Whole program optimisation dans VS. Generation de code au moment du link, ca permet d'avoir une meilleure vue du programme. (comme l'inlining de fonctions pas dans des .h, ce genre de gag)
 
Faudrait regarder en detail quelles sont les optims que VS peut effectuer et effectue a ce moment la

certes, cela dit, faut avoir le temps CPU et la RAM pour faire ça ...

t'as une option de bourrin dans gcc 4.1 pour ça

 
Comme ça:

 
Sans -ffast-math, juste pour le fld1

 
-ffast-math

et surprise, ya un 2.f en 0x40e004.

 
oué, forcement, generalement tu l'actives que lors de la compilation de release finale Dans VS 8 y ont rajouter un optimiser qui se base sur les resultats d'un profiling pour encore grapiller une brochette de pourcent, l'idée est marrante.  
 

 
t'es ne float, taz parlait en int. En int le compilo a le droit de faire de la simplification mathématique, ce genre de chose. Et pour ca il a besoin de connaitre la valeur des constantes

 
Si on utilise les fonctions inline (comme dans les classes de traits standards), et qu'on considère le papier de Gaby Dos Reis sur les expressions constantes généralisées, on a peut être le résultat voulu, non ?

t'as pas l'impression de tricher là ...

ca dois jouer le fait que la définition de a se trouve dans la meme TU ?

bah ouais

Evidement que ça joue, vous croyez aux miracles vous?
 
Le coup du 'whole programm optimization' c'est rien d'autre que de changer la visibilité des fonctions et des données (en gros tout coller en statique par défaut au lieu d'extern) et de scotcher toutes les unitées ensembles.
 
Je ne triche donc pas plus que les compilateurs.
 
 

Tu crois qu'il fait quoi la le compilateur?

et si on mets extern, c'est du flan ?

Du tout. Mais le fait que le compilo produise une constante addressable et comment il l'utilise (si il arrive a completement la deduire) sont 2 faits parfaitement distincts.

#
extern const float a;
#
 
#
float foo(const float c) {
#
    const float b = 1;    
#
    return c+a+b;
#
}
 
compile ça et reviens ...

Qu'essaies tu de me démontrer? Qu'un compilo ne fait pas dans la voyance?
 
Ta question initiale était...

... et j'y ais répondu. Si tu ne saisis pas les tenants et aboutissants, j'en suis désolé.

fast-math c'est sympa en local, sur ta propre machine, sinon si tu execute le prog sur une machine exotique avec le même jeu d'instruction et des calculs flottants plus précis t'obtient pas le même résultat.
(rem: ça c'est un autre débat, la précision des flottants)
 
tbp> tu ne fait pas de la compilation séparée là. remarque que ça me pose pas de problème, j'ai déjà essayé, et c'est vrai que ça améliore un chouia:
for i in *.cpp do echo "#include \"$i\"" >> optim.C ; done
 
Perso, j'en concluerai que sur des petites boucles ça vaut sûrement le coup de se prendre la tête sur une optim inline/extern, pas forcément sur une grande boucle. Je verrai donc à la fin, si je peut optimiser encore en découpant mon code et mes données judicieusement.
 
Merci à tous.

vas-y, joue au con.

il a raison, c'est la meilleure solution: le compilo peut utiliser à la fois la définition extern et inline.

la variable ne peut etre définie qu'une fois, ou est l'interet

Vu que je suis d'humeur taquine...
 
 

Si la précision differe le resultat sera different, fast-math ou pas.
Ce qui compte generalement c'est le nombre d'ulp en bout de course. A ce point du débat, on se doit de connaitre son compilo, et donc ce qu'implique reelement fast-math. Ca n'a rien de magique.
 

Sauf que pour que ça porte vraiment ses fruits il faut à priori triturer la visibilité de divers élements afin que d'exposer plus d'optimisations potentielles, entre autres choses.
Je rappelle à toutes fins utiles que, par exemple, les fonctions membres d'une classe ont un linkage externe par défaut (empechant l'utilisation d'une convention d'appel plus aggressive). Etc...
 
Pour l'instant, --combine & --whole-program ne sont pas disponible pour le C++ avec g++. Mais ça ne saurait trop tarder.
 

Au contraire. C'est lorsque le compilo perd de vue les données chaudes, comme on dit outre-atlantique, qu'il faut le guider, à la main s'il le faut. Et ça a d'autant plus de chance d'arriver que le code en question grossit.

L'interet c'est de produire une section read-only avec des données intialisées...

... ce qui n'entrave en rien les 'optimisations' si tel est votre souhait, comme je l'ai démontré.
 
D'ailleurs je viens de remarquer que l'alignement est foireux, c'est nouveau ça. Crotte.

> Si la précision differe le resultat sera different, fast-math ou pas.
 
Si le résultat correct dépends d'un arrondi du dernier chiffre, ça marche plus avec 1 chiffre de plus en calcul interne. C'est du chipotage de toutes façon. (Jusqu'au jour où t'a un bug de calcul inexplicable)
 
> Au contraire. C'est lorsque le compilo perd de vue les données chaudes
Oui, ok. Plutôt: en priorité optimiser les petites boucles internes avant la grosse globale.

Un dernier point, les compilo ont des heuristiques pour regrouper les fonctions & données afin d'améliorer la localité des accès, mais d'une part il faut leur permettre de re-organiser le bazar et cela reste des heuristiques.
 
D'ou le principe des 'profile guided optimizations' qui remplacent ces heuristiques par des mesures, gcc/msvc/icc proposent tous à des degrés divers qque chose dans ce gout la (avec plus ou moins de bonheur).
 
Il n'empeche que le programmeur est à priori le mieux placé pour savoir ce qui est pertinent. Ou pas