Reprise du message précédent :

C'était plus par curiosité qu'autre chose

par contre quelque chose d'interessant quand on veut faire de l'optimisation agressive mais pas destructrice (enlever des virtual, c bien mais le jour ou on réutilise...), c'est de bien maitriser la déclaration des champs de ses structures/classes: gaffe aux bits de bourrage, on peut perdre inutilement quelques octets

 
ouais j'ai découvert ca y a pas longtemps, avec un truc du genre :
 
struct s1
{
   char c1;
   int i;
   char c2;
}
 
et
 
struct s2
{
   int i;
   char c1;
   char c2;
}
 
on a sizeof (s1) == 12 et sizeof (s2) == 8
 
en anglais on appelle ca le padding je crois, qu'est par défaut de 4. par contre me souviens plus comment on l'élimine, sauf sous VC++, avec un "pragma pack()" je crois.
c'est meme pas de l'optimisation, il parait que le code généré est moins efficace quand les struct sont pas alignées (enfin bon, chuis pas sur...)
 
edit : j'ai retrouvé la page, ca explique bien le truc :
http://msdn.microsoft.com/library/ [...] errors.asp

ton pragme c'est de la contre optimisation certes, mais réarranger sa structure à la main, ça n'a aucun contre-cout ni effet indésirable. la taille du padding dépend de l'architecture et du type de données. la règle générale est de regrouper la déclaration des champs de même types

 
ouaip faut tjs mettre les champs les plus gros au dessus. Non seulement t'economise un peu de place mais tu peux aussi avoir un (leger bien sur, sauf si tu utilises le SSE ou la ca sera obligatoire ) gain de vitesse vu que tes membres auront plus de chance d'etre correctement alignés (a vrai dire suffira que le premier soit aligné pour que les autres le soient). Ca coute pas cher et c tjs ca de pris

ca marche comment exactement cette histoire d'alignement ?

en gros :
 
(Adresse de ta donnee) % sizeof(donnee) doit etre egal a 0
 
Partant de la, si tu met les plus grosses donnees en premier (double) et qu'elle est alignée, alors les autres données de ta struct le seront aussi (alignement naturel)
 
http://forum.hardware.fr/forum2.ph [...] 439&cat=10
 

Je prends note!
Si seulement ca pouvait accélérer mon appli...

c'est à dire? ben c'est justement une question d'alignement. pour les entiers, l'acces est plus rapide si les données sont alignés en fonction de la taille du bus. pour les flottants, il me semble que les normes IEEE imposent une contrainte forte sur l'alignement.
 
enfin si tu fais ça
 
char c;
int i;
 
sur un x86 tu risques d'avoir 3octets de padding entre les 2 membres. ça n'est pas evitable, sauf directive de compilation. l'acces mémoire est alors sub-optimal (en général) mais ça gagne de la place. l'interet de déclarer cote à cote des données de meme type ne demande pas de padding entre elles, puisque ces données sont toutes correctement alignés.
 
enfin bon, c'est anecdotique, mais ça peut rendre service des fois. mais y aura toujours un minimum de padding. de toutes façons du padding, t'es as partout, jusque dans les pages pour avoir un alignement avec les ligne de cache

 
attention tu entre la dans le domaine de l'optimisation bas niveau 3lite w4rlord oldsch00l

rien à voir. ce qui est important c'est les types, pas la position.
 
 
int i;
char c;
 
donne la meme chose que
 
char c;
int i;

Je vais pas trop toucher à tout ca, je m'en sortirai pas...mais si mettre les membres de grande taille au début suffit à accélérer le brol je vais pas m'en priver...de toute façon j'ai rien à perdre!

 
Depend si ton compilo padd le tout ou pas, sinon alors le deuxieme est - rapide que le premier. Note que ne serait ce que pour gagner trois octets on a tout interet a utiliser le premier
 
skeye : heuh t'attends pas a tomber de ta chaise devant tes nouvelles perfs hein ?
 

nonon, mais tout gain est appréciable vu les quantités de données que je traite...
Mes images en 2400*3200 font "légèrement" souffrir les p2 du taf...

http://oopweb.com/Assembly/Documen [...] EADING1-31

Bizarre ... le lien de la barre de titre ne marche pas dans une autre fenêtre ...
http://oopweb.com/Assembly/Documen [...] rames.html
Chapitre 3, -> 3.1.2 "The Memory Subsystem"

(j ai pas tout lu le topic ca a peut etre deja été dit)
 
il faut savoir que si tu declares un tableau genre char tab[9] bah il fera pas 9 octets en memoire mais 12.  
 
C du au fait qu on travaille en 32 bits et donc que les lectures se font 32bits par 32 bits. C est donc plus rapide a lire.
 
C est d ailleurs pour cela que le bool (en minuscule ) est "inutile" si c est pour gagner de la place car en memoire il prend 4 octets.
 
Par contre je ne sais pas pour l allocation dynamique.