GPU оптимизирована для вычислений с 4-мерными векторами из 32-битных float
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
При счетчике ссылок «платится» за каждую передачу объекта (присваивание, передачу аргументом, и т.п.), тогда как при GC «платится» когда объект переживает сборку мусора (плата, правда, побольше, и зависит от того сколько внутри объекта указателей)
Объекты присваиваются и передаются аргументом намного чаще чем переживают GC.
Плюс, счетчик ссылок очень медленный в случае наличия больше чем одного потока.
Кыштымская авария это не авария на гражданской электростанции
Если под «серьезной аварией» подразумевать «у нас была электростанция, а теперь ее нет, и вместо нее что-то не предусмотренное проектом» то как раз эти три и получаются.
(Нужно обновлять комментарии перед отправкой)
В одноядерной системе нет понятия «неблокирующее многопоточное программирование»
Коллизии легко избегаются потому что есть специальная атомарная инструкция en.wikipedia.org/wiki/Compare-and-swap (я именно это имел в виду под «в cpu есть атомарные инструкции по работе с ними»)
Порядок действий если надо вставить элемент между a и b (a->b):
— Создаем новый элемент c (никто о нем не знает, так что синхронизироваться не нужно)
— Выставляем указатель c -> b
— если a все еще a->b то меняем указатель a->c (через compare-and-swap), иначе кто-то влез перед нами и надо что-то передумать или просто повторить
Есть одна область в которой односвязные списки критически необходимы — неблокирующая многопоточность
связный список это единственная структура данных динамического размера, операции с которой требуют изменение лишь одного указателя (т.е. и до и после изменения указателя структура в корректном состоянии), а в cpu есть атомарные инструкции по работе с ними
Если в задаче используется только сложение, вычитание и умножение — то да.
Но тогда можно просто использовать fixed-point, будет больше бит чем мантисса, и быстрее.
Лично мне кажется более интересным третий подход, когда тип (указатель на табличку с методами) хранится прямо в указателе.
Если мы говорим о языке, то где хранятся типы объектов не должно влиять на язык.
Если же мы говорим о деталях реализации, то у такого подхода есть проблемы. Во-первых, указателей на объект больше чем объектов. Во-вторых, указатели на объекты гораздо чаще перемещаются в памяти, а это означает всякие сопутствующие проблемы вроде того что передача указателей в функцию занимает больше регистров и меньше параметров можно передать через регистры и т.п.
Но самая концептуальная проблема в том, что такие указатели (являющиеся по сути структурами) становятся неатомарными в смысле многопоточного доступа. Что фактически ставит крест на «низкоуровневой» многопоточности.
(Или нужна система как упаковать 2 указателя в одно машинное слово, это в принципе можно сделать в 64 битной системе, но тогда это означает что указатель придется «распаковывать» при каждом доступе)
Если будет «приемник-передатчик на халявной энергии» то можно будет на его основе двигатели получше керосинки сделать т.к. закон сохранения энергии не соблюдается
А если будет соблюдаться то т.к. на Венере потенциальной энергии гравитационного поля Солнца меньше, то атмосфера потечет в обратном направлении (Марс->Венера) т.к. эта разница больше чем давление
Основное место на кристалле занимают регистры (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
Если под «серьезной аварией» подразумевать «у нас была электростанция, а теперь ее нет, и вместо нее что-то не предусмотренное проектом» то как раз эти три и получаются.
(Нужно обновлять комментарии перед отправкой)
Коллизии легко избегаются потому что есть специальная атомарная инструкция en.wikipedia.org/wiki/Compare-and-swap (я именно это имел в виду под «в cpu есть атомарные инструкции по работе с ними»)
Порядок действий если надо вставить элемент между a и b (a->b):
— Создаем новый элемент c (никто о нем не знает, так что синхронизироваться не нужно)
— Выставляем указатель c -> b
— если a все еще a->b то меняем указатель a->c (через compare-and-swap), иначе кто-то влез перед нами и надо что-то передумать или просто повторить
связный список это единственная структура данных динамического размера, операции с которой требуют изменение лишь одного указателя (т.е. и до и после изменения указателя структура в корректном состоянии), а в cpu есть атомарные инструкции по работе с ними
Но тогда можно просто использовать fixed-point, будет больше бит чем мантисса, и быстрее.
Если мы говорим о языке, то где хранятся типы объектов не должно влиять на язык.
Если же мы говорим о деталях реализации, то у такого подхода есть проблемы. Во-первых, указателей на объект больше чем объектов. Во-вторых, указатели на объекты гораздо чаще перемещаются в памяти, а это означает всякие сопутствующие проблемы вроде того что передача указателей в функцию занимает больше регистров и меньше параметров можно передать через регистры и т.п.
Но самая концептуальная проблема в том, что такие указатели (являющиеся по сути структурами) становятся неатомарными в смысле многопоточного доступа. Что фактически ставит крест на «низкоуровневой» многопоточности.
(Или нужна система как упаковать 2 указателя в одно машинное слово, это в принципе можно сделать в 64 битной системе, но тогда это означает что указатель придется «распаковывать» при каждом доступе)
А если будет соблюдаться то т.к. на Венере потенциальной энергии гравитационного поля Солнца меньше, то атмосфера потечет в обратном направлении (Марс->Венера) т.к. эта разница больше чем давление