Я вообще без понятия, честно. Вижу это только со стороны кода, и только когда это вызывает проблемы и баги, а в остальное время стараюсь писать стандартный код, который бы не приводил к таким проблемам и багам, но не всегда получается Ж)
Нет, барьеры не выталкивают данные в L2, как вы выразились. smp_wmb() просто инструкция упорядочивания, которая гарантирует что все записи до барьера станут видны другим ядрам раньше записей после барьера. Это понятие только об относительном порядке видимости, и физические если вы откроете годболт там будет чтото вроде mfence или lock xchg, и все отложенные записи из store-буфера коммитятся в L1D конкретного ядра, а вот полетят ли они дальше в L2 вопрос. Ядро просто пометит свою копию как Invalid. Более того, L1D ядра1 может вообше отдать линию напрямую ядру2 через HITM, минуя L2, и изменения там появятся только когда ядро3 придет за этими данными, но там тоже есть особенности работы на старых Intel/Amd до 15года
Это не было темой статьи. Я вам больше скажу, обычный (широковещательный) snooping MESI нормально работает только на 2-4 ядрах. Если интересно больше технических деталей то можно вот это почитать (https://habr.com/ru/articles/689310/), на 6–8 накладные расходы уже соизмеримы и превышают время работы с переменной в L2. Но все зависит от паттерна работы, если вся работа в пределах одного ядра то проблем не будет, проблема начинается там, где есть write-sharing, когда несколько ядер пишут в одни и те же или соседние кэш-линии. Но даже на двух ядрах можно подложить себе граблей с false sharing, если два потока пишут в разные переменные, которые случайно лежат в одной кэш-линии. И тогда с точки зрения MESI они делят одну линию, и каждая запись одного ядра инвалидирует кэш другого, хотя логически данные вообще независимы. Это классическая грабля при написании многопотока, еслиatomic counter1 и stomic counter2 лежат рядом в структуре, то они почти гарантированно окажутся в одной кешлинии и будут постоянно пинговать друг друга между ядрами, но увидите и почините вы это очень не скоро, если увидите вообще.
есть такое, у знакомых на билдферме стоит пара Samsung PM9AX c 16гб кеша, но скажу что кардинально они картину не меняют, снижение времени сборки билда не стоит этих денег. Сам диск стоит как самолет и потом оказалось что дешевле было докупить 128Гб оперативки и развернуть в ней временный диск.
Хеоны у меня были в руках очень давно, но в числомолотилках, да еще под ICC скомпиленых они уделывали AMD и обычные гражданские версии не то, что на проценты - в разы в некоторых случаях, на GCC результаты были сильно скромнее. Но, это было в 2008.
Ну дядя Борман был известным приколистом в этом плане, на его багах я застал -Og, когда внутри функции делалась подфункция если некоторые части были одинаковые. И я бы никогда не знал про эту дичь если бы не странные краши, которые она порождала. Или -Ov, который пытался выносить переменные и инваринты из циклов. Или "фантастический" -Ob режим, который умел склеивать функции под капотом, что тоже добавляло отладки в ночи.
Ну вы же прочитали эту статью, она размещена в сети, написана с помощью пк и вызвала некоторый отклик у вас, раз вы решили написать комментарий. Вероятно с помощью смартфона. Разве ваш комментарий не реален? Музыка и игры тоже не имеют физических воплощений, но это не мешает им вызывать эмоции.
Не надо жалости, у меня все отлично ;) Специально спрятал под спойлер, он появился после выхода книги для обратной связи. Вы еще про бусти забыли сказать...
Есть такие понятия как комерческая тайна, авторское право и мнение игроков. Если пользоваться открытами тулами, то рано или поздно код или его части утекут. Если код пишет ИИ, то нет явного авторства кода и условный ChatGPT может взять кусок как есть и встроить его в игру, если код взят из открытых источников и имеет специфичную лицензию, то автор лицензии намример может потребовать открыть всю кодовую базу изза этого небольшого фрагменты. Есть мнение игроков, которые считают что игры должны писать люди для людей, и пока их большинство.
Ну так там не про современный с++, а про базовые вещи, структуры данных, работу с памятью, строки, паттерны оптимизации. Это все мало связано с конкретным стандартом, если охота 20/23 стандарта - это уже отдельно, в нескучное программирование.
Ага, семплирующие это только верхушка чтобы наметить самые явные области куда смотреть: А смотреть надо на Self time (exclusive) проведённое непосредственно в теле функции. Высокое значение = внутри функции есть дорогой код, Total time (inclusive, если есть) время вместе со всеми вызываемыми функциями. Высокое значение = функция является точкой входа в дорогой пайплайн, т.е. надо разбираться не самой функцией, причиной почему функции внутри дорогие, но смотреть выше 3-4 уровня смысла нет, main и update всегда будут дорогими по понятным причинам. Я тут про книгу рассказывал, вся вторая часть посвящена оптимизациям, как, зачем и где смотреть.
Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Таже, просто не все из тех кто на меня подписан читают блог bhv, поэтому с разрешения издательства я утащил текст к себе. Ну и тут часть материала, которая появилась у меня уже после постов в bhv и на линкеде.
Я вообще без понятия, честно. Вижу это только со стороны кода, и только когда это вызывает проблемы и баги, а в остальное время стараюсь писать стандартный код, который бы не приводил к таким проблемам и багам, но не всегда получается Ж)
Нет, барьеры не выталкивают данные в L2, как вы выразились.
smp_wmb()просто инструкция упорядочивания, которая гарантирует что все записи до барьера станут видны другим ядрам раньше записей после барьера. Это понятие только об относительном порядке видимости, и физические если вы откроете годболт там будет чтото вродеmfenceилиlock xchg, и все отложенные записи из store-буфера коммитятся в L1D конкретного ядра, а вот полетят ли они дальше в L2 вопрос. Ядро просто пометит свою копию как Invalid. Более того, L1D ядра1 может вообше отдать линию напрямую ядру2 через HITM, минуя L2, и изменения там появятся только когда ядро3 придет за этими данными, но там тоже есть особенности работы на старых Intel/Amd до 15годаЭто не было темой статьи. Я вам больше скажу, обычный (широковещательный) snooping MESI нормально работает только на 2-4 ядрах. Если интересно больше технических деталей то можно вот это почитать (https://habr.com/ru/articles/689310/), на 6–8 накладные расходы уже соизмеримы и превышают время работы с переменной в L2. Но все зависит от паттерна работы, если вся работа в пределах одного ядра то проблем не будет, проблема начинается там, где есть write-sharing, когда несколько ядер пишут в одни и те же или соседние кэш-линии. Но даже на двух ядрах можно подложить себе граблей с false sharing, если два потока пишут в разные переменные, которые случайно лежат в одной кэш-линии. И тогда с точки зрения MESI они делят одну линию, и каждая запись одного ядра инвалидирует кэш другого, хотя логически данные вообще независимы. Это классическая грабля при написании многопотока, если
atomic counter1иstomic counter2лежат рядом в структуре, то они почти гарантированно окажутся в одной кешлинии и будут постоянно пинговать друг друга между ядрами, но увидите и почините вы это очень не скоро, если увидите вообще.есть такое, у знакомых на билдферме стоит пара Samsung PM9AX c 16гб кеша, но скажу что кардинально они картину не меняют, снижение времени сборки билда не стоит этих денег. Сам диск стоит как самолет и потом оказалось что дешевле было докупить 128Гб оперативки и развернуть в ней временный диск.
Хеоны у меня были в руках очень давно, но в числомолотилках, да еще под ICC скомпиленых они уделывали AMD и обычные гражданские версии не то, что на проценты - в разы в некоторых случаях, на GCC результаты были сильно скромнее. Но, это было в 2008.
Ну дядя Борман был известным приколистом в этом плане, на его багах я застал -Og, когда внутри функции делалась подфункция если некоторые части были одинаковые. И я бы никогда не знал про эту дичь если бы не странные краши, которые она порождала. Или -Ov, который пытался выносить переменные и инваринты из циклов. Или "фантастический" -Ob режим, который умел склеивать функции под капотом, что тоже добавляло отладки в ночи.
Благодарю, поправил на сигнал, так будет корректнее.
Могут, но это уже не ко мне вопросы :)
Ну вы же прочитали эту статью, она размещена в сети, написана с помощью пк и вызвала некоторый отклик у вас, раз вы решили написать комментарий. Вероятно с помощью смартфона. Разве ваш комментарий не реален? Музыка и игры тоже не имеют физических воплощений, но это не мешает им вызывать эмоции.
Не надо жалости, у меня все отлично ;) Специально спрятал под спойлер, он появился после выхода книги для обратной связи. Вы еще про бусти забыли сказать...
Есть такие понятия как комерческая тайна, авторское право и мнение игроков. Если пользоваться открытами тулами, то рано или поздно код или его части утекут. Если код пишет ИИ, то нет явного авторства кода и условный ChatGPT может взять кусок как есть и встроить его в игру, если код взят из открытых источников и имеет специфичную лицензию, то автор лицензии намример может потребовать открыть всю кодовую базу изза этого небольшого фрагменты. Есть мнение игроков, которые считают что игры должны писать люди для людей, и пока их большинство.
@Kotyara99А у вас была возможность разобрать фрейм через RenderDoc? Может получится вытащить реверснутые шейдеры?
Благодарю, надеюсь найдёте полезные моменты и практики
Ну так там не про современный с++, а про базовые вещи, структуры данных, работу с памятью, строки, паттерны оптимизации. Это все мало связано с конкретным стандартом, если охота 20/23 стандарта - это уже отдельно, в нескучное программирование.
Ага, семплирующие это только верхушка чтобы наметить самые явные области куда смотреть: А смотреть надо на Self time (exclusive) проведённое непосредственно в теле функции. Высокое значение = внутри функции есть дорогой код, Total time (inclusive, если есть) время вместе со всеми вызываемыми функциями. Высокое значение = функция является точкой входа в дорогой пайплайн, т.е. надо разбираться не самой функцией, причиной почему функции внутри дорогие, но смотреть выше 3-4 уровня смысла нет, main и update всегда будут дорогими по понятным причинам.
Я тут про книгу рассказывал, вся вторая часть посвящена оптимизациям, как, зачем и где смотреть.
Выложил оглавление под спойлер, всё есть.
Добавил ссылку на ozon, там есть оглавление.
Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Таже, просто не все из тех кто на меня подписан читают блог bhv, поэтому с разрешения издательства я утащил текст к себе. Ну и тут часть материала, которая появилась у меня уже после постов в bhv и на линкеде.
Google docs + word. Aнатлий работал в Corel насколько я знаю