CppCon 2014 - Conception orientée données et C++

Les logiciels ne sont pas une plateforme ! Évidemment, la plateforme c'est le matériel. Lorsque le matériel change, la solution change.

La réalité n'est pas une bidouille. Vous êtes obligé de gérer cela pour résoudre votre problème théorique.

La réalité est le vrai problème.

Le fait de masquer les données, car elles sont implicites dans la modélisation du monde est faux, car :

• cela embrouille la maintenance (permet des changements sur les accès) ;
• cela embrouille la compréhension des propriétés des données (critique pour trouver les solutions aux problèmes).

La modélisation du monde implique des relations entre les vraies données ou les transformations, mais dans la vraie vie, les classes sont fondamentalement similaires : une chaise est une chaise, mais dans le jeu vidéo, on a une chaise physique, une chaise statique, une chaise cassable. Comment peuvent-elles être similaires ?

La modélisation du monde mène à un monolithe, sans liens entre les structures de données et les transformations.

La modélisation du monde essaie d'idéaliser le problème, mais vous ne pouvez rendre un problème plus simple que ce qu'il est.

La modélisation du monde est équivalente aux livres pour apprendre la programmation seul.

Trop de temps de développement est perdu à parler du code. Le seul but du code est de transformer une donnée d'une forme à une autre. Le programmeur est fondamentalement responsable des données, et non du code. Son travail n'est pas d'écrire du code, mais de solutionner des problèmes de transformation de données.

Écrire du code, seulement si cela a une valeur prouvable directe, comme la transformation de données d'une manière utile.

Vous ne pouvez pas vous protéger du futur ni avoir de solution idéale.

Ces mensonges provoquent :

• mauvaise performance ;
• mauvais parallélisme ;
• mauvaise optimisation ;
• mauvaise stabilité ;
• difficulté pour tester.

Il faut donc trouver la solution pour la transformation des données que vous avez, suivant les contraintes de la plateforme (et rien d'autre).

Lorsque l'on pense au code avant tout, on imaginera la table en mémoire.

Par contre, la plupart du temps, on parcourt la liste des clés, sans avoir besoin de la valeur. Ne chargez donc pas la valeur dans le cache. De plus, vous pouvez charger les clés les plus souvent utilisées dans le cache.

Il faut trouver la solution du cas le plus commun avant le cas le plus générique.

Est-ce que les compilateurs peuvent faire ce type d'optimisation eux-mêmes ?

Le compilateur ne peut régler que 10 % des cas. Il ne peut pas trouver de solution pour les problèmes réellement significatifs.

Il est absolument nécessaire d'optimiser les accès à la mémoire, notamment pour éviter que le CPU ait besoin de chercher les données dans la mémoire vive. Par exemple, vous pouvez empaqueter vos données pour n'avoir que les données nécessaires à disposition.

class GameObject {
    float m_Pos[2];
    float m_Velocity[2];
    char m_Name[32];
    Model* m_Model;
    // ... autres variables membres ...
    float m_Foo;
    
    void UpdateFoo(float f)
    {
        float mag = sqrtf(
            m_Velocity[0] * m_Velocity[0] +
            m_Velocity[1] * m_Velocity[1]);
        m_Foo += mag * f;
    }
};

Le problème étant que lors de l'appel à la fonction UpdateFoo(), l'intégralité des variables membres vont être copiées dans les registres et le souci est d'autant plus énorme lorsque vous voulez appeler la fonction sur de multiples instances.

La solution est de créer une fonction UpdateFoo() qui traite directement un tableau, et que ce tableau ne contienne que les données réellement utiles :

struct FooUpdateIn {
    float m_velocity[2];
    float m_Foo;
};

struct FooUpdateOut {
    float m_Foo;
};

void UpdateFoos(const FooUpdateIn* in, size_t count, FooUpdateOut* out, float f)
{
    for (size_t i = 0 ; i < count ; ++i) {
        float mag = sqrtf(
            in[i].m_Velocity[0] * in[i].m_Velocity[0] +
            in[i].m_Velocity[1] * in[i].m_Velocity[1]);
        out[i].m_Foo = in[i].m_Foo + mag * f;
    }
}

Ce nouveau code est maintenable, facile à déboguer et on peut estimer le coût d'une modification dans celui-ci.

Les variables booléennes dans les structures provoquent une diminution de la densité d'informations dans la structure et augmente le risque d'accès aux données en mémoire vive.

De plus, les variables booléennes sont utilisées pour les décisions de dernières minutes :

int Foo::Bar( int count )
{
    int value = 0;
    for (int i=0;i<count;i++)
    {
        if ( m_NeedParentUpdate )
        {
            value++;
        }
    }
    return (value);
}

Certains compilateurs peuvent avoir du mal à optimiser ce code. Il y a encore moins de chances que le code soit optimisé dans le cas où la variable booléenne est retournée par une fonction.

Pour aider le compilateur à optimiser le code, vous pouvez :

• placer les variables membres, dans des variables locales à la fonction ;
• les valeurs invariables et les embranchements doivent être gardés hors des boucles.