При этом шейдер скорее всего будет занимать меньше места чем попытка реализовать что-то подобное на CPU
В общем-то многие из современных демок и являются небольшими программами, которые инициализируют OpenGL/DirectX, и почти весь их объем — один или несколько сложных шейдеров.
К примеру демка из 2010 «elevated» 4кб
вот тут можно посмотреть на ютубе www.youtube.com/watch?v=jB0vBmiTr6o
вот тут портированный на ShaderToy шейдер www.shadertoy.com/view/MdX3Rr
Сам 4кб бинарник можно найти тоже (Windows), только под win10 (и может даже win7) нужно искать пофикшенную версию
Рассмотрим вырожденный пример
Если мы попали в число, которое является степенью двойки, умножим на два. А если не является — уменьшим сразу до 1. Все ли числа уменьшатся до 1 в итоге?
Какая вероятность того что большое число N является степенью двойки? Очень маленькая. И если является, то умножив его на 2 получим еще большее число, которое будет с еще меньшим шансом являться степенью двойки, так?
Не так. Потому что тот факт то что число является степенью двойки изменяет вероятности. И если мы умножим степень двойки на 2, то шанс получить степень двойки оказывается вовсе не случайным событием.
Поэтому то, что «каждое следующее нечетное число будет соответствовать тем же условиям, что и предыдущее» не является фактом и это нужно доказывать. (Кроме того, это еще и не является правдой, судя по всему, только перекос наоборот, в сторону уменьшения)
Такое наблюдение позволяет понять почему «возможно» «большинство» чисел становятся в итоге 1
при этом «возможно» здесь потому что только первая такая операция действительно «случайна», а «случайность» последюущих уже вызывает вопросы
а «большинство» здесь потому что даже маленькая вероятность чего-либо не гарантирует отсутствие таких чисел (к примеру если наивно посчитать вероятность того что число будет простым, то кажется как будто они должны будут кончиться)
Вот в этих то «возможно» и «большинство» и загвоздка
GPU оптимизирована для вычислений с 4-мерными векторами из 32-битных float
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
При счетчике ссылок «платится» за каждую передачу объекта (присваивание, передачу аргументом, и т.п.), тогда как при GC «платится» когда объект переживает сборку мусора (плата, правда, побольше, и зависит от того сколько внутри объекта указателей)
Объекты присваиваются и передаются аргументом намного чаще чем переживают GC.
Плюс, счетчик ссылок очень медленный в случае наличия больше чем одного потока.
Кыштымская авария это не авария на гражданской электростанции
Если под «серьезной аварией» подразумевать «у нас была электростанция, а теперь ее нет, и вместо нее что-то не предусмотренное проектом» то как раз эти три и получаются.
(Нужно обновлять комментарии перед отправкой)
Как такое возможно в хоть сколько-то компетентной архитектуре ММО-игры — ума не приложу.
В общем-то многие из современных демок и являются небольшими программами, которые инициализируют OpenGL/DirectX, и почти весь их объем — один или несколько сложных шейдеров.
К примеру демка из 2010 «elevated» 4кб
вот тут можно посмотреть на ютубе
www.youtube.com/watch?v=jB0vBmiTr6o
вот тут портированный на ShaderToy шейдер
www.shadertoy.com/view/MdX3Rr
Сам 4кб бинарник можно найти тоже (Windows), только под win10 (и может даже win7) нужно искать пофикшенную версию
Реньше накладных расходов не было
Теперь накладные расходы есть
Разница в (1/0) = бесконечность раз
Пойду писать статью: Можно уменьшить время выполнения программы в бесконечность раз! (При условии что программа ничего не делает, правда)
Если мы попали в число, которое является степенью двойки, умножим на два. А если не является — уменьшим сразу до 1. Все ли числа уменьшатся до 1 в итоге?
Какая вероятность того что большое число N является степенью двойки? Очень маленькая. И если является, то умножив его на 2 получим еще большее число, которое будет с еще меньшим шансом являться степенью двойки, так?
Не так. Потому что тот факт то что число является степенью двойки изменяет вероятности. И если мы умножим степень двойки на 2, то шанс получить степень двойки оказывается вовсе не случайным событием.
Поэтому то, что «каждое следующее нечетное число будет соответствовать тем же условиям, что и предыдущее» не является фактом и это нужно доказывать. (Кроме того, это еще и не является правдой, судя по всему, только перекос наоборот, в сторону уменьшения)
при этом «возможно» здесь потому что только первая такая операция действительно «случайна», а «случайность» последюущих уже вызывает вопросы
а «большинство» здесь потому что даже маленькая вероятность чего-либо не гарантирует отсутствие таких чисел (к примеру если наивно посчитать вероятность того что число будет простым, то кажется как будто они должны будут кончиться)
Вот в этих то «возможно» и «большинство» и загвоздка
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
ru.wikipedia.org/wiki/Проблема_остановки
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
При счетчике ссылок «платится» за каждую передачу объекта (присваивание, передачу аргументом, и т.п.), тогда как при GC «платится» когда объект переживает сборку мусора (плата, правда, побольше, и зависит от того сколько внутри объекта указателей)
Объекты присваиваются и передаются аргументом намного чаще чем переживают GC.
Плюс, счетчик ссылок очень медленный в случае наличия больше чем одного потока.
Ассоциативность:
(1e-200*1e200)*1e200 => 1e+200
1e-200*(1e200*1e200) => Infinity
Дистрибутивность:
1e200*(1e200-1e200) => 0
(1e200*1e200)-(1e200*1e200) => NaN
Если под «серьезной аварией» подразумевать «у нас была электростанция, а теперь ее нет, и вместо нее что-то не предусмотренное проектом» то как раз эти три и получаются.
(Нужно обновлять комментарии перед отправкой)