Войти
WarZesФорум

Виртуальные функции в системе рендера (комментарии) (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
13:09, 13 июня 2013

Che@ter
> В целом у меня виртуальные работают в 5-6 раз медленнее невиртуальных функций.

Ну вообще то у тебя виртуальные функции в 5-6 раз медленее работают записи константы в volatile переменную. Всё в inline, всё константно вычислимо на этапе компиляции еще. Неудивительно что тебе пришлось подставлять ключевое слово volatile ибо ты сам видел что без него тесты занимают 0 мс. Однако то что ты сделал volatile не означает что константы перестали быть константами, просто запись в переменную константы повторяется 10000 раз. Никакие функции без virtual вообще не вызываются.


#31
13:20, 13 июня 2013

Вот же, забыл про это :) Поставил в аргументы rand() и результаты сравнялись.

#32
13:20, 13 июня 2013

Вот так выглядит асмовыхлоп виртуальной функции:

  mov  ebx, 100000000
L5:
  mov  eax, DWORD PTR [esi]
  mov  DWORD PTR [esp+4], 5
  mov  DWORD PTR [esp], 4
  mov  ecx, esi
  call  [DWORD PTR [eax]]
  sub  esp, 8
  mov  DWORD PTR [ebp-52], eax
  dec  ebx
  jne  L5

Вот так "обычная функция":

  mov  eax, 100000000
L6:
  mov  DWORD PTR [ebp-48], 9
  dec  eax
  jne  L6

Как видно сравнение мягко говоря некорректное (хотя если функция проста типа геттера - вполне так может и быть в реале). Но если речь про рабочий код то это не оно.

#33
13:24, 13 июня 2013

Che@ter
> Поставил в аргументы rand() и результаты сравнялись.

А rand() в свою очередь ОЧЕНЬ тяжелая функция и забьёт собой любые попытки вычисления чего то маловесящего вхлам.
Совет такой - сделай массивчик небольшой (чтобы кеш уже не пришлось тестировать), заполни его рандом. А в рабочих циклах уже суммируй ячейки этого массива. Но т.е. массив небольшой для тестов, то заверни каждый цикл в еще один цикл-множитель и в нём суммируй допустим результаты в одной переменной (чтобы он по нему еще оптимизацией не прошелся). Ну хоть чуток ближе к реальности будет.

#34
13:26, 13 июня 2013

А, и если хочется не инлайны сравнивать а всё таки вызов функции - то выдели все классы в отдельный модуль, убери инлайны и реализации методов убери в *.cpp файл невидимый для тестировочного кода. Тогда он не сможет заинлайнить и будут честные вызовы невиртуальных методов.

#35
13:37, 13 июня 2013

ИМХО (ну тут уже накатали, но всеж)
инлайнинг виртуальных функций - возможен только в вакууме и не всегда.
если не про инлайнинг:
стоимость native call для виртуальной/невиртуальной ф-ии непринципиален

#36
15:32, 13 июня 2013

war_zes
Что на кубиках, что на серьезной сцене CPU оверхед на виртуальных вызовах будет минимальный. Не то нужно оптимизировать, ну и динамически рендер не сменишь, а то открыл консоль набрал "changerender", релоад ресурсов, красота.
Feo
>в машинный код они не транслируются
ну ну все лишь пару иyструкций с косвенной адресацией ну по крайней мере на x86.

#37
15:37, 13 июня 2013

Feo

renderer->currentRenderer = new OGLRenderer();
Я бы тут сделал так:
if (renderer->currentRenderer)
{
  renderer->currentRenderer->Destroy();// может не тут
}

Switch (RenderType)
{
  case OGLRender:
  {
    static OGLRenderer renderer;
    renderer->currentRenderer = &renderer;
  }
  break;
  case D3DRenderer:
  {
    static D3DRenderer renderer;
    renderer->currentRenderer = &renderer;
  }
  break;
}

renderer->currentRenderer->Init(....
#38
21:14, 13 июня 2013

Andrey
> Что на кубиках, что на серьезной сцене CPU оверхед на виртуальных вызовах будет
> минимальный.

Конзольные "отцы" с тобой не согласны ...

> Не то нужно оптимизировать

Пусть товарищ, скажет сколько у него получилось таких вызовов на один фрейм

#39
6:53, 14 июня 2013

Andrey
> Что на кубиках, что на серьезной сцене CPU оверхед на виртуальных вызовах будет
> минимальный. Не то нужно оптимизировать, ну и динамически рендер не сменишь, а
> то открыл консоль набрал "changerender", релоад ресурсов, красота.
Ты невнимательно читал. У меня три вида сборки - мультиплатформа, DX и OGL. Первая именно так и работает, с возможностью сменить рендер в реалтайме. Там обычные виртуальные функции. Две другие сборки нужны если точно известно что будет только одно GAPI

innuendo
> Пусть товарищ, скажет сколько у него получилось таких вызовов на один фрейм
я еще не делал, это только мысли как буду делать:). Но поясню. у меня рендер - это голая надстройка над GAPI, в ней нет даже понятия Mesh (более высокоуровневая система - Graphics она абстрактна и от gapi не зависит). То есть большинство методов как раз вида 2+2 (то есть в две-три строчки), так что нужен хороший инлайн, а виртуальные функции и инлайн не всегда вместе.

#40
7:48, 14 июня 2013

war_zes
> То есть большинство методов как раз вида 2+2 (то есть в две-три строчки), так
> что нужен хороший инлайн, а виртуальные функции и инлайн не всегда вместе.
>

Я про колво на кадр спрашиваю ...

#41
8:55, 14 июня 2013

war_zes
> Но поясню. у меня рендер - это голая надстройка над GAPI, в ней нет даже
> понятия Mesh (более высокоуровневая система - Graphics она абстрактна и от gapi
> не зависит). То есть большинство методов как раз вида 2+2 (то есть в две-три
> строчки), так что нужен хороший инлайн, а виртуальные функции и инлайн не
> всегда вместе.

Ну вообще то уже давным давно хороший голый рендер заключается в минимальном вызове батчей за кадр. Буквально - вызовов функций отрисовки. Голые они или обернутые - даже неважно.
Так что да, оптимизация в данном месте уберсомнительная сама по себе, а ввиду того что еще усложняет код - просто вредная.

#42
10:13, 14 июня 2013

=A=L=X=
> Так что да, оптимизация в данном месте уберсомнительная сама по себе, а ввиду
> того что еще усложняет код - просто вредная.
код не усложняется, то есть вообще не изменяется. Усложняются только заголовки за счет дополнительных проверок дефайнов.

#43
13:19, 14 июня 2013

war_zes
> Усложняются только заголовки

Я их и имею ввиду, это же тоже код.

#44
13:45, 14 июня 2013

=A=L=X=
> Я их и имею ввиду, это же тоже код.
У меня заголовки со всеми дефайнами никогда не превышают больше 100 строк (не считая приватного раздела), то есть один класс на один файл, минимум публичных методов (если их становится много, разделение на два класса). так что лишняя пара дефайнов ничего не добавит

Страницы: 1 2 3 4 Следующая »
WarZesФорум

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