Bref, très difficile d'écrire du code spécifique pour une machine.
En effet.
Ceci dit, ce niveau d'optimisation (optimiser pour exploiter le fait qu'une ligne de cache à une taille définie) à plusieurs paliers aussi: par exemple dans une classe mettre les membres les moins utilisés à la fin, ou tout simplement faire gaffe à l'alignement des données en fonction de la taille du type (tiens d'ailleurs... je me demande comment ça marche ce genre de problématiques dans les langages sans typage statique?).
Ces cas restent des cas d'optimisation qui sont relativement simples à mettre en œuvre et ne dépendent pas (trop) de la machine cible. Ça n'implique d'ailleurs pas non plus de repenser toute l'archi.
Pour le coup, on peut même simplement se dire qu'un bloc de données qui sont rarement utilisées, plutôt que de les mettre dans la même classe que des trucs utilisés en permanence, stocker une référence (dans le sens français du terme, pas C++: ça peut être un id, un itérateur, un pointeur, peu importe) qui permets d'accéder à ces données peu usitées permets d'augmenter la densité des données utiles (si l'objet est utilisé dans un tableau, bien entendu).
Bon, certes, c'est pas «optimiser au maximum», juste optimiser un poil :)
ce qui a le mérite d'être plus explicite, je dirais
Bof, des pointeurs à poil en C++ moderne...
Bah... à moins de bricoler un pointeur qui ne peut être libéré (ce qui à tendance à être mon choix, pour le coup), y'a moyennement le choix. Sinon, faut utiliser shared_ptr, et la on passe de (sur une machine classique) 8 octets à 24 (pointeur + compteur + deleter quand on veut utiliser ça pour des structures C, 16 si on prend juste le delete par défaut de l'objet stocké) du coup ça peut piquer pour les perfs.
Pas évident sans refiler tout un tas de code imbittable.
Tant pis alors. Parce qu'effectivement la je ne vois pas comment ça peut tomber dans un comportement non défini.
[^] # Re: essayer Julia ?
Posté par freem . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 2.
En effet.
Ceci dit, ce niveau d'optimisation (optimiser pour exploiter le fait qu'une ligne de cache à une taille définie) à plusieurs paliers aussi: par exemple dans une classe mettre les membres les moins utilisés à la fin, ou tout simplement faire gaffe à l'alignement des données en fonction de la taille du type (tiens d'ailleurs... je me demande comment ça marche ce genre de problématiques dans les langages sans typage statique?).
Ces cas restent des cas d'optimisation qui sont relativement simples à mettre en œuvre et ne dépendent pas (trop) de la machine cible. Ça n'implique d'ailleurs pas non plus de repenser toute l'archi.
Pour le coup, on peut même simplement se dire qu'un bloc de données qui sont rarement utilisées, plutôt que de les mettre dans la même classe que des trucs utilisés en permanence, stocker une référence (dans le sens français du terme, pas C++: ça peut être un id, un itérateur, un pointeur, peu importe) qui permets d'accéder à ces données peu usitées permets d'augmenter la densité des données utiles (si l'objet est utilisé dans un tableau, bien entendu).
Bon, certes, c'est pas «optimiser au maximum», juste optimiser un poil :)
Bah... à moins de bricoler un pointeur qui ne peut être libéré (ce qui à tendance à être mon choix, pour le coup), y'a moyennement le choix. Sinon, faut utiliser shared_ptr, et la on passe de (sur une machine classique) 8 octets à 24 (pointeur + compteur + deleter quand on veut utiliser ça pour des structures C, 16 si on prend juste le delete par défaut de l'objet stocké) du coup ça peut piquer pour les perfs.
Tant pis alors. Parce qu'effectivement la je ne vois pas comment ça peut tomber dans un comportement non défini.