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

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

Поделиться

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

MrShoorУчастникwww26 окт. 201723:52#15
return [](){};
Оп оп. Статик ассерт подъехал. Круть. Плюс в копилку D

upd. А как-нибудь просто заэмбедить компилятор там случайно нельзя? Если бы было можно - можно было бы простенькую обвязку написать для эмуляции шейдеров софтверно!

Правка: 26 окт. 2017 23:54

return [](){};Участникwww26 окт. 201723:55#16
Нормальная версия с циклом
http://rextester.com/ESH59475
return [](){};Участникwww26 окт. 201723:58#17
MrShoor
  • Есть такое, раз: http://rextester.com/ZOWDP5369
  • Работаем над таким, два: http://www.gamedev.ru/flame/forum/?id=220707
  • jaguardУчастникwww27 окт. 20170:00#18
    Я когда-нибудь потом о них поговорю.
    return [](){};Участникwww27 окт. 20170:00#19
    Забыл, такое, три: https://github.com/libmir/dcompute
    MrShoorУчастникwww27 окт. 20170:36#20
    return [](){};
    > Работаем над таким, два
    Маньяки. D прям вырос в моих глазах.
    А ты чтоль контрибьютишь в D?
    SuslikМодераторwww27 окт. 20173:35#21
    Alexander K
    > Быстрым гуглением готовую либу с таким функционалом на rust не нашёл, но
    > кажется, что его можно реализовать без проблем. Например там в стандартной либе
    > есть итераторы с ленивыми преобразованиями, которые разворачиваются в
    > без-оверхедный код.
    Да, мне тоже казалось, что раст должен хорошо с такими делами рулить. Но у плюсов такой код не просто инлайнится, а он ещё и автоматически векторизуется оптимизатором на SSE. Как у раста дела с этим?

    eagle
    > https://github.com/highwatt/lazymatrix 
    Во-первых, у меня кода в 3 раза меньше. Во-вторых, у меня поддерживаются inplace операции вроде +=, *=. Но всё равно очень интересно почитать, как люди это делают, потому что я сделал совсем не так.

    kipar
    > Но для больших матриц рекурсивный алгоритм со сложностью O(n^2.8) будет сильно
    > быстрее влобного умножения за O(n^3)
    Именно это я предусмотрел следующим образом. Выражение вычисляется непосредственно перед присваиванием. и если умножение — последняя операция в стеке обратной польской нотации, то умножение выполняется по быстрому алгоритму. то есть для

    a = b * c + d
    и для
    a = b * c;
    a += d;
    сгенерится разный код. в первом случае сгенерится код по типу
    for(row =..)
      for(column =..)
        a.Get(row, column) = b.GetRow(row) * c.GetColumn(column) + d.Get(row, column); //здесь скалярное произведение векторов

    То есть строки помножатся на столбцы за O(n), суммарная сложность — O(n^3).
    Во втором случае код развернётся в
    FastMult(b, c, a);
    for(row =..)
      for(column =..)
        a.Get(row, column) += d.Get(row, column);
    то есть суммарная сложность будет O(n ^ 2.8) + O(n ^ 2) = O(n ^ 2.8). Моей основной целью было сделать код использования библиотеки максимально предсказуемым, читаемым и явным. Но, признаю, в этом месте происходит implicit choice.

    *Lain*
    > Мув даёт экономию по памяти, но не даёт леаниризации вычислений
    именно так.

    MrShoor
    > И чтобы разбраться что за говно творится под низом - нужно лезть в исходный код
    > библиотеки, или курить тонну манулов.
    основная проблема моей либы, я считаю, случается, если код не компилируется. например, если написать:

    a + b = c + d;
    то он выплюнет гигантскую ошибку о том, что нет оператора присваивания для монструозной компайлтайм штуки. Или если забыть взять Proxy от матрицы и попытаться просто прибавить матрицу к матрице — пользователю может показаться это действие интуитивным, но вся суть в том, что оно по идее порождает промежуточный объект, поэтому я его в явном виде запретил. Для этого и нужны все auto и GetProxy(). То есть любой код, который скомпилируется, гарантированно не порождает временных объектов и гарантированно выполняется за один внешний цикл по всем элементам. Проблемы начинаются, если код по каким-то причинам не компилируется и необходимо понять, по каким. Я считаю это одним из основных недостатков плюсового метапрограммирования и не умею с ним бороться.

    all
    Код выкладывать пока не планирую, потому что не считаю, что обладаю достаточными навыками в метапрограммировании. Эту штуку писал для себя как эксперимент и для целей самообучения. Несмотря на то, что в существующих решениях вроде eigen есть существенные недостатки(неявность, хоть это и спорно. монструозный размер), над ними работают гораздо более шаристые люди и они объективно лучше. Поэтому обсудить бы хотелось в первую очередь реализацию таких же штук на других языках и другими людьми, сравнить.

    Правка: 27 окт. 2017 3:35

    MrShoorУчастникwww27 окт. 20173:53#22
    Suslik
    > Я считаю это одним из основных недостатков плюсового метапрограммирования и не
    > умею с ним бороться.
    Это нормально. Никто не умеет. Считаю что выложить все таки стоит, потому что годные велосипеды могут быть доработаны публикой + могут подсказать, что "если сделать вот так и так, то компилятор выдаст сообщение на 5% понятнее". Алсо это будет мотивацией велосипедить на других ЯП.
    loysoПостоялецwww27 окт. 20177:35#23
    Suslik
    Непринципиально, чисто ясности ради:
    Это Proxy Object по Скоту Мейерсу, да. (Который бывает rvalue и lvalue)
    А ленивые вычисления - это call-by-need lambda calculus и graph reduction machine, совсем другая история.

    Правка: 27 окт. 2017 8:00

    loysoПостоялецwww27 окт. 20177:50#24
    Suslik
    > Поэтому обсудить бы хотелось в первую очередь реализацию таких же штук на
    > других языках и другими людьми, сравнить.
    Proxy-Object - очень низкоуровневая идиома, специфичная для mainstream процедурных языков с объектами.
    Если брать ООП в широком смысле слова то Proxy Object - это такой shallow copy исходного объекта. И далее можно говорить о всяких Copy-on-write поведениях, sharing подгруппы данных, делегировании и т.д.
    SuslikМодераторwww27 окт. 20178:01#25
    loyso
    > Непринципиально, чисто ясности ради:
    > Это Proxy Object по Скоту Мейерсу, да. (Который бывает rvalue и lvalue)
    это название я сам придумал и любые совпадения чисто случайны. в смысле я не удивлён, что кто-то ещё их так же назвал, но это — просто особенность моей реализации lazy maths.

    loyso
    > А ленивые вычисления - это call-by-need labmda calculus и graph reduction
    > machine, совсем другая история.
    а вот lazy maths — это вполне себе стандартный термин(не мой): https://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html , http://xtensor.readthedocs.io/en/latest/

    ещё, почитав статьи по expression templates (спасибо тем, кто подсказал, как это называется), прихожу к выводу, что моя реализация — не такая уж страшная :D

    Правка: 27 окт. 2017 8:02

    loysoПостоялецwww27 окт. 20178:25#26
    Suslik
    > lazy maths — это вполне себе стандартный термин(не мой)
    В математике под ленивостью другое понимают.
    Но спорить о терминах - неинтересно. Есть разные группы людей, которые вкладывают разное.
    Главное - какую проблему и задачу решаем.
    loysoПостоялецwww27 окт. 20178:29#27
    Suslik
    > expression templates
    Ну это уже шажок к C# expression trees, Lisp S-expressions, EDSL интерпретаторам, the evaluation as a 1st class object и Монадам через редукцию графов.
    Другая история.
    SuslikМодераторwww27 окт. 20178:58#28
    буст перед использованием обычных матричных операций огромен. на выражении m3 = (m1 + m2 * 2.0f) * 2.0f и матрицах размером 500x500  разница между отложенным кодом и immediate кодом вроде ((m2 += 2.0f) += m1) *= 2.0f; составляет примерно 1:2. то есть разница в два раза по скорости только из-за разного паттерна доступа к памяти, так как общее количество операций строго одинаковое и объём памяти используется идентичный.

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

    Правка: 27 окт. 2017 8:59

    return [](){};Участникwww27 окт. 201710:27#29
    Извините, что опять врываюсь

    MrShoor
    > А ты чтоль контрибьютишь в D?
    Да, есть немного.

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

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

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