верно, когда смотрели этот код с коллегами, тоже обратили внимание на это, написали тогда репорт на форуме Нинтендо об этом, особой реакции не было. Надеюсь в последних версиях сдк и версию компилятора подняли, и часть багов поправил
Если вы откроете асм с -03, то скорее всего окажется что компилятор заменил ваш strlen на векторизованный вариант, оптимальный для данного CPU. Не стоит считать себя умнее компилятора, а ещё лучше использовать пикс для поиска таких мест, оптимизация "глазами" лет 20 как малоэффективна
Вам уже на dtf накидали минусов с указанием ошибок в рассуждениях, и общего качества материала, как будто написанного ЧатГпт. Пишите лучше код и игры, познавайте разные методы на практике, тогда на такое не останется времени ;)
Совсем не новый, Александреску предлагал подобную реализацию ещё в 2012 году, но самого кода не было. Мне интересно было это все руками сделать, а не тащить с гитхаба
По опыту использования в разных проектах подбираем от сложности вычислений * количество тредов, также неплохо ведут себя ожидания с простыми числами, бэкофф ожидание тоже неплохо себя показало
верно, операция в общей области памяти называется атомарной, если она завершается в один шаг относительно других потоков, имеющих доступ к этой памяти. Во время выполнения такой операции над переменной, ни один поток не может наблюдать изменение наполовину завершенным. Но сама операция может состоять из нескольких шагов, атомарность гарантируется соглашением между разработчиком компилятором и производителем железа. Более того инструкция процессора тоже может быть разбита на шаги и неатомарна. Например запись 64 битного числа может быть реализована как запись старшего/младшего состояния и без поток прочитал состояние между ними
Хороший пример, надо будет написать тестов и посмотреть. Я заметил ниже коварный SDL_Delay(0) -> Sleep(0), который в худшем случае выкинет тред в планировщик с неопределенным временем возврата обратно, не было проблем с этим? одинаковые числа лучше не крутить, какое-нибудь exponent backoff wait даст лучший результат
да, есть комбинированные подходы, например подождать 5к циклов на спинлоке, а потом уже уходить в мютекс, на плойке он дает лучший результат чем использование системного мютекса, но использование сисколов стараются стараются избегать изза их дороговизны. Платформы предоставляют хорошую документацию, но все таки они остаются черными ящиками, из недавних примеров на живой ps5 велосипед memcpy на AVX регистрах до 16кб выигрывает примерно 2х перед crt реализацией, к 32кб они сравниваются, дальше уже выигрывает реализация в ОС
мютексы в пределенных видах приложений (например игровые движки) использовать очень дорого, время блокировки мютекса составляет 10-15к циклов процессора, да еще и гарантированный вызов в ядро. Зачастую дешевле и быстрее подождать ресурс в спинлоке
переделывал пару проектов для IoT, где "умные" индусы (реально индусы) затащили v8 в железо с 8mb ram, оно там жило примерно 2-3 часа и умирало на номем. А использовали железку для опроса датчиков движения в помещении. Походил по форумам нашел mujs, понравилось
Если не хватает денег и желания на P4, то сидят на svn, или разных связках svn(content) + git(sources), cvs + git. Как бы нибыл хорош git он ужасен для сырого большого контента, с gitlfs тоже танцев хватает. Да и поддерживать репо в пару терабайт контента с гитом то еще удовольствие
вероятно это все профдеформация, я надеялся, что хоть какое-то «код-ревью» они проходят перед отправкой, иначе это действительно просто спам. Я могу ошибаться, т.к. плохо знаком с методами работы HR
Практическая гидроакустика очень капризная, на глубинах до 5 метров температура очень рвано меняется, обычные измерения это не показывают, но запросто может быть температурная «яма» на отдельном участке, которую непросто обнаружить. Плюс сильный эффект от волн на поверхности, реальные дальности распространения звука на таких глубинах не больше 50-150 метров, в дождь или хоть какое-то слабое волнение «увидеть» чтото вообще нереально. А еще есть еффект тунелирования внутри звукового канала на сверхвысоких частотах (10кГц), тоже очень интересный эффект которым занималось в союзе несколько НИИ
Жизнь — она разная, вероятно будь возможность попробовать систему в реале и увидев такое поведение в начале разработки, мы бы сейчас это не обсуждали :) Но с другой стороны посмотрите на современные SoC, в 90% они содержат гпу, который занимает до половины площади чипа, и не пользоваться им значит лишать себя значительной части доступных ресурсов, забирая их у цпу. А разве рендерить чтото на экран это не прямое назначение гпу, освободив ресурсы для нужных задач? пусть даже это и UI
верно, когда смотрели этот код с коллегами, тоже обратили внимание на это, написали тогда репорт на форуме Нинтендо об этом, особой реакции не было. Надеюсь в последних версиях сдк и версию компилятора подняли, и часть багов поправил
Если вы откроете асм с -03, то скорее всего окажется что компилятор заменил ваш strlen на векторизованный вариант, оптимальный для данного CPU. Не стоит считать себя умнее компилятора, а ещё лучше использовать пикс для поиска таких мест, оптимизация "глазами" лет 20 как малоэффективна
Вам уже на dtf накидали минусов с указанием ошибок в рассуждениях, и общего качества материала, как будто написанного ЧатГпт. Пишите лучше код и игры, познавайте разные методы на практике, тогда на такое не останется времени ;)
У вас случаем комната 101 не появилась, и двухминутки ненависти?
Есть такое, но она работает от 17 плюсов, в конце написал про нее. Интересно же понять самому как оно работает
Совсем не новый, Александреску предлагал подобную реализацию ещё в 2012 году, но самого кода не было. Мне интересно было это все руками сделать, а не тащить с гитхаба
Верно, но надо проверить, чето я забыл потестировать это :(
По опыту использования в разных проектах подбираем от сложности вычислений * количество тредов, также неплохо ведут себя ожидания с простыми числами, бэкофф ожидание тоже неплохо себя показало
на x86 32-битная операция mov атомарна в том случае, когда операнд в памяти выровнен, и не атомарна если не выровнена
верно, операция в общей области памяти называется атомарной, если она завершается в один шаг относительно других потоков, имеющих доступ к этой памяти. Во время выполнения такой операции над переменной, ни один поток не может наблюдать изменение наполовину завершенным. Но сама операция может состоять из нескольких шагов, атомарность гарантируется соглашением между разработчиком компилятором и производителем железа. Более того инструкция процессора тоже может быть разбита на шаги и неатомарна. Например запись 64 битного числа может быть реализована как запись старшего/младшего состояния и без поток прочитал состояние между ними
Хороший пример, надо будет написать тестов и посмотреть. Я заметил ниже коварный SDL_Delay(0) -> Sleep(0), который в худшем случае выкинет тред в планировщик с неопределенным временем возврата обратно, не было проблем с этим?
одинаковые числа лучше не крутить, какое-нибудь exponent backoff wait даст лучший результат
да, есть комбинированные подходы, например подождать 5к циклов на спинлоке, а потом уже уходить в мютекс, на плойке он дает лучший результат чем использование системного мютекса, но использование сисколов стараются стараются избегать изза их дороговизны. Платформы предоставляют хорошую документацию, но все таки они остаются черными ящиками, из недавних примеров на живой ps5 велосипед memcpy на AVX регистрах до 16кб выигрывает примерно 2х перед crt реализацией, к 32кб они сравниваются, дальше уже выигрывает реализация в ОС
мютексы в пределенных видах приложений (например игровые движки) использовать очень дорого, время блокировки мютекса составляет 10-15к циклов процессора, да еще и гарантированный вызов в ядро. Зачастую дешевле и быстрее подождать ресурс в спинлоке
переделывал пару проектов для IoT, где "умные" индусы (реально индусы) затащили v8 в железо с 8mb ram, оно там жило примерно 2-3 часа и умирало на номем. А использовали железку для опроса датчиков движения в помещении. Походил по форумам нашел mujs, понравилось
да не очень и тяжелый, https://mujs.com/
их vm занимает примерно 145кб рантайма, сделан специально под ембед платформы
все плюшки js в наличии
Если не хватает денег и желания на P4, то сидят на svn, или разных связках svn(content) + git(sources), cvs + git. Как бы нибыл хорош git он ужасен для сырого большого контента, с gitlfs тоже танцев хватает. Да и поддерживать репо в пару терабайт контента с гитом то еще удовольствие