Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Поговорим об отложенных(ленивых) вычислениях (4 стр)

Поговорим об отложенных(ленивых) вычислениях (4 стр)

Поделиться

Страницы: 1 2 3 4

SuslikМодераторwww27 окт. 201713:46#45
nonamezerox
> И вот тут я чего-то вспоминаю байтофобов с их "компилятор сделает лучше
> человека" и "да не нужно париться о низкоуровневых вещах - компилятор все
> сделает хорошо", "да задрачивать на низком уровне
> (асм/интринсики/__forceinline) реализацию не нужно - решает выбор алгоритма" и
> на выходе традиционное  "Core i7 и 64GB хватит каждому для запуска
> HelloTriangle"
кстати, прекрасный пример. что бы сделал любой уважающий себя байтофил на моём месте в первую очередь? правильно, бросился писать супероптимизированные векторизованные вручную AddMatrix(), MulMatrix() и компанию. и результат бы получился в итоге медленнее моего велосипеда из-за одного лишь паттерна доступа к памяти в длинных цепочках вычислений. как уже сказали выше, интринсиками имеет смысл обмазываться не раньше того, как ты будешь полностью уверен, что алгоритмическая часть 100% оптимальна. а этого, вопреки фантазиям байтофилов, не бывает почти никогда. а asm-выхлоп я уж всегда могу проверить, чтоб убедиться, что компилятор совсем уж не накосячил.

Правка: 27 окт. 2017 13:46

eagleПостоялецwww27 окт. 201716:01#46
Suslik
> от реализации этого самого кастомного аллокатора зависит слишком много
Его можно прозрачно подменить через параметр шаблона. Для небольших матриц всегда быстрее чем стандартная куча.

> в своей реализации я заметил, что замена inline на __forceinline увеличивает
> производительность
Контекст вызова с expression templates довольно сложный. Поэтому компилятор как правило inline встроить не может. Собственно анализ asm'а это подтверждает. С __forceinline берем все на себя если понимаем, что делаем.

> смотрю, ты тоже с этим успел повоевать. каковы впечатления?
С такими прагмами удалось добиться максимального инлайна. Но это в основном для анроллов. Отключение любой из pragm снижало производительность на VS в тестах (лет 5 назад).

> как влияют анроллы на время компиляции и на размер бинарника?
Для векторов и небольших матриц 4x4 вообще не критично. Для графических приложений использую вовсю.

> ты сравнивал результирующую производительность с ручным написанием циклов
> оптимальным образом?
Да. Руками написанные циклы быстрее, только если у компилятора получается векторизовать. Но это вообще от фазы луны зависит. Лучше интринсиками. Есть древний топик http://www.gamedev.ru/code/forum/?id=50087 где все это жевали.

> твоя реализация умеет в рантайм размер матриц?
Эта с гитхаба как раз для того чтоб было все в compile time и на стеке.
Для рантайм у меня другая реализация, про которую упоминал выше с expression templates, COW, move constructors, custom allocator.

FordPerfectПостоялецwww27 окт. 201717:29#47
Suslik
Мне тоже интересно про GCC.
Пробовал сравнивать как там с инлайном?
То, что в студии эвристики inline не срабатывают - странно, код вроде совсем влобный.
Ты за 256 уровней не вылетаешь, из-за шаблонов?
FordPerfectПостоялецwww27 окт. 201717:46#48
>http://www.gamedev.ru/code/forum/?id=50087
Да, там есть полезные измерения.

>супероптимизированные векторизованные вручную AddMatrix(), MulMatrix()
подразумеваются как низкоуровневые блоки. Которые не мешают строить алгоритмически более продвинутые вещи.

>алгоритмическая часть 100% оптимальна
Звучит так, как будто ты считаешь, что умножение матриц - алгоритмически solved problem.
Ну можно матрицы множить за O(n2+ɛ), для произвольно малого положительного ɛ, пользы с этого?
Там всё-ещё всякое интересное творится.

Ради интереса - пробовал сравнивать свои блоки с чем-то приличным, типа OpenBLAS, которое выжимает более 90% теоретически достижимых FLOPS (я про низкоуровневую часть)?
Там, насколько я понимаю, побольше интересного, чем "компилятор савтовекторизует". Или наивной SIMD-ификации на ручками.

return [](){};Участникwww18 ноя. 201713:59#49
Со скуки накрафтил версию на D, правда для векторов:
https://wandbox.org/permlink/q1CoKKCVS5b2hbmk
В отличии от крестоподелок, генерируется плоская функция, которую еще и посмотреть можно в читабельном виде.

Правка: 18 ноя. 2017 14:01

Страницы: 1 2 3 4

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр