Думаю уже все слышали об Alpaca - аналоге chatGPT, которую можно запустить локально на процессоре. И раз есть такая возможность почему бы не сделать это на Эльбрусе?!

На чем тестировалось

Я решил сравнить три процессора: Эльбрус 8СВ на сервере sumeriko(Доступ можно получить по ссылке), Эльбрус-16С(Спасибо Михаилу Шигорину, у него как раз имеется инженерный образец данного процессора) и Ryzen 7 5800H.

Что было сделано

Я не стал придумывать велосипед и скачал llama.cpp и веса alpaca-7B. Затем собрал с параметрами -O4 -ffast-math и -O3 на Эльбрусе и Ryzen соответственно. Также на Эльбрус-8СВ добавил -ftune=elbrus-8c2, а на Эльбрус-16С добваил -ftune=elbrus-16c. Если кому-то будет интересно поиграться на сервере, то файл весов с alpaca лежит в /srv/home/alex_mih/llama.cpp/models

Запуск

Я решил протестировать сразу 3 системы для наглядности. Тестировались Эльбрус-8СВ, Эльбрус-16с(с 8 ядрами) и Ryzen 7 5800H. Тест скорости проводил следующей командой, которая была предложена пользователем rPman на Хабре.

for a in {1..8};do printf "%s;" $a;./main -t $a -m ./models/ggml-alpaca-7b-q4.bin -s 42 -p "Random joke:" -n 32 2>&1 |grep "llama_print_timings:       eval time" | cut -d "(" -f 2 | grep -o -e "[0-9\.]*" ;done

Для того чтобы условия были равными(на сколько это возможно) сначала я протестировал все три процессора на 8 потоках.

Потоки

Ryzen 7 5800H 3200MHz (ms)

Эльбрус-8СВ 1500MHz (ms)

Эльбрус-16С 2000MHz (ms)

1

716,04

2708,62

2389,05

2

391,81

1379,05

1225,16

3

271,67

935,71

823,20

4

216,83

714,14

638,50

5

171,64

580,71

513,72

6

147,36

491,13

438,66

7

129,04

427,02

380,11

8

123,06

379,25

342,84

График сравнения(Меньше - лучше)
График сравнения(Меньше - лучше)
График Скорости Процессоров
График Скорости Процессоров


Бенчмарки

(Данная часть будет обновляться) Спасибо entityfx за дополнительные тесты.

тесты были сделаны при помощи benchmark-q4_0-matmult. Собиралось через команду: make benchmark

На данный момент нет доступа к Ryzen на котором проводились тесты выше, так что пока добавил Ryzen 7 1700X (Спасибо Вячеславу за тест)

1 поток

FLOPS_per_u_Second

Эльбрус 4С

750 МГц

735.60

Эльбрус 8С

1300 МГц

3455.45

Эльбрус 8СВ

1550 МГц

7202.17

Эльбрус 16С

2000 МГц

10761.69

Core i7 2600K

3400 МГц

14224.27

Intel Core i5 8250U

2000..3400 МГц

27306.49

Байкал-М

1500 МГц

3307.45

Ryzen 7 1700X

3400..3800 МГц

18888.65

Ну и в многопоточном тесте.

8 потоков

FLOPS_per_u_Second

Эльбрус 4С

750 МГц (4 потока)

2858.15

Эльбрус 8С

1300 МГц

26892.26

Эльбрус 8СВ

1550 МГц

55424.05

Эльбрус 16С

2000 МГц

82397.41

Core i7 2600K

3400 МГц (4 потока)

40267.38

Intel Core i5 8250U

2000..3400 МГц

111165.17

Байкал-М

1500 МГц

24025.62

Ryzen 7 1700X

3400..3800 МГц

111718.20

А теперь ограничим производительность на Ryzen.

Я решил ограничить частоты на Ryzen и снова запустил тест(по этой причине результаты немного отличаются от таблицы выше). К сожалению пока получилось ограничить только на 1.3GHz(Если получится выставлю на 2.0GHz. Рязань меня не слушает).Я понимаю что этот тест нечестный. В дальнейшем поправлю таблицы для Ryzen. И вот тут уже результаты довольно близкие.

Потоки

Ryzen 7 5800H 3200MHz (ms)

Ryzen 7 5800H 1300MHz (ms)

