О тенденциях развития архитектуры процессоров, или почему я верю в успех Huawei на серверном рынке

    Мы живем в интересные времена. Мне кажется, следующие 2-3 года определят, куда пойдет развитие архитектуры на ближайшее десятилетие. Сейчас на рынке серверных процессоров есть несколько игроков, представляющих совершенно разные подходы к технологии. И это очень здорово (я даже затрудняюсь сказать, на какой слог падает ударение в последнем слове :))
    .
    А ведь еще лет 5-6 назад казалось, что время застыло и развитие остановилось. Упершись в разного рода ограничения (power wall, scalability wall и т.п.). Я немного рассказывал об этом вот здесь. Закон Мура был поставлен под сомнение и особо горячие теоретики предлагали ввести в него логарифмические поправки :) Доминация Intel на рынке серверных процессоров представлялась тогда незыблемой. AMD не оказывал серьезной конкуренции, GPGPU от NVidia выглядели сугубо нишевым продуктом, а попытки ARM пробиться на серверный рынок не имели успеха.

    Все изменилось с развитием таких сегментов как Machine Learning и Artificial intelligence. GPGPU оказались куда лучше “приспособлены” к операциям свертки и перемножения матриц (особенно с небольшой точностью), чем CPU. Кроме того, NVidia сумела продемонстрировать рост числа транзисторов, даже опережающий закон Мура. Это привело к тому, что мир серверных архитектур стал биполярным. На одном конце – x86 СPU, latency-engine, приспособленная к скрывания латентностей out of order машина. Ee неоспоримым достоинством является отличная производительность на однопоточных приложениях (single- thread performance). Недостатком – огромная площадь и число транзисторов. На другом конце GPGPU – Throughput engine, большое количество несложных вычислительных элементов(EU). Здесь все наоборот – размер одного элемента невелик, что позволяет разместить на одном чипе большое их количество. С другой стороны – производительность однопоточных приложений оставляет желать…

    Увы, попытки совместить СPU и GPU большой мощности в одном корпусе успеха пока не имели. Хотя бы по той причине, что подобный чип будет потреблять и рассеивать слишком много энергии. Поэтому сейчас в тренде дискретные решения. Я в них не особо верю по двум причинам. Во- первых архитектура становится более сложной и в ней появляются дополнительные затычки в виде шины, связывающей СPU и GPU, и неоднородной структуры памяти. Вторая сложность отчасти связана с первой, и состоит в том, что такие решения гораздо сложнее программировать. Каждая из существующих моделей программирования акселераторов (CUDA от NVidia, DPC++ от Intel, OpenCL или OpenMP) имеет свои достоинства и недостатки. В то же время ни одна из них не является ни универсальной, ни доминирующей.

    Мне кажется, что с точки зрения развития архитектуры верный шаг был сделан компанией AMD, представившей процессор Rome. За счет компактности ядра (по сравнению с Intel) в одном корпусе удалось разместить больше ядер. Впрочем, одного этого мало – для того чтобы такое решение масштабировалось по производительности необходимо позаботиться о правильной коммуникации между ядрами (uncore) и качестве параллельных рантаймов. Инженерам AMD удалось решить обе задачи и получить очень конкурентные результаты на одном из важнейших индустриальных бенчмарков – SPEC CPU. Решение от AMD находится между полюсами, представленными Nvidia и Intel. Но оно куда ближе к последнему. Это все еще то же самое “большое ядро”. “Золотая середина” между полярными подходами, как мне кажется, требует большего количества более компактных ядер. И из ныне существующих архитектур ARM имеет наилучшие шансы занять эту нишу.
    image
    Так почему же ARM именно от Huawei? Я для себя нашел такой ответ: с возрастанием числа ядер на чипе, значимость производительности одного ядра снижается (но до определенного предела), а важность коммуникаций между ядрами и с памятью возрастает. А коммуникации –это та область, где Huawei является мировым лидером. Именно дизайн uncore (а не только и даже не столько ядра) будет определять производительность системы. И здесь, как мне думается, у нас неплохие шансы.

    Однако идеальные архитектуры существуют только в вакууме. В реальности нужно всегда соотноситься с количеством и структурой существующего на серверном рынке программного обеспечения. А оно годами писалось и оптимизировалось под X86. Потребуется много времени и усилий, чтобы сделать его более “дружественным” к архитектуре ARM. Предстоит гигантская работа как в области программных инструментов (компиляторы, библиотеки, рантаймы) так и в области адаптации приложений (аpplication engineering). Но я верю, что дорогу осилит идущий.
    Huawei
    Компания

    Комментарии 32

      0
      Вроде как, да.
      Я бы изменил заголовок, это Linux (Android и серверные применения) надо готовиться
      www.ixbt.com/news/2020/05/02/windows-huawei-harmonyos-2-0.html
      Можете пролить свет на эту ОС?
        0
        Я все таки больше серверный человек. А серверный мир все же очень консервативен. Harmony — безусловно хорошее начинание. Но думаю, что оно скорее увидит свет в мире ПК. Серверные люди вряд ли скоро уйдут с Linux…
        +2
        значимость производительности одного ядра снижается
        Почему тогда дорогой проприетарный ARM, а не RISC-V?
          0
          Потому, что деньги на лицензии уже потрачены — надо отбивать :-)
            0

            Наверно потому что "но до определенного предела" + дальше еще про коммуникации между ядрами написано.

              0
              Это хорошее соображение. Я бы хотел знать где место RISC-V на этой картинке. Но пока не видел никаких внятных перформанс данных (SPEC, Linpack) или хотя бы оценок.
              А до определенного предела написал вот почему — все же производительность софта зачастую определяется самым узким местом, сериальной частью кода. Поэтому не особо верю, что RISC-V заработает «из коробки»…
                0
                Есть Power9 от рапторов. Вроде нормальный перформанс. Правда стоимость поднебесная.
                Риски вроде Алибаба хотел делать
              +5
              Я кстати, за проектом RISC-V c интересом посматриваю. Концепция выглядит на мой взгляд неплохо. Но если для ARM все же существует определенная экосистема, то для RISC-V весь софт надо будет перелопачивать с нуля. Это немного пугает :) Но вообще я тут думал написать пост про сравнение instruction sets cточки зрения эффективности и простоты реализации СPU front-end (a может быть и компилятора тоже). Мы на эту тему с Борисом Арташесовичем Бабаяном много дискутировали :)
                +1
                Было бы очень интересно послушать ваши соображения на счёт ISA.
              0
              Хорошая статья, но Я пока не вижу применений для ARM.
              В специфику своей работы, мне нам всегда требовались либо мощные процессоры (для серверов) и видеокарты с большим количеством CUDA ядер (машинное зрение и машинное обучение), а вот проекты, где нужно что то среднее, пока не встречались.
                0
                Ну я собственно полагаю что такая гомогенная конфигурация сможет эффективно конкурировать и с большими ядрами для серверных приложений и с маленьким для AI. Просто пока еще не создан чип с таким количеством ядер(~150 по моим оценкам), который смог бы это делать.
                А какие у вас ворклоады, если не секрет?:)
                  0
                  Просто пока еще не создан чип с таким количеством ядер(~150 по моим оценкам), который смог бы это делать.

                  Вот такие?
                  image
                    0

                    Чего-то попытался почитать про это, но так и не понял. Что за технология у них используется? ARM/MIPS/какая-то собственная? Их сайт больше похож на рекламную компанию хрен пойти чего.

                      +2
                      А ISA то какая? Какая нить очередная compiler -driven architecture?
                    0
                    Вы про какую нагрузку спрашиваете?
                    Производства которое мы автоматизируем, на роботов которых мы делаем или лично на меня? )
                    Или на сервера от Huawei которые мы используем)))
                      0
                      Да я все пытаюсь думаю про машинное зрение или обучение. Сколько нужно ядер, сколько исполнительных элементов и какую ширину SIMD, чтобы это стало сравнимо с NVidia. Это ведь для роботов?
                        0
                        Ага, Я не разработчик, а сис админ, поэтому могу сказать только про железо.
                        Для понимания приведу пример обработки видеопотока, точнее время выполнения цикла процессов для полного выполнения задачи:
                        1. При обработке на процессоре на Сервере с выделенными для софта 32 ядрами цикл выполняется за 3минуты.
                        2. При обработке на видеокарте на ПК с GTX1070, полный цикл проходит за 30 секунд.
                        3. При обработке на видеокарте на Сервере с RTX2080 Super, завершается за 10 секунд.
                        Софт использует многопоточность, соответственно чем больше CUDA ядер, тем лучше. Может и на Асиках считать. И высоко производительные ядра тут не требуются.

                        По поводу машинного обучения. У нас для этого используется три RTX 2070.
                        Как бы изначально на них строили, так что сравнений с другим железом нет.
                          0
                          спасибо. Вопрос тут как всегда в балансе числа исполняющих элементов, обьема загружаемых из памяти данных и сложности scheduleroв. На GPU они уже приближаются по сложности к космическим кораблям :) По сути скедюлер на GPU — это уже чип в чипе. Есть даже идеи использовать СPU для решения этой задачи :)
                    0
                    Что-то среднее нужно для HPC.
                    Fujitsu A64FX это сейчас самое топовое HPC решение по производительности среди CPU, обладающее эффективностью выше чем GPU.

                    www.nextplatform.com/2020/05/18/with-fugaku-supercomputer-installed-riken-takes-on-coronavirus

                    A64FX и ThunderX3 — 2 ARM процессора с производительностью > 3TFLOPS в DP.
                    0
                    Идея интересная, но не выстрелит.

                    Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

                    А при возникновении выбора — купить более дешевое, но слабое в single-thread производительсноти железо или использовать более простую, но CPU-затратную технологию (напр., Python вместо C++) — обычно выбирают второе, потому что труд программиста супердорог (по сравнению с другими профессиями в большинстве стран мира), и технологии надо упрощать, пусть и засчет увеличения потребления CPU.
                      0
                      Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

                      Это серверы. А для них в первую очередь имеет значение кол-во кол-во обработанных запросов в единицу времени (точнее, кол-во удовлетворенных юзеров), которое зависит и от кол-ва ядер и от их производительности.

                        0
                        Ну с количество запросов в секунду уже научились увеличивать настолько, насколько нужно — балансировать нагрзуку, шардировать можно хоть до бесконечности, если, конечно, архитектура позволяет.
                          0

                          Шардирование до бесконечности -> трата всей энергии земли.

                          Хотел написать по какому алгоритму желательно бы работали процы, но уже в с самом начале остановился на том, что это должен/ны решать какие-то отдельные ядра. А не будет ли при этом трата энергии на эти ядра больше, чем задача, которую они решают?
                          В текущих процах это скорее всего делает "кто-то" (не поднялась рука на "что-то") типа гипервизора. Судя по времени жизни от аккумов на разных смартах эти алгоритмы для этих гипервизорах отличаются сильно.

                          0
                          Я полагаю что важно и то и другое на самом деле. Throughput (количество обработанных запросов) наверно важнее. Но и латентность тоже играет рояль иногда. Впрочем она даже сильнее от сетки зависит и еще от чертовой тучи факторов…
                          0
                          Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

                          так вроде бы у армов прогресс в этом направлении

                          0
                          Offtop on
                          Неожиданная встреча на Хабре. Привет-привет. Заодно узнал чем ты сейчас занимаешься)
                          Offtop off
                          Прогнозы дело не благородное. Я бы склонился к подходу ниши всякие нужны, ниши всякие важны. Пусть расцветают множество архитектур и решений, а уж мы потом выберем)
                            +1
                            Привет, Паш. Рад слышать :)
                            0
                            Валера, привет! А как же компании которые на ARM сделали упор на производительность отдельного ядра? Какие задачи по твоему именно лидерство в «коммуникациях» поможет в HPC?
                              +2
                              Привет, Игорь. Ну я имел в виду то, что что uncore oн весь состоит из шин, коммутаторов и буферов.
                              0
                              Очень интересуют нейроускорители Huawey.
                              Это то на чем могут выстрелить сервера с ARM. Если нужен только inference, а не training, то Nvidia не нужна.
                                0
                                Когда нибудь напишу о них. Когда дойдет ход. Но пока про CPU :)

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое