То, что их устройство на порядки примитивнее человеческого мозга, вовсе не означает, что оно у них не может возникать. Хотя бы на момент обработки промпта, подобно Больцмановскому мозгу.
И следует учитывать, что вопросы квалиа и сознания всё ещё остаются открытыми, в частности, вопрос «Что есть сознание?». А если чёткого общепринятого содержания понятия «сознание» нет, то не получится удостовериться, есть ли оно у чего‑то, или его нет.
Хотел тоже недавно начать проект со светодиодными лентами. Только не для домашнего, а для клуба, чтобы музыканта со сцены по MIDI мог управлять светодиодной подсветкой всего клуба (внешней и внутренней).
Интересная штука. Можно даже разделить, чтобы цветовыми сочетаниями управлял человек, а динамика и ритм брались из музыки после некоторых обработок.
@VBDUnit есть вопрос по поводу снятия "скриншота" экрана. Для одного проетка я никак не могу решить задачу получения всего изображения, которое видит пользователь. Суть в том, что некоторые оверлеи не видны на скринах, как бы я не старался. Только через захват всего рабочего стола и только через NVIDIA Shadowplay.
Если ShadowPlay работает, то и OutputDuplication действительно может сработать, но не факт. Иногда он капризничает, хотя с играми всё ок.
Есть предположение, что 5 минут беседы с вами может сэкономить месяц поисков
Возможно, я ошибаюсь, но из текста вырисовывается несколько иная позиция.
Иными словами, столь тщательно выстроенные годами паттерны, абстракции и вообще краеугольные камни ООП — рушатся при распределении нагрузки по всем процессорам. Инкапсуляции из коробки больше нет.
Иными словами, в ООП нет ничего прям плохого, но только пока вы не погрузились в сильно связанный хайлоад. Вот тогда придется написать заново неспецифицированную, глючную и медленную реализацию половины акторной модели². ООП был современной и крайне удобной парадигмой в девяностые, когда многопоточное связанное программирование было уделом фриков. В 2025 эта парадигма всячески сопротивляется распараллеливанию задач, что при современной доступности количества ядер на единицу выполнения кода — халатность, граничащая с преступлением.
То есть не «решение проблем построения многопоточных приложений не входит в круг задач ООП», а «ООП не только не помогает, но и мешает решать задачи построения многопоточных приложений».
Это два разных суждения: в первом случае парадигма ООП имеет, если можно так сказать, нейтральную позицию по отношению к многопоточности, а во втором случае — ярко выраженную негативную позицию — она не «не помогает», она «делает хуже».
Полагаю, у данного срконструктивного обсуждения два корня:
У понятия «ООП» нет единого строгого логически верного определения, с которым согласны все. Разные участники дискуссии подразумевают разное содержание понятия «ООП»
Высоковероятно, что построение многопоточных приложений не входило изначально в круг задач, которые должна была решать парадигма ООП. Подобно тому, как, например, динамика кварков не входит в круг задач, решаемых Общей Теорией Относительности
Исключительно lock free, без мьютексов нельзя сделать некоторые задачи
Само собой. Но там, где требуется повышенная эффективность, лучше делать lock free (при условии, что это не повысит вероятность багов — а в этих штуках они допускаются легко и потом сложно отлавливаются)
Есть ещё вариант сразу писать объект на атомарных операциях так, чтобы он спокойно переносил многопоточное использование. Это не всегда возможно, и, зачастую, сложно, но проблему тоже решает.
Проходил Metro 2033 Exodus Enchanced как раз на 40фпс. Мало, но играть можно. Впрочем, я проходил по стелсу. Если бы рашил — настройки пришлось бы снижать 100%.
Зависит от того, что за игра. Если это онлайн шутер — да, это слайдшоу. Если это сюжетный шутер — просто очень мало. А если это какой‑нибудь квест то норм.
//Не путать с C# - в этом C++
//тип long имеет размер 32 бита
//то есть long здесь это int
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}
Его там юзали для нормализации вектора (т. е. при сохранении направления делаем длину равной 1) при расчёте освещения. Всё это было нужно, чтобы сглаживать переходы между полигонами и делать их малое количество менее заметным.
Полигон плоский, но с помощью нормалей алгоритм визуализации считает затенение так, как будто бы в каждой точке этот полигон повёрнут в немного разные стороны
С выходом C# 10 компилятор научился разбирать $"строка" не напрямую в string, а в handler: структуру, которая получает куски литералов и плейсхолдеры. Базовый – DefaultInterpolatedStringHandler.
string text = $”Значение равно {value}%”;
mew text = (“Значение равно “, value , “%”);
//mew - значимый тип, который хранит фрагменты строки
//в их исходном виде (строки как строки,
//числа — как числа, bool как bool).
//Первые 48 фрагментов хранятся на стеке,
//далее уже идёт аллокация в куче.
Но синтаксис кортежей это просто боль после $"значение:{value}". Теперь же, как я понял, можно к этой штуке прикрутить нормальный синтаксис конкатенации строк.
Вообще странно, что они не сделали сам тип string как-нибудь так, чтобы если строка короткая, то она пыталась бы храниться на стеке. Смысла дёргать кучу из-за текста в 10 букв, имхо, нет.
Ага. Я думаю, это ключевое. Получается, что подобные возможности сами по себе не вшиты в язык, а являются его эмерджентным свойством, которое возникает просто из его концепции и подходов. Это более чем вкусно.
Нет, не подтверждает. Система «чувак с книгой» обладает совокупностью эмерджентных свойств, среди которых может быть (а может и не быть) сознание.
Ну так если
то как можно утверждать, что сознания у чего то нет или есть?
Я про то и говорю — спор об этом, равно как утверждения, что у сетей есть или нет сознания, бессмысленны, пока мы не узнаем, что такое сознание.
Почему Вы так уверены?
То, что их устройство на порядки примитивнее человеческого мозга, вовсе не означает, что оно у них не может возникать. Хотя бы на момент обработки промпта, подобно Больцмановскому мозгу.
И следует учитывать, что вопросы квалиа и сознания всё ещё остаются открытыми, в частности, вопрос «Что есть сознание?». А если чёткого общепринятого содержания понятия «сознание» нет, то не получится удостовериться, есть ли оно у чего‑то, или его нет.
Интересная штука. Можно даже разделить, чтобы цветовыми сочетаниями управлял человек, а динамика и ритм брались из музыки после некоторых обработок.
Если ShadowPlay работает, то и OutputDuplication действительно может сработать, но не факт. Иногда он капризничает, хотя с играми всё ок.
Предлагаю в личке или тг :)
В том то и фокус, что Vist — это структура. Дополнил описание, спасибо.
Хорошая идея, но для начала мне надо причесать код.
Так массив выделится в куче — а весь сыр‑бор как раз чтобы избегать этого.
Возможно, я ошибаюсь, но из текста вырисовывается несколько иная позиция.
То есть не «решение проблем построения многопоточных приложений не входит в круг задач ООП», а «ООП не только не помогает, но и мешает решать задачи построения многопоточных приложений».
Это два разных суждения: в первом случае парадигма ООП имеет, если можно так сказать, нейтральную позицию по отношению к многопоточности, а во втором случае — ярко выраженную негативную позицию — она не «не помогает», она «делает хуже».
Полагаю, у данного
срконструктивного обсуждения два корня:У понятия «ООП» нет единого строгого логически верного определения, с которым согласны все. Разные участники дискуссии подразумевают разное содержание понятия «ООП»
Высоковероятно, что построение многопоточных приложений не входило изначально в круг задач, которые должна была решать парадигма ООП. Подобно тому, как, например, динамика кварков не входит в круг задач, решаемых Общей Теорией Относительности
Спасибо!
Само собой. Но там, где требуется повышенная эффективность, лучше делать lock free (при условии, что это не повысит вероятность багов — а в этих штуках они допускаются легко и потом сложно отлавливаются)
Есть ещё вариант сразу писать объект на атомарных операциях так, чтобы он спокойно переносил многопоточное использование. Это не всегда возможно, и, зачастую, сложно, но проблему тоже решает.
О! Очень круто, не знал)
Проходил Metro 2033 Exodus Enchanced как раз на 40фпс. Мало, но играть можно. Впрочем, я проходил по стелсу. Если бы рашил — настройки пришлось бы снижать 100%.
Интересно, в нейросетях такое как раз актуально. По идее в видеокартах неплохо бы сделать аппаратную инструкцию для вот такой вот быстрой экспоненты.
Спасибо :)
Попробуйте поиграть в онлайн шутер с 24 фпс
Зависит от того, что за игра. Если это онлайн шутер — да, это слайдшоу. Если это сюжетный шутер — просто очень мало. А если это какой‑нибудь квест то норм.
Спасибо!)
Да, там был быстрый обратный квадратный корень
Его там юзали для нормализации вектора (т. е. при сохранении направления делаем длину равной 1) при расчёте освещения. Всё это было нужно, чтобы сглаживать переходы между полигонами и делать их малое количество менее заметным.
Это просто шикарно!
У меня тоже была проблема с аллокациями в логах, и решал я её как-то так:
Но синтаксис кортежей это просто боль после $"значение:{value}". Теперь же, как я понял, можно к этой штуке прикрутить нормальный синтаксис конкатенации строк.
Вообще странно, что они не сделали сам тип string как-нибудь так, чтобы если строка короткая, то она пыталась бы храниться на стеке. Смысла дёргать кучу из-за текста в 10 букв, имхо, нет.
Ага. Я думаю, это ключевое. Получается, что подобные возможности сами по себе не вшиты в язык, а являются его эмерджентным свойством, которое возникает просто из его концепции и подходов. Это более чем вкусно.
Ушел смотреть интерпретаторы Лиспа для.NET :)