Эльбрус-16С 2000MHz (ms)

1

710,80

2296,21

2367,98

2

381,21

1156,99

1218,16

3

264,92

778,34

827,60

4

210,56

592,54

639,17

5

170,64

475,96

514,12

6

147,92

398,64

440,96

7

132,29

350,26

386,43

8

123,84

318,50

338,58

График скорости (Меньше - лучше)
График скорости (Меньше - лучше)

Заключение

Может Эльбрус и не показал скорость в разы превышающие результаты по сравнению с Ryzen, но нужно учитывать что Эльбрус 8св 2018 года выпуска, a Ryzen 2021 года, Плюс частоты на данных процессоров разные. (3200MHz и 4400MHz в turbo boost на Ryzen, 1500MHz на Эльбрус-8СВ и 2000MHz на Эльбрус-16С). Однако судя по тестам тут была проблема именно с оптимизацией. Судя по всему нужно менять ggml под Эльбрус. Эльбрус-16с поддерживает аппаратную виртуализацию и данный пример был как раз запущен под виртуалкой.

P.S.

На момент тестов оптимизации кода под Эльбрус не проводилось!

Комментарии (26)


  1. t13s
    17.04.2023 06:30
    +4

    Я за Эльбрусами слежу очень поверхностно...

    Но вот быстрый гуглеж про 16С показал, что камень еще не вышел: http://mcst.ru/elbrus-16s ("ведётся подготовка серийного производства в 2022 году").

    Вы его как тестировали?


    1. AlexMih23 Автор
      17.04.2023 06:30
      +1

      У Михаила Шигорина имеется инженерный образец


  1. DmitryZlobec
    17.04.2023 06:30
    +4

    Если идет оценка архитектуры, то, результаты следует отнормировать на MHz, как это делают например с тем же CoreMark. т.е. результат должен быть (ms / поток)/MHz


    1. AlexMih23 Автор
      17.04.2023 06:30
      +3

      Отредактировал. Но я бы не сказал что это именно тест архитектуры, скорее это просто тестпо типу "А заработает ли?". На данный момент хочется оптимизировать ggml для Эльбруса, если есть интерес можете помочь всегда готов к сотрудничеству


      1. Civil
        17.04.2023 06:30

        Но я бы не сказал что это именно тест архитектуры

        Если это так, то какой смысл в результатах Ryzen'а с даунклоком? Вы же понимаете, что процессор это законченное изделие и вы не получите Эльбруса-16С с частотами Ryzen 5800H? Да и 1.3 ГГц для Zen 3 не соответствует ни одной из моделей, даже включая Ryzen Embedded V3000 (там у V3C18I 1.9 ГГц базовой частоты, у всех остальных выше)


        1. AlexMih23 Автор
          17.04.2023 06:30
          +1

          Да, понимаю. Просто пока не получилось Ryzen до 2ГГц опустить. Это будет сделано позже и я обновлю таблицу и тесты.


          1. Civil
            17.04.2023 06:30
            +2

            Ryzen до 2ГГц опустить. 

            Так а зачем это вообще делать? Вы все равно не увидите вживую Ryzen с фиксированной частотой 2 ГГц (даже у Embedded это All Core Clock, но на одном ядре будет больше)

            Вы ж сами говорите, что вам архитектурная скорость (на МГц) не интересна, а если так, то нет никакого смысла в этих извращениях с частотами.

            Вам ниже тоже самое другими словами говорят.


    1. MountainGoat
      17.04.2023 06:30
      +4

      Зачем? Что нам покажет этот фактор? Частота не ниспослана свыше, она часть архитектуры. Одна система работает с меньшей частотой, но больше умеет на такт, другая меньше...
      Я понимаю сравнение ms на ватт. Или ms на рыночную стоимость компа. Но почему ms на MHz?


      1. DmitryZlobec
        17.04.2023 06:30

        Частота определяется техпроцессом. Надо смотреть не сколько тактов в секунду, а просто - сколько тактов. Вот смотрите если взять coremark:
        Pentium IV 3.00GHz, Coremarks 5007.1, Coremark/Mhz: 1.6731
        Pentium 100MHz, Coremarks 213.83, Coremark/Mhz: 2.138

        Да, PIV за счет тактовой выигрывает, но Pentium за счет архитектуры тратит на одну итерацию в полтора раза меньше тактов, чем Pentium 4, соответственно его архитектура лучше.

        И то же самое можно сказать и про 8СВ vs Ryzen 7: Разница в частоте в два раза, но если считать в количестве затрачиваемых тактов, то процентов 40%. И тогда мы действительно увидим - а умеет ли одна система больше за такт чем другая.


        1. EntityFX
          17.04.2023 06:30
          +3

          Нужно ещё учитывать скорость доступа в память/кеш. Ну и в P IV появились инструкции SSE2.


        1. Civil
          17.04.2023 06:30
          +2

          Частота определяется техпроцессом.

          Не совсем - частота определяется множеством факторов: техпроцессом, длиной критического пути в архитектуре, целевым энергопотреблением и т.п.

          Вы привели пример с 4-ым пнем на 3 ГГц - такая частота там достигалась на техпроцессе в 130 нм, но при этом же у Pentium III Tualatin на тех же 130 нм частоты были далеки от 3 ГГц (1.4 у последнего серийного).

          но Pentium за счет архитектуры тратит на одну итерацию в полтора раза меньше тактов, чем Pentium 4, соответственно его архитектура лучше.

          Во-первых, по одному тесту делать вывод некорректно.

          Во-вторых - Pentium не будет работать на частоте в 3 ГГц, если его сделать по 130нм техпроцессу (см. Atom N270 - он правда на 45нм, но зато близок к первому Pentium'у архитектурно).

          Рассматривать эффективность архитектуры (как раз таки сколько тактов уходит на ту или иную операцию) не имеет особого практического смысла, это интересно сугубо с точки зрения академической - например при изначальном исследовании архитектуры или чтобы получить инструмент прогнозирования, если архитектура в принципе разгоняется (или тормозится) до каких-то других частот. И ровно поэтому для этих целей используют наборы тестов - например SPEC и CoreMark.


        1. DrSmile
          17.04.2023 06:30
          +3

          Частота определяется техпроцессом и микроархитектурой. Как разобьют долгие операции на куски, такая и будет частота. Можно намельчить и сделать конвейер на 20 стадий, зато поднять частоту повыше, как у P4, а можно — наоборот.


        1. EntityFX
          17.04.2023 06:30
          +1

          Crystal Mark 2004
          Crystal Mark 2004


          1. Civil
            17.04.2023 06:30
            +1

            Собственно комментарии те же самые. Про нормирование про частоту я тебе давно говорил, а про Crystal Mark - совершенно непонятно что конкретно он меряет, поэтому что говорят его попугаи - тоже не ясно. Без этого совершенно непонятно что попугаи в нем дают на практике.

            Плюс ко всему:

            The result of CrystalMark 2004R7 is not compatible with CrystalMark 2004/R2/R3.

            CrystalMark 2004R7 is a 32bit total benchmark software.


        1. MountainGoat
          17.04.2023 06:30
          +2

          тратит на одну итерацию в полтора раза меньше тактов, ... соответственно его архитектура лучше.

          Вот тут не понимаю логики. Почему лучше? Какая на выходе разница, сколько система умеет за такт? Пользователь не расходует такты, он расходует ватты, секунды и бабки.


  1. DBalashov
    17.04.2023 06:30
    +4

    Там же внутри ggml (которая используется в Alpaca) есть вагон использования векторных расширений, как они транслируются в VLIW? Используются ли они? По хорошему надо бы в нативный код портировать это и потом сравнивать.


    1. AlexMih23 Автор
      17.04.2023 06:30
      +2

      Да, это и хочу сделать. Пока разбираюсь как это в натив закинуть. Если все пройдет успешно будут еще тесты. На данный момент это грубо говоря тест "из коробки" с минимальным вмешательством


      1. IvGrad2
        17.04.2023 06:30
        +2

        Здесь на Хабре есть статья от @SmartEngines "Низкоуровневая оптимизация кода на платформе Эльбрус". Эльбрус-8СВ и 16С поддерживают уже векторные операции с регистром 128 бит. Также для процессоров Эльбрус имеется высокопроизводительная библиотека EML, функции из которой можно использовать для оптимизации.


    1. thevlad
      17.04.2023 06:30
      +3

      Один из плюсов VLIW и Эльбруса в том, что векторные интрисинки(SSE/AVX) достаточно напрямую транслируются в систему комманд, и их "реализация" поставляется с компилятором. В результате "векторный код" довольно не плохо компилируется по производительности.


      1. avdosev
        17.04.2023 06:30
        +1

        А если код изначально хорошо оптимизирован под SSE/AVX, то улучшить перформанс под эльбрусы не получится?


        1. thevlad
          17.04.2023 06:30

          Если переписать нативно под e2k, улучшить скорее всего можно, вопрос насколько. Вообще нейросетки с минимум ветвлений, должны относительно хорошо ложиться на VLIW.


        1. OpenA
          17.04.2023 06:30

          Для эльбруса недостаточно просто упаковать операции в одну avx/sse инструкцию.
          Ему надо полностью оптимизировать функции/процедуры на которые приходится большая часть времени работы. Оптимизации заключаются в том что надо подсказать компилятору вещи, которые не очевидны из кода - типичное количество итераций в том или ином цикле, могут ли пересекаться указатели, выравнены ли данные итп.


          В общем надо уметь читать ассемблер е2к, смотреть что генерирует компилятор и все ли возможности он в том или ином случае использовал.


  1. dimitrii_z
    17.04.2023 06:30
    +4

    Чувствую, что отхвачу минусов, но таки вот. Очередная попытка натянуть сову на глобус. Типа вот наш проц (который печатался на Тайване и уже не печатается и в обозримом будущем не будет) что-то может в несколько раз медленнее чем человеческий камень. Отставание в 10 - 15 лет по производительности никуда не денется какие тесты не гонять. Единственный путь - дружить с цивилизацией и совместно что-то делать полезное (как пример - МКС и проект термоядерного реактора ITER). Надеюсь, что будет реально чем хвастать скоро, а не выжимать из воздуха сравнительные статьи где фактически несуществующий в продакшне проц с чем-то лежащим на полках сравнивается.


    1. OpenA
      17.04.2023 06:30
      -2

      Рязань производится на том же самом TSMC.
      А в ближайшем десятилетии возможно сможет производится в одном из штатов, так как у "цивилизации" если чего-то нет, то они не жалеют времени и денег на то чтоб у них это появилось чтоб они ни от кого не зависели. Пример - та же космонавтика где у них практически все свое появилось уже и мы им будем скоро не нужны.

      Я это все к тому что быть с "цивилизацией" можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой - кофе приносить, туалеты на их станции чинить, соперничать с другим обслуживающим персооналом за право быть к господину ближе чем другие.


      Причем большая часть элиты нашей страны строго ориентировалась на второе все время своей власти, но барину нравятся только маленькие и слабенькие, большие могучие коровы ему не нужны.


      1. dimitrii_z
        17.04.2023 06:30

        Я к тому, что есть вещи, которые можно делать и можно нагнать, а есть которые вряд ли. Опуская даже ситуацию, простой пример: в технологиях постсовок слаб, но силён например в науке типа математики. Таким образом в идеальном мире российские учёные могли бы приносить пользу при разработке и развитии технологий (к примеру ядерных, процессорных или космических), материальные части для которых (чипы, софт, коллайдера) строятся/производятся в других странах, в итоге все выигрывают, человечество движется вперёд. Технологии не будут ждать кого-то отстающего, а т.к. скачки происходят экспоненциально, то уровень отставания будет расти. Это вам не ядерное оружие испытывать, тут физика не менялась почти век, такое и Северная Корея умеет. А сейчас всё сводится у некоторых к радости если вдруг у Маска ракета не взлетит в срок как сегодня. Печально это.


      1. PuerteMuerte
        17.04.2023 06:30
        +4

        можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой

        А есть ещё два пути: можно сотрудничать с ними на равных, участвуя в международных проектах, предлагая выгодные условия для иностранного бизнеса с участием российского капитала и так далее, и можно пытаться имитировать их, отгородившись железным занавесом и клепая в своём маня-мирке поделки "по мотивам", с совершенно безнадёжными экономическими характеристиками, которые умрут сиюмоментно как только тот занавес рухнет, похоронив все вложенные в них финансовые и интеллектуальные ресурсы.
        Вот из этих четырёх путей мы выбрали последний.