Qu'est-ce que la conception orientée données?
Je lisais cet article , et ce gars continue en expliquant que tout le monde peut grandement tirer profit du mélange de la conception orientée données avec la POO. Il ne montre aucun échantillon de code, cependant.
Je l'ai cherché sur Google et je n'ai trouvé aucune information réelle sur ce que c'est, sans parler des exemples de code. Quelqu'un connaît-il ce terme et peut-il donner un exemple? Est-ce que c'est peut-être un mot différent pour autre chose?
Tout d'abord, ne confondez pas cela avec la conception basée sur les données.
D'après ma compréhension de la conception axée sur les données, il s'agit d'organiser vos données pour un traitement efficace. Par exemple, Data Driven Design consiste à laisser les données contrôler beaucoup de comportements de vos programmes (très bien décrits par réponse d'Andrew Keith ).
Supposons que vous ayez des objets boule dans votre application avec des propriétés telles que la couleur, le rayon, l’amplitude, la position, etc.
Approche orientée objet
Dans OOP vous décririez vos balles comme ceci:
class Ball {
Point position;
Color color;
double radius;
void draw();
};
Et ensuite, vous créeriez une collection de balles comme celle-ci:
vector<Ball> balls;
Approche axée sur les données
Dans la conception orientée données, cependant, vous êtes plus susceptible d’écrire le code comme ceci:
class Balls {
vector<Point> position;
vector<Color> color;
vector<double> radius;
void draw();
};
Comme vous pouvez le constater, plus aucune unité ne représente une balle. Les objets boule n'existent qu'implicitement.
Cela peut avoir de nombreux avantages en termes de performances. Habituellement, nous voulons faire des opérations sur plusieurs balles en même temps. Le matériel veut généralement que de gros morceaux de mémoire continus fonctionnent efficacement.
Deuxièmement, vous pouvez effectuer des opérations n’affectant qu’une partie des propriétés d’une balle. Par exemple. Si vous combinez les couleurs de toutes les billes de différentes manières, vous voulez que votre cache ne contienne que des informations de couleur. Cependant, lorsque toutes les propriétés d'une balle sont stockées dans une unité, vous intégrez également toutes les autres propriétés d'une balle. Même si vous n'en avez pas besoin.
Exemple d'utilisation du cache
Dites une balle, chaque balle occupe 64 octets et un point, 4 octets. Un emplacement de cache prend également 64 octets. Si je veux mettre à jour la position de 10 balles, je dois insérer 10 * 64 = 640 octets de mémoire dans le cache et obtenir 10 échecs de cache. Si toutefois je peux travailler les positions des balles comme des unités séparées, cela ne prendra que 4 * 10 = 40 octets. Cela tient dans une extraction de cache. Ainsi, nous ne recevons qu'un seul cache pour mettre à jour toutes les 10 billes. Ces chiffres sont arbitraires Je suppose qu'un bloc de cache est plus gros.
Mais il montre comment la disposition de la mémoire peut avoir de graves conséquences sur le cache et donc les performances. Cela ne fera qu'augmenter à mesure que la différence entre le processeur et la vitesse RAM s'élargira.
Comment agencer la mémoire
Dans mon exemple, j'ai beaucoup simplifié le problème, car vous utiliserez généralement plusieurs variables pour une application normale. Par exemple. la position et le rayon seront probablement utilisés ensemble fréquemment. Ensuite, votre structure devrait être:
class Body {
Point position;
double radius;
};
class Balls {
vector<Body> bodies;
vector<Color> color;
void draw();
};
Cela est dû au fait que, si les données utilisées ensemble sont placées dans des baies distinctes, elles risquent de se faire concurrence pour les mêmes emplacements dans le cache. Ainsi, le chargement de l'un jettera l'autre.
Ainsi, comparé à la programmation orientée objet, les classes que vous créez ne sont pas liées aux entités de votre modèle mental du problème. Étant donné que les données sont regroupées en fonction de leur utilisation, vous n’avez pas toujours de noms pertinents à donner à vos classes dans la conception orientée données.
Relation avec les bases de données relationnelles
La conception de Data Oriented Design est très similaire à celle que vous avez sur les bases de données relationnelles. L’optimisation d’une base de données relationnelle peut également impliquer une utilisation plus efficace du cache, bien que, dans ce cas, le cache ne soit pas un cache de CPU qui mette des pages en mémoire. Un bon concepteur de base de données divisera probablement aussi les données rarement consultées en une table distincte plutôt que de créer une table avec un grand nombre de colonnes, où seules quelques-unes des colonnes sont jamais utilisées. Il peut également choisir de dénormaliser certaines des tables afin que les données ne soient pas accessibles depuis plusieurs emplacements sur le disque. Tout comme avec la conception orientée données, ces choix sont faits en examinant quels sont les modèles d'accès aux données et où se situe le goulot d'étranglement des performances.
Mike Acton a donné une conférence publique sur conception axée sur les données récemment:
Mon résumé de base serait le suivant: si vous voulez des performances, pensez au flux de données, trouvez la couche de stockage la plus susceptible de vous plaire et optimisez-la . Mike se concentre sur les erreurs de cache L2, car il le fait en temps réel, mais j'imagine que la même chose s'applique aux bases de données (lectures sur disque) et même au Web (requêtes HTTP). Je pense que c'est une manière utile de faire de la programmation système.
Notez que cela ne vous dispense pas de penser aux algorithmes et à la complexité temporelle, il concentre simplement votre attention sur le type d'opération le plus coûteux que vous devez ensuite cibler avec vos compétences folles en CS.
Je tiens simplement à souligner que Noel parle spécifiquement de certains des besoins spécifiques auxquels nous sommes confrontés dans le développement de jeux. Je suppose que d'autres secteurs qui pratiquent la simulation logicielle en temps réel en bénéficieraient, mais il est peu probable que ce soit une technique susceptible de montrer une amélioration notable des applications métiers en général. Cette configuration est destinée à garantir que chaque dernière performance soit réduite du matériel sous-jacent.