OpenGL Вопросы (7 стр) / Графика / Форум / Программирование игр / GameDev.ru

bazhenovc
Data Oriented быстрее, да. Только у него есть один существенный минус. Я с ним никогда не работал. Я вообще слабо представляю как в этом штиле писать.

bazhenovc, Стас
Предлагаю теперь сравнить i++, ++i, i+=1 и i = i + 1
Кто напишет тест?

MrShoor
> Предлагаю теперь сравнить i++, ++i, i+=1 и i = i + 1
Идентичны, но могут быть чудеса в связи с не атомарностью данных :-D

MrShoor
Ну всякие дядьки говорят что ++i в форах быстрее. Типа не надо копировать. Но я им не верю.

Стас
Это не корректно, потому что ты ошибся с rand(). У тебя ни одна матрица не считается, в жизни такого точно не будет :)

Да и в нормальных условиях обычно хочется не скипнуть больше объектов, а наоборот - показать максимальное разнообразие на экране.

bazhenovc
> Да и в нормальных условиях обычно хочется не скипнуть больше объектов, а
> наоборот - показать максимальное разнообразие на экране.

Так ты их и не скипнешь, ты просто их матрицу не пересчитываешь.

MrShoor
> Предлагаю теперь сравнить i++, ++i, i+=1 и i = i + 1
> Кто напишет тест?
Ключевой вопрос: какой тип у i? Это int или std::some_heavy_iterator_with_slow_constructor?

Разница в префиксном и постфиксном инкременте заключается в том, что префиксный инкремент не создаёт копию объекта. Если объект - какой-то замороченный кастомный итератор, тогда разница в скорости будет.
Но это не зависит от типа инкремента, это скорее вопрос к тому, что внутри итератора.

Dampire
> Ну всякие дядьки говорят что ++i в форах быстрее. Типа не надо копировать. Но я
> им не верю.

Ты хочешь еще одну лекцию на следующие 7м страниц?:-D

bazhenovc
> Ключевой вопрос: какой тип у i? Это int или
> std::some_heavy_iterator_with_slow_constructor?

А черт... опоздал... :-D Ладно ты пока тут прочитай лекцию, а я пожалуй пойду:-D

bazhenovc
Сори, забыл поставить тег [sarcasm]

#include <chrono>
#include <vector>
#include <thread>
#include <iostream>

struct A1
{
  A1()
  {
    std::this_thread::sleep_for(std::chrono::milliseconds(3));
  }

  A1(const A1& other)
  {
    std::this_thread::sleep_for(std::chrono::milliseconds(3));
  }

  A1& operator++()
  { return * this; }
  A1 operator++(int)
  {
    A1 orig = *this;
    ++(*this);
    return orig;
  }
};

int main()
{
  A1 a;
  auto tmStart = std::chrono::high_resolution_clock::now();
  for (int i = 0; i < 100; ++i)
  {
    a++;
  }
  auto tmEnd = std::chrono::high_resolution_clock::now();

  std::cout << "a++: " << std::chrono::duration_cast<std::chrono::duration<double>>(tmEnd - tmStart).count() << std::endl;

  tmStart = std::chrono::high_resolution_clock::now();
  for (int i = 0; i < 100; ++i)
  {
    ++a;
  }
  tmEnd = std::chrono::high_resolution_clock::now();

  std::cout << "++a: " << std::chrono::duration_cast<std::chrono::duration<double>>(tmEnd - tmStart).count() << std::endl;
}

Я даже не знаю что на это ответить. По-моему приведенное выше очевидно, нет?

для pod'ов без разницы постфиксный или префиксный инкремент, они выполняются с одинаковой скоростью.

Dampire
> Я даже не знаю что на это ответить. По-моему приведенное выше очевидно, нет?
Не всегда. Ты вот можешь сходу сказать, что происходит внутри std::vector::iterator?

bazhenovc
> Хотя в любом случае я был прав с data-driven подходом, он всё равно быстрее

Э... если вспомнить ту pdf от Сони - там есть маленькое но, ноды одного типа - вот когда в сцене много разных типов ?

Помнится, с Пушковым много было писанины про pitfall OOP - вот на последних x86 CPU ( да и за последние лет 5 ) много фич для ускорения уже имеющегося кода - то есть чип подстраивается под код, а не наоборот