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

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

Поделиться

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

Alexander KПостоялецwww27 окт. 201710:41#30
Suslik
> Но у плюсов такой код не просто инлайнится, а он ещё и автоматически
> векторизуется оптимизатором на SSE. Как у раста дела с этим?
Пока что оптимизация целиком отдана на откуп LLVM, а он, очевидно, умеет SSE. Но что в данном конкретном случае получится - не знаю, попробую написать как будет время.
eagleПостоялецwww27 окт. 201710:55#31
Suslik
> Во-первых, у меня кода в 3 раза меньше. Во-вторых, у меня поддерживаются
> inplace операции вроде +=, *=. Но всё равно очень интересно почитать, как люди
> это делают, потому что я сделал совсем не так.
Кода много там из-за анролла циклов. +=, *= то же есть. Спрашивай, это моя поделка.

Suslik
> Или если забыть взять Proxy от матрицы и попытаться просто прибавить матрицу к
> матрице — пользователю может показаться это действие интуитивным, но вся суть в
> том, что оно по идее порождает промежуточный объект, поэтому я его в явном виде
> запретил
В отличии от ссылки на гитхаб у меня есть еще реализация "ленивых" матриц с кастомным аллокатором на куче. В ней proxy спрятаны внутри реализации и не видны пользователю. Фактически это аналог COW строк (copy-on-write).

SuslikМодераторwww27 окт. 201711:25#32
eagle
> В отличии от ссылки на гитхаб у меня есть еще реализация "ленивых" матриц с
> кастомным аллокатором на куче. В ней proxy спрятаны внутри реализации и не
> видны пользователю.
по-моему, у любого синтаксического сахара есть граница, которую нельзя пересекать: он никогда не должен делать того, чего от него не ждут. и в случае создания временных объектов, пусть и с кастомным аллокатором, от реализации этого самого кастомного аллокатора зависит слишком много. мне эт не нравится.

eagle
> Спрашивай, это моя поделка.
в своей реализации я заметил, что замена inline на __forceinline увеличивает производительность на 50% приблизительно. вопрос: какого чёрта? у тебя в реализации я заметил такое:

#  pragma inline_depth( 255 )
#  pragma inline_recursion( on )
#  pragma auto_inline( on )
#  define inline __forceinline
смотрю, ты тоже с этим успел повоевать. каковы впечатления?

у меня размер матриц неизвестен в компайлтайме, поэтому с анроллами я не парился. как влияют анроллы на время компиляции и на размер бинарника? твоя реализация умеет в рантайм размер матриц?

#define SCALAR(type) \
template<>\
class Argument<const type> {\
const type arg_;\
...
буэ я до такого не опускался. вроде, удалось особо код не копипастить.

ещё вопрос. ты сравнивал результирующую производительность с ручным написанием циклов оптимальным образом? хватает ли у оптимизатора ума сгенерить идентичный код, либо есть какая-то разница?

Правка: 27 окт. 2017 11:37

innuendoПостоялецwww27 окт. 201711:28#33
Suslik
> в своей реализации я заметил, что замена inline на __forceinline увеличивает
> производительность на 50% приблизительно. вопрос: какого чёрта?

конечно же, нужно сравнивать асмвыхлоп

SuslikМодераторwww27 окт. 201711:30#34
innuendo
> конечно же, нужно сравнивать асмвыхлоп
спасибо, кэп. вопрос в том, почему, согласно асмвыхлопу, разница между inline и __forceinline вообще есть и почему она не в пользу inline, когда обычно компилятор умнее меня?
loysoПостоялецwww27 окт. 201711:36#35
Suslik
> разница между inline и __forceinline
Зависит от баланса оптмизации for size vs for speed. /O3 пробовал?
innuendoПостоялецwww27 окт. 201711:48#36
Suslik
> вопрос в том, почему, согласно асмвыхлопу, разница между inline и
> __forceinline вообще есть и почему она не в пользу inline, когда обычно
> компилятор умнее меня?

кэп, ну не всегда inline делается при inline

всё-таки покажи асмвыхлоп

Правка: 27 окт. 2017 11:49

MrShoorУчастникwww27 окт. 201711:50#37
innuendo
> кэп, ну не всегда inline делается при inline
У суслика как бы другой вопрос. Почему компилятор не сделал inline сам, ведь если заставить его сделать с помощью __forceinline, то выходит намного быстрее.
SuslikМодераторwww27 окт. 201711:50#38
loyso
> Зависит от баланса оптмизации for size vs for speed. /O3 пробовал?
в том-то и дело, что ни /Ox(Full Optimization), ни /Ob2(Inline Function Expansion: Any Suitable), ни /Ot(Favor Fast Code) не помогают. Вызовы упорно не инлайнятся до тех пор, пока я не скажу __forceinline и это совершенно неиллюзорно сказывается на производительности.
loysoПостоялецwww27 окт. 201711:53#39
Suslik
> Вызовы упорно не инлайнятся до тех пор
Знакомая проблема. Обычно делают дополнительный уровень косвенности ALWAYS_INLINE и дело с концом.

Правка: 27 окт. 2017 11:57

innuendoПостоялецwww27 окт. 201712:10#40
MrShoor
> Почему компилятор не сделал inline сам

обратитесь к логике человека писавшего компилятор, ну дети, ей богу :)

nonamezeroxПостоялецwww27 окт. 201712:25#41
И вот тут я чего-то вспоминаю байтофобов с их "компилятор сделает лучше человека" и "да не нужно париться о низкоуровневых вещах - компилятор все сделает хорошо", "да задрачивать на низком уровне (асм/интринсики/__forceinline) реализацию не нужно - решает выбор алгоритма" и на выходе традиционное  "Core i7 и 64GB хватит каждому для запуска HelloTriangle"
kiparПостоялецwww27 окт. 201712:35#42
Suslik
> /Ob2(Inline Function Expansion: Any Suitable)
а, так ты в студии проверял. А компилятором не пробовал?

Правка: 27 окт. 2017 12:49

MrShoorУчастникwww27 окт. 201712:39#43
nonamezerox
> решает выбор алгоритма
Но алгоритм таки решает в первую очередь. Когда был O(n^2), а потом внезапно стал O(n), то уже при n > 50 алгоритм может дать такой буст, что никакая супероптимизация старого O(n^2) и рядом не валялась.
> да задрачивать на низком уровне (асм/интринсики/__forceinline) реализацию не нужно
А вот на низком уровне реализацию нужно задрачивать в последнюю очередь, когда все сделал на высоком. И задрачивать нужно далеко не везде, а только в узких местах.
innuendoПостоялецwww27 окт. 201713:44#44
nonamezerox
> И вот тут я чего-то вспоминаю байтофобов с их "компилятор сделает лучше
> человека" и "да не нужно париться о низкоуровневых вещах - компилятор все
> сделает хорошо", "да задрачивать на низком уровне
> (асм/интринсики/__forceinline) реализацию не нужно - решает выбор алгоритма"

80/20

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

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

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