Процессорные хроники, I guess
AMD. Познал Zen (ба-дум-тсс)
https://www.phoronix.com/scan.php?page=news_item&px=Zen-1-To-Zen-3-2022-AMD-ucode
Ах как жаль, что деталей нет, и рассказывать нельзя. Но можете угадать, кто заставил обновлять AMD микрокод 👀. Для Zen1/2 аж 2.5 года не обновляли. Горжусь, видимо
Бодались с августа, наконец-то дободались, и признали проблему. Наверное, один из самых сложных дебагов в моей жизни. Баги в CPU заставляют переосмыслить, кто ты, зачем ты учишь песок думать, и что тебя окружают конспирологические теории. А потом оказывается, что да, просто баг.
ARM. Нормальная архитектура, говорите?
Тут продолжаю много играться с армами, что аж попал в комитет по дизайну след чипа от Google. А так сидел, бенчмаркал себе, заметил странную особенность.
В армах есть инструкции stp, ldp, они умеют загружать пары регистров в буффера. Так как в армах есть 16 байтные регистры имена которых начинаются на q{0-15}, то можно устраивать load 32 байтов одновременно тем самым немного отходя от парадигмы, что ARM NEON только 16 байтный и учитывать способность иметь хоть какие-то 32 байтные аналоги AVX. Так вот, решил посмотреть кодогенерацию memmove(dst, src, 64) у clang, получил
И что-то мне не понравились perf counters по количеству stalled-cycles-backend. ldp/stp занимают по 6 и 4 latency соответственно, числа не сходились слегка (тут какая-то фраза про 10к часов и что я просто едва учуял ощущение "something is not right"). llvm-mca правильно показывал
Решил поиграться и поменять в обратном направлении (сначала загрузить по 0 адресу, потом по 32.
https://gcc.godbolt.org/z/rE5a4Kze7
Sorry, the what, 5%?
Написал ARM, подтвердили на многих архитектурах, скоро обновим гайд и компиляторы, I guess. Причем с STR/LDR (загрузка по 1 регистру) всё ок, дело не в кешах, процессоры должны давным давно уметь подгружать кеши в обратном направлении и микробенчмарк очевидно смотрит на L1 данные.
Здесь должна быть статья про exoshuffle
Тут вышла интересная статья про Exoshuffle -- https://arxiv.org/pdf/2203.05072.pdf про то, как писать Shuffle в MapReduce на Future абстракциях. Статья в целом не очень то и прорывная и с большими вопросами, но она очень неплохая в том же обзоре какие проблемы испытывают Shuffle операции.
На пост слов не хватит, но очень правильно пишут про Merge Shuffle, Pull based shuffle, очень много хороших обзорных идей и с чем (в том числе моя команда) сталкиваются в написании Shuffle стадии -- её очень сложно завести, чтобы все ресурсы правильно утилизировались и разные распределения ключей не мешали. В след раз как-нибудь разберу
AMD. Познал Zen (ба-дум-тсс)
https://www.phoronix.com/scan.php?page=news_item&px=Zen-1-To-Zen-3-2022-AMD-ucode
Ах как жаль, что деталей нет, и рассказывать нельзя. Но можете угадать, кто заставил обновлять AMD микрокод 👀. Для Zen1/2 аж 2.5 года не обновляли. Горжусь, видимо
Бодались с августа, наконец-то дободались, и признали проблему. Наверное, один из самых сложных дебагов в моей жизни. Баги в CPU заставляют переосмыслить, кто ты, зачем ты учишь песок думать, и что тебя окружают конспирологические теории. А потом оказывается, что да, просто баг.
ARM. Нормальная архитектура, говорите?
Тут продолжаю много играться с армами, что аж попал в комитет по дизайну след чипа от Google. А так сидел, бенчмаркал себе, заметил странную особенность.
В армах есть инструкции stp, ldp, они умеют загружать пары регистров в буффера. Так как в армах есть 16 байтные регистры имена которых начинаются на q{0-15}, то можно устраивать load 32 байтов одновременно тем самым немного отходя от парадигмы, что ARM NEON только 16 байтный и учитывать способность иметь хоть какие-то 32 байтные аналоги AVX. Так вот, решил посмотреть кодогенерацию memmove(dst, src, 64) у clang, получил
// Загрузка 64 байтов, сначала x8+32, потом x8
ldp q2, q3, [x8, #32]
ldp q0, q1, [x8]
// Выгрузка 64 байтов
stp q2, q3, [x9, #32]
stp q0, q1, [x9]
И что-то мне не понравились perf counters по количеству stalled-cycles-backend. ldp/stp занимают по 6 и 4 latency соответственно, числа не сходились слегка (тут какая-то фраза про 10к часов и что я просто едва учуял ощущение "something is not right"). llvm-mca правильно показывал
[1,21] D====eeeeeeER ldp q2, q3, [x8, #32]
[1,22] .D=====eeeeeeER ldp q0, q1, [x8]
[1,23] ..D========eeeeER stp q2, q3, [x9, #32]
[1,24] ...D==========eeeeER stp q0, q1, [x9]
Решил поиграться и поменять в обратном направлении (сначала загрузить по 0 адресу, потом по 32.
https://gcc.godbolt.org/z/rE5a4Kze7
BM_MemMove64_mean 2.27ns
BM_MemMove64Assembly_mean 2.15ns
Sorry, the what, 5%?
Написал ARM, подтвердили на многих архитектурах, скоро обновим гайд и компиляторы, I guess. Причем с STR/LDR (загрузка по 1 регистру) всё ок, дело не в кешах, процессоры должны давным давно уметь подгружать кеши в обратном направлении и микробенчмарк очевидно смотрит на L1 данные.
Здесь должна быть статья про exoshuffle
Тут вышла интересная статья про Exoshuffle -- https://arxiv.org/pdf/2203.05072.pdf про то, как писать Shuffle в MapReduce на Future абстракциях. Статья в целом не очень то и прорывная и с большими вопросами, но она очень неплохая в том же обзоре какие проблемы испытывают Shuffle операции.
На пост слов не хватит, но очень правильно пишут про Merge Shuffle, Pull based shuffle, очень много хороших обзорных идей и с чем (в том числе моя команда) сталкиваются в написании Shuffle стадии -- её очень сложно завести, чтобы все ресурсы правильно утилизировались и разные распределения ключей не мешали. В след раз как-нибудь разберу