Войти
ПрограммированиеФорумОбщее

Data Oriented Design. Виртуальные функции. (комментарии)

Страницы: 1 2 3 4 5 6 Следующая »
#0
12:23, 18 фев. 2011

Data Oriented Design. Виртуальные функции. (комментарии)

Это сообщение сгенерировано автоматически.


#1
12:23, 18 фев. 2011

Deft(So-so-so, PR();)

#2
12:36, 18 фев. 2011

что-то я не понял. в ДОД версии ты просто отказался от вирт функций и сделал update универсальным на все movable? это же совсем негибко
давайте на асме сразу писать чтоб ещё быстрее)
и btw, чем измеряешь целостность кэша?

#3
12:54, 18 фев. 2011
что-то я не понял. в ДОД версии ты просто отказался от вирт функций и сделал update универсальным на все movable?

Как видно из кода - да.

Не думаю, что автор измерял целостность кэша, он замерял время выполнения, откуда делал определенные выводы.

давайте на асме сразу писать чтоб ещё быстрее)

Смысл статьи в том, чтобы показать преимущество DOD по скорости работы, что нередко является основным фактором использования такого кода :)
#4
13:27, 18 фев. 2011

Deft

Ты не то перевел, вся соль в комментариях :)

Имхо во всей этой теме DOD немного смещен фокус.
Нигде не проблема лучше ли DOD для производительности, если это кто-то не понимает значит он просто еще не слышал про кэш, simd и т.п.
Везде проблема в другом месте - *как* применить DOD не нарушая OOP-style гибкость и т.п.
Легко сказать давайте засунем все анимации в один буфер и просчитаем их одним алгоритмом.
Как насчет того что *нужно* каждую анимацию кастомизировать на сайте клиента, т.е. алгоритм изменяется вне библиотеки, которую мы пишем?
Это можно решать, и вот специфика - это уже интересно.

#5
13:37, 18 фев. 2011

>Везде проблема в другом месте - *как* применить DOD не нарушая OOP-style гибкость и т.п.
Очевидно, что DOD как раз должен нарушать "OOP-style гибкость". В этом вся соль: обладая информацией о данных ты строишь свою программу, основываясь на этих специфических знаниях.

#6
13:41, 18 фев. 2011

Нуу, из комментов я выбрал инфу о показателях на более сложной функции.
Насчет проектирования согласен - DOD нужно делать гибким, что очень сложно реализовать.
Но еще раз повторюсь - дело этой статьи - показать преимущества в скорости работы с использование DOD, а не способы реализации механизма :)
P.S. Просили перевести эту статью, а-ля "Полезно для newbie" =)

#7
13:41, 18 фев. 2011

нам гибкость не нужна, нам скорость нужна

#8
15:04, 18 фев. 2011

Не понял, как разные по размеру структуры лежат в одном массиве.

#9
15:47, 18 фев. 2011

shekh
> Легко сказать давайте засунем все анимации в один буфер и просчитаем их одним
> алгоритмом.
а так никто не говорит. говорят давайте сгрупируем анимации по алгоритмам и посчитаем

#10
15:48, 18 фев. 2011

Wraith
> Очевидно, что DOD как раз должен нарушать "OOP-style гибкость
кому очевидно? и что такое ооп стайл гибкость?

#11
16:35, 18 фев. 2011

kas
Ну как "обычно", т.е.

struct IObject
{
    virtual void update() = 0;
    virtual void draw() = 0;
    ...
};
ну чо я тебе рассказывать буду, сам знаешь же.
#12
16:43, 18 фев. 2011

Wraith
ну если считать это гибкостью то да, нарушает)

#13
19:24, 18 фев. 2011

а чем оно от DDDAS отлично?

#14
21:49, 18 фев. 2011

>Теперь DOD дает порядка 60% производительности относительно способа с вектором.
Детский сад.

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.