Ответ 1
Прежде всего, не путайте это с конструкцией, управляемой данными.
Мое понимание Data Oriented Design заключается в организации ваших данных для эффективной обработки. Особенно в отношении промахов кэш-памяти и т.д. Data Driven Design, с другой стороны, позволяет управлять данными по многим вашим программам (очень хорошо описано Andrew Keith answer).
Скажите, что у вас есть объекты шара в вашем приложении со свойствами, такими как цвет, радиус, bounciness, положение и т.д.
Объектно-ориентированный подход
В ООП вы бы описали вам такие шары:
class Ball {
Point position;
Color color;
double radius;
void draw();
};
И тогда вы создадите коллекцию таких шаров:
vector<Ball> balls;
Ориентированный на данные подход
В Data Oriented Design, однако, вы скорее всего напишете код следующим образом:
class Balls {
vector<Point> position;
vector<Color> color;
vector<double> radius;
void draw();
};
Как вы можете видеть, ни одна единица не представляет одного шара больше. Объекты шара существуют неявно.
Это может иметь много преимуществ производительности. Обычно мы хотим делать операции на многих шарах одновременно. Аппаратное обеспечение обычно требует, чтобы большие непрерывные куски памяти работали эффективно.
Во-вторых, вы можете выполнять операции, которые затрагивают только часть свойств шаров. Например. если вы совмещаете цвета всех шаров различными способами, то вы хотите, чтобы ваш кеш содержал только информацию о цвете. Однако, когда все свойства шара хранятся в одном устройстве, вы также будете использовать все другие свойства мяча. Даже если они вам не нужны.
Пример использования кэша
Скажем шар, каждый шар занимает 64 байта, а точка занимает 4 байта. Кэш-память также имеет 64 байта. Если я хочу обновить положение 10 мячей, я должен вытащить 10 * 64 = 640 байт памяти в кеш и получить 10 промахов в кэше. Если, однако, я могу работать с позициями шаров в виде отдельных единиц, которые будут принимать только 4 * 10 = 40 байт. Это соответствует одной выборке кеша. Таким образом, мы получаем только 1 кеш-код, чтобы обновить все 10 мячей. Эти числа произвольны, я предполагаю, что блок кеша больше.
Но это иллюстрирует, как макет памяти может иметь серьезные последствия для кеша эффекта и, следовательно, производительность. Это будет только увеличиваться по мере увеличения разницы между ЦП и оперативной памятью.
Как разместить память
В моем примере шара я упростил проблему, потому что обычно для любого обычного приложения вы, вероятно, будете иметь доступ к нескольким переменным вместе. Например. положение и радиус, вероятно, будут использоваться вместе часто. Тогда ваша структура должна быть:
class Body {
Point position;
double radius;
};
class Balls {
vector<Body> bodies;
vector<Color> color;
void draw();
};
Причина, по которой вы должны сделать это, состоит в том, что если данные, используемые вместе, помещаются в отдельные массивы, существует риск, что они будут конкурировать за одни и те же слоты в кеше. Таким образом, погрузка одна выкинет другую.
Таким образом, по сравнению с объектно-ориентированным программированием классы, которые вы в конечном итоге делаете, не связаны с объектами в вашей ментальной модели проблемы. Поскольку данные объединены на основе использования данных, вы не всегда будете иметь разумные имена, чтобы давать свои классы в Data Oriented Design.
Отношение к реляционным базам данных
Мысль за Data Oriented Design очень похожа на то, как вы думаете о реляционных базах данных. Оптимизация реляционной базы данных может также включать использование кеша более эффективно, хотя в этом случае кеш не является кэшем кэша страниц в памяти. Хороший разработчик базы данных также, скорее всего, отделяет редко доступные данные в отдельной таблице, а не создает таблицу с огромным количеством столбцов, только когда-либо использовались только некоторые из столбцов. Он также может выбрать денормализацию некоторых таблиц, чтобы данные не могли быть доступны из нескольких мест на диске. Так же, как и с помощью Data Oriented Design, эти варианты сделаны, глядя на то, какие шаблоны доступа к данным и где узкое место производительности.