Писать код, который не поймет ИИ. У меня например куча асинхронщины, подписки на события и тд, разобраться в этом можно только с самодельным визуальным отладчиком. А если еще почаще кидать исключения и ловить их на глубине в 10-20 вызовов, то вообще никто не разберется, что там происходит.
Стоит с телефона в дефолтном браузере поискать кухни, так сразу раздается звонок с предложениями. А тут БПЛА от обычного пользователя все никак не могут отличить.
Я находил что у двух производителей есть проблема, когда видеокарта фиксируется на 210МГц и все тормозит, мне хоть повезло и само восстановилось через неделю. Проблема с WiFi вообще массовая, даже дешевый USB адаптер лучше. Еще сильно греется при подключении к USB-C прямо под рукой.
Двухканальная DDR5-8000 это всего 128Гб/с, на 52 ядра это 2.5ГБ/с. Если кто-то сможет распределить задачи на столько ядер.
Кстати, текстуры в играх используются не процессором, они перегоняются с диска на ГПУ через ЦП, а объемы данных такие, что кэш никак не поможет. Если скорость PCI-E около 64ГБ/с, то половина пропускной способности памяти будет уходить на подгрузку открытых миров.
Сейчас не так важно что за SIMD 128-512 поддерживается, так как в железе может быть 4х 128битных пайплайна, то есть 4 инструкции выполняются параллельно. Такое сделано например на Intel E-ядрах и Cortex X4. А на AMD Zen4 был SIMD256 dual issue для эмуляции SIMD512 пока они не сделали полноценные 512 бит на Zen5.
У ЦП reorder buffer 300+ микроинструкций, задержка на чтение RAM около 60нс, на 5ГГц это 300 тактов. Так что в идеальном случае память прочитается даже без кэшей.
В некоторых случаях кэши даже вредны, например memcpy при копировании более 2Мб включает некэшируемое копирование, иначе на заполнение кэшей тратится в 3 раза больше времени.
Для корректности теста автовекторизацию лучше выключить настройками компилятора. А еще неплохо бы посчитать флопсы и Гб/с.
Насчет кэш промахов при случайном доступе нужно считать Гб/с и сравнивать с аналогичным memcpy, тогда будет видно сколько реально идет в RAM, а сколько в кэши. Ничего не мешает ЦП читать массив индексов наперед и префетчить, потери идут только из-за прыгания по кэш линиям из-за чего железо не успевает подгружать данные, а была бы память побыстрее, то и потерь не было бы.
Как в UE не знаю, но я тестировал разные варианты и на всех встройках быстрее через пиксельный и с sampler min фильтром вместо gather4. Округление до степени 2 тоже быстрее работает, хоть и меньше точности.
Только подход не универсальный, так как запись в UAV идет без компресии (кроме AMD), поэтому на встройках и мобилках такой код работает в разы медленее.
как быстро удалить элементы из x[], y[], z[] массивов
ни в коем случае не использовать скаляры, иначе производительность падает в 5 раз
как сделать ветвление: сгруппировать по типам или использовать маски
как выбрать определенные элементы из массива и плотно упаковать их не переходя на скаляры
как разместить иерархию в памяти: проще когда по 16 нод цепляется, но такого не бывает и нужно заполнить например один simd регистр из 3х родителей и второй simd из 16 их детей и не потерять на этом производительность
А если капнуть глубже, то современные ЦП способны читать из L1 в 2 регистра по 64байт выровненных данных за такт, но пока мы используем скаляры все это замедляется до 2х 4 байт за такт. И используем только одну инструкцию на скаляр вместо инструкции на 16х скаляров.
Только VR теперь без XXX не работает, даже PICO не хочет обновляться, а платежи еще до блокировок не принимали.
Писать код, который не поймет ИИ. У меня например куча асинхронщины, подписки на события и тд, разобраться в этом можно только с самодельным визуальным отладчиком. А если еще почаще кидать исключения и ловить их на глубине в 10-20 вызовов, то вообще никто не разберется, что там происходит.
Стоит с телефона в дефолтном браузере поискать кухни, так сразу раздается звонок с предложениями. А тут БПЛА от обычного пользователя все никак не могут отличить.
Я находил что у двух производителей есть проблема, когда видеокарта фиксируется на 210МГц и все тормозит, мне хоть повезло и само восстановилось через неделю. Проблема с WiFi вообще массовая, даже дешевый USB адаптер лучше. Еще сильно греется при подключении к USB-C прямо под рукой.
У меня тоже самое на Asus за 150к. Хотя с ноутами мне вообще не везет.
Двухканальная DDR5-8000 это всего 128Гб/с, на 52 ядра это 2.5ГБ/с. Если кто-то сможет распределить задачи на столько ядер.
Кстати, текстуры в играх используются не процессором, они перегоняются с диска на ГПУ через ЦП, а объемы данных такие, что кэш никак не поможет. Если скорость PCI-E около 64ГБ/с, то половина пропускной способности памяти будет уходить на подгрузку открытых миров.
Все решается проще через flat квалификатор. Была бы там поддержка интов, без него вообще бы шейдер не скомпилировался.
Под AVX тоже есть расширения, например AVX-VNNI для Intel, который повторяет AVX512-VNNI.
Я все же про то, что решает распараллеливание инструкций, а не длина SIMD.
Сейчас не так важно что за SIMD 128-512 поддерживается, так как в железе может быть 4х 128битных пайплайна, то есть 4 инструкции выполняются параллельно. Такое сделано например на Intel E-ядрах и Cortex X4. А на AMD Zen4 был SIMD256 dual issue для эмуляции SIMD512 пока они не сделали полноценные 512 бит на Zen5.
У ЦП reorder buffer 300+ микроинструкций, задержка на чтение RAM около 60нс, на 5ГГц это 300 тактов. Так что в идеальном случае память прочитается даже без кэшей.
В некоторых случаях кэши даже вредны, например memcpy при копировании более 2Мб включает некэшируемое копирование, иначе на заполнение кэшей тратится в 3 раза больше времени.
Для корректности теста автовекторизацию лучше выключить настройками компилятора. А еще неплохо бы посчитать флопсы и Гб/с.
Насчет кэш промахов при случайном доступе нужно считать Гб/с и сравнивать с аналогичным memcpy, тогда будет видно сколько реально идет в RAM, а сколько в кэши. Ничего не мешает ЦП читать массив индексов наперед и префетчить, потери идут только из-за прыгания по кэш линиям из-за чего железо не успевает подгружать данные, а была бы память побыстрее, то и потерь не было бы.
Как в UE не знаю, но я тестировал разные варианты и на всех встройках быстрее через пиксельный и с sampler min фильтром вместо gather4. Округление до степени 2 тоже быстрее работает, хоть и меньше точности.
Тут мой ресерч по HiZ.
Только подход не универсальный, так как запись в UAV идет без компресии (кроме AMD), поэтому на встройках и мобилках такой код работает в разы медленее.
8745HS на Zen4 с llama.cpp выдает 20tps на GPU и около 12tps на CPU. На Zen5 должно быть побыстрее.
pack(1) падает на ARM, если при компиляции не разрешить чтение невыровненых данных, что замедлит весь код
С переходом на simd начинается веселье типа:
как быстро удалить элементы из x[], y[], z[] массивов
ни в коем случае не использовать скаляры, иначе производительность падает в 5 раз
как сделать ветвление: сгруппировать по типам или использовать маски
как выбрать определенные элементы из массива и плотно упаковать их не переходя на скаляры
как разместить иерархию в памяти: проще когда по 16 нод цепляется, но такого не бывает и нужно заполнить например один simd регистр из 3х родителей и второй simd из 16 их детей и не потерять на этом производительность
А если капнуть глубже, то современные ЦП способны читать из L1 в 2 регистра по 64байт выровненных данных за такт, но пока мы используем скаляры все это замедляется до 2х 4 байт за такт. И используем только одну инструкцию на скаляр вместо инструкции на 16х скаляров.
Сделал так и нашел у себя такую же ошибку.
Кстати, для ассертов уже давно добавил bool{} конструктор чтобы отлавливать неправильные касты.
Лучше тогда андроид ТВ приставку с али за 4К. Там нет видеокамеры и микрофона, 100% отключается при выдергивании из розетки.
А кто их засудит за недоступ к еще разрешенным ресурсам?