Как стать автором
Обновить

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

Сборку chromium ;-) И сразу будет понятно чего стоят камешки в совершенно практической задаче.

сразу отвечу, что сборка на Эльбрусе ооооооооочень долгая. Я при знакомстве с ним собирал разные либы на Эльбрус-8С — так вот, скорость сборки на нём по времени примерно равнялась оной на древнем кукурузном АМД А6.


Объясняется это тем, что компилятору для VLIW нужно на порядки больше оптимизаций делать. Ещё плюс то, что сам компилятор же на Эльбрусе работает.


Поэтому вангую, что результат будет не в пользу Эльбруса

наверно если тестировать сборку, то с одинаковым таргетом.

НЛО прилетело и опубликовало эту надпись здесь
смотря что за разработка. Я вот не собираю/запускаю код, который разрабатываю, на своей машине. То же самое будет верно для большинства микроконтрольщиков и разрабов под мобилки. Собственно, даже если у вас таргет — эльбрусы, вы совершенно не обязаны разрабатывать на эльбрусе.

Да, на Хромиуме куча всего, ждем... Говорят, там немного сложно из-за зависимостей и JS движка. Вот для Firefox пришлось Rust запиливать.

Мне кажется, стоило бы еще добавить какой-нибудь современный ARM к сравнению, не только Intel.

Сделаю как-нибудь. Apple M1? А так Байкал М как две малины 4.

На сколько мне известно, ее довольно глубоко меняли и она лучше других языков/сред показывает себя (С конечно же лучше).

Может стоит сравнивать не с топовым Intel 10-летней давности, а самым простым офисным Atom, но современным?

Делал с Atom Z8350 1.44 GHz 4 core. Есть в большой картинке в конце статьи.

Ядро Cortex A57

Детали ядра e2k

image

Более подробные детали ядра Эльбруса.
Пришёл посмотреть на комментарий с аксиомой Эскобара, не нашёл. Всё надо делать самому…

Сравнение попугаев на единицу стоимости хотелось бы. Если, конечно, отечественные процессоры наконец-то можно просто «взять и купить».

Про цены сложно, серии малые, значит пока дорого.

Мне был бы интересен тест кросс-компиляции, например, ядра linux - с одинаковым конфигом и под одну архитектуру (не нативную, но одинаковую для всех, например, PowerPC или какую-нибудь еще)

Поскольку Эльбрус — серверная машина, то интересно

— HTTP бенчмарк
— PostgreSQL бенчмарк
— Python / Ruby бенчмарк

Но вообще тут что-то очень не ладно — как так получается что обычный Intel на более старом техпроцессе и медленной памяти оказался настолько быстрее. Либо VLIW как идея не работает, либо команде Эльбруса надо насесть на компиляторы, clang бэкенд, JIT и оптимизацию библиотек.

Php, Python я бенчил в прошлой статье.

Intel для начала почти в 2.5 раза быстрее по частоте.

Вообще, из всей статьи, выбивается два интересных момента:
1)
MP MFLOPS 49788 381326 81745
Что это такое, и в чем выгода, если большинство других тестов (особенно практических) не показывают особое преимущество Эльбруса

2)
И Байкал и Эльбрус показывают примерно одинаковую производительность. При этом потребление отличается почти в три раза, что сильно не красит Эльбрус
Intel для начала почти в 2.5 раза быстрее по частоте.

Этот аргумент работает только в таком разрезе: новый техпроцесс позволяет ту же архитектуру разогнать до больших частот, поэтому, до некоторого предела можно было ставить знак равества между большая частота и более тонкие топонормы. Если же говорить про одинаковые топонормы, то увеличение частоты возможно при упрощении архитектуры и наборот, усложнение архитектуры ведёт к снижению тактовой частоты.
Соответственно, хуже топонорма но выше частота и производительность, просто говорит о полном разгроме архитекторов. Но для красоты эксперимента, можно было взять Интеловский проц по такому же техпроцессу. И да, напротив CISC для Интела надо поставить звёздочку, под копотом это RISC архитектура с микрокодом.

Да, для серверов важна энергоэффективность и в точке оптимума, будет существенная просадка и по частоте и по производителности, но Вт на мегаопс, я так понимаю тоже продули, так что эта версия не катит. В конце концов, если уж учитывать этот аргумент, то и Интел надо брать серверный проц.

А вообще, печально, 28 нанометров, это уже более-менее приличные размерности, но выросшая производительность относительно предыдущего поколения, выросла гораздо ниже, чем у конкурентов, то есть линейный и более масштаб, который предсказывался и грозил просто разорвать всех, на деле оборачивается катастрофой. Ибо, чем ближе мы к новым техпроцессам, тем очевидней, что силы на оптимизацию под эти техпроцессы конкуренты вваливали нещадно, а тут, видимо просто «сменили техпроцесс» и если дальше продолжать в том же духе, то это просто утянет на репутационное дно.

P. S. to EntityFX, возьмите на заметку эти аргументы.
Этот аргумент работает только в таком разрезе: новый техпроцесс

Про частоту интела я хотел сказать, что как бы не совсем корректно сравнивать процессор с почти в 2.5 раза большей частотой каждого ядра. Там сразу понятно, что многие тесты и обязаны показывать больше, и это не совсем заслуга именно архитектуры.

А вот два других показывают примерно одинаковые бенчмарки, и различия более чем на 5-10% уже интересно за счет чего так вышло.
  1. Это как раз числодробильный бенчмарк. Там умножения, сложения, работа с массивами. С Этим Эльбрус очень быстро справляется.

  2. В других случаях он на уровне с Байкалом (не числодробильные задачи). Где много переходов, ветвлений и т. д.

Intel для начала почти в 2.5 раза быстрее по частоте.


Что же это значит? Варианты, на мой взгляд, такие
— Не смогли на высоком уровне сделать place & route на чипе. Поэтому блоки работают на низких частотах.
— Сделали слишком сложный чип, он работает на низких частотах даже на более тонком техпроцессе, но эта сложность не дает ожидаемого прироста производильности.
— Забили на оптимизацию софта, поэтому несмотря на возможности паралеллизации блоки процессора простаивают.

ИМХО дело в том, что эльбрус-8СВ — первое изделие на 28нм архитектуре у МЦСТ.

8С тоже 28 нм.

Да, я ошибся. Но не сильно. Первым 28нм был 8С, а у 8СВ уже выше частота (хотя не не просто оверклокинг, там много поменяли, они вроде бы даже не обратно совместимы бинарно).

Протестировал PHP на Байкале:

Extenstion 'mbstring' not loaded or not compiled! Multi-byte string tests will produce empty result!
-------------------------------------------------------------------------------------------
|                                  PHP BENCHMARK SCRIPT                                   |
-------------------------------------------------------------------------------------------
Start               : 2021-05-23 02:16:32
Server              : Linux/5.10.32-un-def-alt1 aarch64
Platform            : Linux
System              : ALT Workstation 9.1 (Laertes)
CPU                 :
              model : Cortex-A57
              cores : 8
          available : 8
                MHz : 50MHz
Memory              : 256 Mb available
Benchmark version   : 1.0.37
PHP version         : 7.3.27
  available modules :
           mbstring : no
               json : yes
               pcre : yes
Max execution time  : 600 sec
Crypt hash algo     : MD5
-------------------------------------------------------------------------------------------
TEST NAME                      :      SECONDS |       OP/SEC |      OP/SEC/MHz |    MEMORY
-------------------------------------------------------------------------------------------
01_math                        :    8.808 sec | 113.53 kOp/s |   2.27 kOps/MHz |      2 Mb
02_string_concat               :    0.988 sec |   7.80 MOp/s | 155.95 kOps/MHz | 128.84 Mb
03_1_string_number_concat      :    7.818 sec | 639.52 kOp/s |  12.79 kOps/MHz |      4 Mb
03_2_string_number_format      :    6.880 sec | 726.75 kOp/s |  14.53 kOps/MHz |      4 Mb
04_string_simple_functions     :    8.959 sec | 145.10 kOp/s |   2.90 kOps/MHz |      4 Mb
05_string_multibyte            :    -.--- sec |     -.--Op/s |     -.--Ops/MHz |         0
06_string_manipulation         :   16.111 sec |  80.69 kOp/s |   1.61 kOps/MHz |      4 Mb
07_regex                       :    9.372 sec | 138.71 kOp/s |   2.77 kOps/MHz |      4 Mb
08_1_hashing                   :    9.121 sec | 142.52 kOp/s |   2.85 kOps/MHz |      4 Mb
08_2_crypt                     :   24.709 sec | 404.72  Op/s |   8.09  Ops/MHz |      4 Mb
09_json_encode                 :   15.315 sec |  84.88 kOp/s |   1.70 kOps/MHz |      4 Mb
10_json_decode                 :   22.405 sec |  58.02 kOp/s |   1.16 kOps/MHz |      4 Mb
11_serialize                   :   12.070 sec | 107.70 kOp/s |   2.15 kOps/MHz |      4 Mb
12_unserialize                 :   15.904 sec |  81.74 kOp/s |   1.63 kOps/MHz |      4 Mb
13_array_fill                  :    7.982 sec |   6.26 MOp/s | 125.29 kOps/MHz |     12 Mb
14_array_range                 :    1.150 sec |  86.99 kOp/s |   1.74 kOps/MHz |     12 Mb
14_array_unset                 :    7.537 sec |   6.63 MOp/s | 132.69 kOps/MHz |     12 Mb
15_loops                       :    8.161 sec |  24.51 MOp/s | 490.15 kOps/MHz |      4 Mb
16_loop_ifelse                 :    3.594 sec |  13.91 MOp/s | 278.27 kOps/MHz |      4 Mb
17_loop_ternary                :    8.815 sec |   5.67 MOp/s | 113.45 kOps/MHz |      4 Mb
18_1_loop_defined_access       :    1.877 sec |  10.66 MOp/s | 213.16 kOps/MHz |      4 Mb
18_2_loop_undefined_access     :   15.441 sec |   1.30 MOp/s |  25.90 kOps/MHz |      4 Mb
19_type_functions              :    4.260 sec | 704.26 kOp/s |  14.09 kOps/MHz |      4 Mb
20_type_conversion             :    4.171 sec | 719.26 kOp/s |  14.39 kOps/MHz |      4 Mb
21_0_loop_exception_none       :    0.186 sec |  21.56 MOp/s | 431.26 kOps/MHz |      4 Mb
21_1_loop_exception_try        :    0.213 sec |  18.81 MOp/s | 376.23 kOps/MHz |      4 Mb
21_2_loop_exception_catch      :    8.344 sec | 479.36 kOp/s |   9.59 kOps/MHz |      4 Mb
22_loop_null_op                :    5.616 sec |   8.90 MOp/s | 178.06 kOps/MHz |      4 Mb
23_loop_spaceship_op           :    4.535 sec |  11.02 MOp/s | 220.50 kOps/MHz |      4 Mb
26_1_class_public_properties   :    0.501 sec |   9.97 MOp/s | 199.44 kOps/MHz |      4 Mb
26_2_class_getter_setter       :    1.600 sec |   3.12 MOp/s |  62.50 kOps/MHz |      4 Mb
26_3_class_magic_methods       :    3.566 sec |   1.40 MOp/s |  28.04 kOps/MHz |      4 Mb
-------------------------------------------------------------------------------------------
Total time:                    :  246.007 sec |   2.45 MOp/s |  48.96 kOps/MHz |
Current PHP memory usage:      :        4 Mb
Peak PHP memory usage:         :   125.45 Mb
На Эльбрусе:

Extenstion 'xmlrpc' not loaded or not compiled! XmlRpc tests will procude empty result!
-------------------------------------------------------------------------------------------
|                                  PHP BENCHMARK SCRIPT                                   |
-------------------------------------------------------------------------------------------
Start               : 2021-05-22 23:28:40
Server              : Linux/5.4.0-2.11-e8c2 e2k
Platform            : Linux
System              : Linux
CPU                 :
              model : E8C2
              cores : 8
          available : 8
                MHz : 1550MHz
Memory              : 256 Mb available
Benchmark version   : 1.0.36
PHP version         : 7.4.7
  available modules :
           mbstring : yes
               json : yes
             xmlrpc : no
               pcre : yes
Max execution time  : 600 sec
Crypt hash algo     : MD5
-------------------------------------------------------------------------------------------
TEST NAME                      :      SECONDS |       OP/SEC |      OP/SEC/MHz |    MEMORY
-------------------------------------------------------------------------------------------
01_math                        :   13.572 sec |  73.68 kOp/s |  47.54  Ops/MHz |      2 Mb
02_string_concat               :    2.039 sec |   3.78 MOp/s |   2.44 kOps/MHz | 128.84 Mb
03_1_string_number_concat      :   10.689 sec | 467.78 kOp/s | 301.80  Ops/MHz |      4 Mb
03_2_string_number_format      :    9.120 sec | 548.25 kOp/s | 353.71  Ops/MHz |      4 Mb
04_string_simple_functions     :    9.785 sec | 132.85 kOp/s |  85.71  Ops/MHz |      4 Mb
05_string_multibyte            :    9.245 sec |  14.06 kOp/s |   9.07  Ops/MHz |      4 Mb
06_string_manipulation         :   43.879 sec |  29.63 kOp/s |  19.11  Ops/MHz |      4 Mb
07_regex                       :   29.604 sec |  43.91 kOp/s |  28.33  Ops/MHz |      4 Mb
08_1_hashing                   :    9.369 sec | 138.76 kOp/s |  89.52  Ops/MHz |      4 Mb
08_2_crypt                     :   26.396 sec | 378.84  Op/s |   0.24  Ops/MHz |      4 Mb
09_json_encode                 :   21.731 sec |  59.82 kOp/s |  38.60  Ops/MHz |      4 Mb
10_json_decode                 :   28.453 sec |  45.69 kOp/s |  29.48  Ops/MHz |      4 Mb
11_serialize                   :   28.453 sec |  45.69 kOp/s |  29.48  Ops/MHz |      4 Mb
11_serialize                   :   14.194 sec |  91.59 kOp/s |  59.09  Ops/MHz |      4 Mb
12_unserialize                 :   14.194 sec |  91.59 kOp/s |  59.09  Ops/MHz |      4 Mb
12_unserialize                 :   13.504 sec |  96.27 kOp/s |  62.11  Ops/MHz |      4 Mb
13_array_fill                  :   17.443 sec |   2.87 MOp/s |   1.85 kOps/MHz |     12 Mb
14_array_range                 :    1.609 sec |  62.14 kOp/s |  40.09  Ops/MHz |     12 Mb
14_array_unset                 :   18.711 sec |   2.67 MOp/s |   1.72 kOps/MHz |     12 Mb
15_loops                       :   11.621 sec |  17.21 MOp/s |  11.10 kOps/MHz |      4 Mb
16_loop_ifelse                 :    8.599 sec |   5.81 MOp/s |   3.75 kOps/MHz |      4 Mb
17_loop_ternary                :   12.434 sec |   4.02 MOp/s |   2.59 kOps/MHz |      4 Mb
18_1_loop_defined_access       :    4.744 sec |   4.22 MOp/s |   2.72 kOps/MHz |      4 Mb
18_2_loop_undefined_access     :   29.025 sec | 689.07 kOp/s | 444.56  Ops/MHz |      4 Mb
19_type_functions              :    6.675 sec | 449.42 kOp/s | 289.95  Ops/MHz |      4 Mb
20_type_conversion             :    6.671 sec | 449.71 kOp/s | 290.14  Ops/MHz |      4 Mb
21_0_loop_exception_none       :    0.447 sec |   8.94 MOp/s |   5.77 kOps/MHz |      4 Mb
21_1_loop_exception_try        :    0.531 sec |   7.54 MOp/s |   4.86 kOps/MHz |      4 Mb
21_2_loop_exception_catch      :   11.791 sec | 339.25 kOp/s | 218.87  Ops/MHz |      4 Mb
22_loop_null_op                :   12.497 sec |   4.00 MOp/s |   2.58 kOps/MHz |      4 Mb
23_loop_spaceship_op           :    9.828 sec |   5.09 MOp/s |   3.28 kOps/MHz |      4 Mb
24_xmlrpc_encode               :    -.--- sec |     -.--Op/s |     -.--Ops/MHz |         0
25_xmlrpc_decode               :    -.--- sec |     -.--Op/s |     -.--Ops/MHz |         0
26_1_class_public_properties   :    1.213 sec |   4.12 MOp/s |   2.66 kOps/MHz |      4 Mb
26_2_class_getter_setter       :    3.024 sec |   1.65 MOp/s |   1.07 kOps/MHz |      4 Mb
26_3_class_magic_methods       :    6.593 sec | 758.34 kOp/s | 489.25  Ops/MHz |      4 Mb
-------------------------------------------------------------------------------------------
Total time:                    :  405.037 sec |   1.49 MOp/s | 959.43  Ops/MHz |
Current PHP memory usage:      :        4 Mb
Peak PHP memory usage:         :   125.48 Mb
Справедливости ради стоит отметить, что у системы-на-кристалле Байкал BE-M1000 имеется несколько аппаратных ускорителей видео и аппратные видеокодеки (8 ядер Mali-T628), чего, пока что, нет ни в одном Эльбрусе. А значит, на десктопах, при работе с графическим интерфейсом пользователя, просмотре и кодировании видео, Байкал BE-M1000 будет более предпочтителен, чем Эльбрус.
У меня в Ryzen 9 тоже нет ничего видоускоряющего. Он хуже байкала теперь?
У Эльбруса 1С+ на борту Vivante GC2500. Добротный мобильный чип, вполне успешный на свое время.

H.264 и 1080p@60fps такое себе видео, даже youtube уже не посмотришь.

Вообще не логичным выглядит добавление кодеков, из серии - чтобы было. Я понимаю, что вставили на что денег было, но был ли смысл вообще.

На плате кого производителя тестировался BE-M1000?
Интересно было бы оценить результат в виде производительность/ватт и производительность/MHz.
Очень хотелось бы тестов бинарного транслятора.
Горшенин говорил, что x86-код, выполняемый в трансляторе примерно на 25% медленнее нативного. Было бы интересно посмотреть хотя бы 3-4 теста.

Это не HPL, а древний Linpack, но раз он есть, то почему бы не побенчить с ним.

На самом деле спасибо за достаточно интересный и вроде бы не предвзятый тест. Да думал эльбрус себя лучше покажет.
Без указания с какими опциями производилась компиляция кода эти тесты ничего не показывают, Эльбрус очень сильно зависит от оптимизаций компилятора, фактически за счет компилятора и достигается его производительность, в зависимости от степени оптимизации производительность может меняться на порядок.
Это лучше чем ничего. Если кто то сможет дать материал лучше чем автор флаг ему в руки. Я буду рад его увидеть и я жду материал еще лучше. Но это лучше чем говновбросы ряда некогда уважаемых блогеров, в которых вообще нет фактов, кроме политики. А так понятно, что оптимизация в том числе компиляторов рулит. Я надеюсь, что автор использовал оптимальные варианты. Да если по Байкалу и так все было ясно ибо ARM, то вот от эльбруса я ожидал выше результатов. Опять таки со слов блогеров, которые ударились в политику.
Эльбрусы создаются для решения вычислительных задач, где они и показывают высокие результаты, там где возможно распараллеливание когда, что вы от них еще ждете непонятно, это не процессор для игр или серфинга в интернете.

Байкал Эльбрус Интел
MP MFLOPS 49788 381326 81745
HPL [GFLOPS] 38 110 93.9
SPEC 2006 INT 9.2 19.5 44.6
SPEC 2006 FP 9 27.5
А я от него ничего и не жду. Я прекрасно понимаю, что эльбрусам вообще не место в сегменте десктопа и у него специфические задачи. И что сравнение в лоб разных архитектур сомнительно. Хотя тот же m1 показал, что ARM вполне может тягаться с x86/x64. Но пиарят Эльбрусы некоторые люди именно с упором как наш ответ Интел. И вот данная статья ставит точки на и. И как популярная она имеет место быть для развеянья легенд и мифов. Это заметно даже тут в комментариях, когда людей интересует эффективность именно ПК на базе Эльбруса и сравнение его с бытовыми процессорами общего назначения. А то так для распараллеливания наверное надо не с I7-2600 сравнивать.

Да, вы правы. На самом деле я советовался с людьми из МЦСТ чтобы правильно собрать бенчи. Эльбрусы любит параллельные программы, но он всё-равно процессор общего назначения.

Серфинг на 4 ядрах куда как комфортнее чем на 2.
Вывод — распараллеливается еще как.

Тесты собирались под Эльбрусы с разными флагами и запускались с профилем, выбирались лучшие результаты.

Интересно, конечно. Уже много сказано насчет этих процессоров, но в целом, компьютеры достаточно эффективные для определенных задач. Куда интереснее их оснащение и подход к сборке, достаточно добротно сделано. А насчет трансляции х86 — а не товарищ Бабаян ли участвовал в разработке архитектуры? насколько помню, сей дон и на Интел успел поработать, как раз на тему трансляторов в х86) Сам я вообще не смыслю в этой обалсти, но статьи с Компьютерры начала-середины нулевых помню =)

А какой «загрузчик» у Байкал-М? Там UEFI или uboot?

Мы недавно приобрели материнку с BE-M1000 (TF307, SDK 4.4), у нас тест Coremark показал даже немного больше: 8562 / 68248, лог ниже. По первым ощущениям, как рабочий ПК для офисных сотрудников — вполне годная машина. LibreOffce не тормозит. Youtube декодируется на ЦПУ (300% загрузка из 800% возможных), аппаратных видео-кодеков пока не доступно для Alt-а. Вроде как есть кодеки для Астры (Debina 10), но что-то как-то нет желания её ставить.

2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 12846
Total time (secs): 12.846000
Iterations/Sec : 8562.976802
Iterations : 110000
Compiler version : GCC8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1)
Compiler flags : -O3 -funroll-all-loops -fgcse-sm -fgcse-las -finline-limit=1000 -DVALIDATION_RUN=1 -DPERFORMANCE_RUN=1 -lrt -lpthread
Memory location : Please put data memory location here
(e.g. code in flash, data on heap etc)
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 8562.976802 / GCC8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) -O3 -funroll-all-loops -fgcse-sm -fgcse-las -finline-limit=1000 -DVALIDATION_RUN=1 -DPERFORMANCE_RUN=1 -lrt -lpthread / Heap

2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 12894
Total time (secs): 12.894000
Iterations/Sec : 68248.797890
Iterations : 880000
Compiler version : GCC8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1)
Compiler flags : -O3 -DMULTITHREAD=8 -DUSE_PTHREAD -funroll-all-loops -fgcse-sm -fgcse-las -finline-limit=1000 -DVALIDATION_RUN=1 -DPERFORMANCE_RUN=1 -lrt -lpthread
Parallel PThreads : 8
Memory location : Please put data memory location here
(e.g. code in flash, data on heap etc)
seedcrc : 0xe9f5
...
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 68248.797890 / GCC8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) -O3 -DMULTITHREAD=8 -DUSE_PTHREAD -funroll-all-loops -fgcse-sm -fgcse-las -finline-limit=1000 -DVALIDATION_RUN=1 -DPERFORMANCE_RUN=1 -lrt -lpthread / Heap / 8:PThreads
Да, спасибо. Скорее всего доп. флаги помогли. Да, у меня YouTube 1920p @30 тянул спокойно. Ускорение 3D с Panfrost появилось недавно.
Panfrost это 3D (OpenGL), к декодированию видео отношения не имеет, там отдельный кусок железа за это отвечает и драйверов к нему для Alt-а нет.

Расскажите как заставить FreeCAD использовать Panfrost? FreeCAD из репозитория жутко тормозит при вращении 3D модели, грузит одно ядро на 100%. На виндовой машине — ничего не грузит, вращает модель очень быстро — сразу видно, что используется GPU.
Да, 3д драйвер недавно появился и я смог простые игры с поддержкой OpenGL ES 3 запустить. Драйвера на ускорение кодирования/декодирования нет, это я знаю, но процессор вытягивает в FHD.

Про FreeCAD не отвечу — не интересовался этой темой.
Тема игр не раскрыта, где DOOM тест? ;-)

На мали Т628 текстуры пропадают.

Попросили замерить задержки ОЗУ на Эльбрусе-8СВ:
Test-Tlb

 $ make run freq=1.5
gcc -g -Wall -O3 test-tlb.c -o test-tlb -lm -D FREQ="1.5"
for i in 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 6M 8M 16M 32M 64M 128M 256M ; do echo "$i:"; ./test-tlb -H $i 64; ./test-tlb $i 64 ; ./test-tlb -Hr $i 64; ./test-tlb -r $i 64; done
4k:
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
8k:
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
16k:
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
32k:
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
  2.01ns (~3.0 cycles)
64k:
  2.02ns (~3.0 cycles)
  2.02ns (~3.0 cycles)
  2.02ns (~3.0 cycles)
  2.02ns (~3.0 cycles)
128k:
  7.40ns (~11.1 cycles)
  7.43ns (~11.1 cycles)
  7.39ns (~11.1 cycles)
  7.45ns (~11.2 cycles)
256k:
  7.41ns (~11.1 cycles)
 10.98ns (~16.5 cycles)
  7.41ns (~11.1 cycles)
 10.00ns (~15.0 cycles)
512k:
  7.89ns (~11.8 cycles)
 16.36ns (~24.5 cycles)
  7.78ns (~11.7 cycles)
 16.29ns (~24.4 cycles)
1M:
 22.19ns (~33.3 cycles)
 21.36ns (~32.0 cycles)
 22.18ns (~33.3 cycles)
 21.46ns (~32.2 cycles)
2M:
 22.18ns (~33.3 cycles)
 22.19ns (~33.3 cycles)
 22.18ns (~33.3 cycles)
 22.20ns (~33.3 cycles)
4M:
 22.19ns (~33.3 cycles)
 24.19ns (~36.3 cycles)
 22.18ns (~33.3 cycles)
 27.09ns (~40.6 cycles)
6M:
 22.21ns (~33.3 cycles)
 28.77ns (~43.2 cycles)
 22.18ns (~33.3 cycles)
 35.63ns (~53.4 cycles)
8M:
 22.18ns (~33.3 cycles)
 31.61ns (~47.4 cycles)
 22.19ns (~33.3 cycles)
 39.64ns (~59.5 cycles)
16M:
 29.33ns (~44.0 cycles)
 69.35ns (~104.0 cycles)
 28.78ns (~43.2 cycles)
 86.74ns (~130.1 cycles)
32M:
108.36ns (~162.5 cycles)
 97.97ns (~147.0 cycles)
124.15ns (~186.2 cycles)
122.47ns (~183.7 cycles)
64M:
108.33ns (~162.5 cycles)
106.03ns (~159.0 cycles)
124.32ns (~186.5 cycles)
136.67ns (~205.0 cycles)
128M:
108.45ns (~162.7 cycles)
108.53ns (~162.8 cycles)
124.69ns (~187.0 cycles)
141.88ns (~212.8 cycles)
256M:
108.42ns (~162.6 cycles)
108.57ns (~162.9 cycles)
125.08ns (~187.6 cycles)
146.06ns (~219.1 cycles)

На Байкал-М:

gcc -g -Wall -O3 test-tlb.c -o test-tlb -lm -D FREQ="1.5"
for i in 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 6M 8M 16M 32M 64M 128M 256M ; do echo "$i:"; ./test-tlb -H $i 64; ./test-tlb $i 64 ; ./test-tlb -Hr $i 64; ./test-tlb -r $i 64; done
4k:
  3.38ns (~5.1 cycles)
  3.38ns (~5.1 cycles)
  3.38ns (~5.1 cycles)
  3.38ns (~5.1 cycles)
8k:
  3.37ns (~5.1 cycles)
  3.37ns (~5.1 cycles)
  3.37ns (~5.1 cycles)
  3.38ns (~5.1 cycles)
16k:
  3.37ns (~5.1 cycles)
  5.65ns (~8.5 cycles)
  3.37ns (~5.1 cycles)
 12.84ns (~19.3 cycles)
32k:
  3.43ns (~5.1 cycles)
  4.60ns (~6.9 cycles)
  3.45ns (~5.2 cycles)
 11.42ns (~17.1 cycles)
64k:
  5.94ns (~8.9 cycles)
  6.02ns (~9.0 cycles)
 16.24ns (~24.4 cycles)
 16.22ns (~24.3 cycles)
128k:
  5.96ns (~8.9 cycles)
  6.59ns (~9.9 cycles)
 16.24ns (~24.4 cycles)
 16.38ns (~24.6 cycles)
256k:
  5.95ns (~8.9 cycles)
  6.66ns (~10.0 cycles)
 16.24ns (~24.4 cycles)
 18.65ns (~28.0 cycles)
512k:
  5.96ns (~8.9 cycles)
  6.65ns (~10.0 cycles)
 16.48ns (~24.7 cycles)
 19.81ns (~29.7 cycles)
1M:
  9.91ns (~14.9 cycles)
 11.20ns (~16.8 cycles)
 22.74ns (~34.1 cycles)
 33.13ns (~49.7 cycles)
2M:
 10.14ns (~15.2 cycles)
 11.88ns (~17.8 cycles)
 60.86ns (~91.3 cycles)
 64.48ns (~96.7 cycles)
4M:
 10.84ns (~16.3 cycles)
 12.67ns (~19.0 cycles)
 71.07ns (~106.6 cycles)
 78.54ns (~117.8 cycles)
6M:
 13.06ns (~19.6 cycles)
 16.53ns (~24.8 cycles)
 99.53ns (~149.3 cycles)
112.87ns (~169.3 cycles)
8M:
 17.26ns (~25.9 cycles)
 19.99ns (~30.0 cycles)
144.49ns (~216.7 cycles)
182.61ns (~273.9 cycles)
16M:
 21.79ns (~32.7 cycles)
 25.37ns (~38.1 cycles)
212.50ns (~318.7 cycles)
228.44ns (~342.7 cycles)
32M:
 22.04ns (~33.1 cycles)
 26.04ns (~39.1 cycles)
216.38ns (~324.6 cycles)
244.64ns (~367.0 cycles)
64M:
 22.06ns (~33.1 cycles)
 25.75ns (~38.6 cycles)
219.83ns (~329.7 cycles)
255.81ns (~383.7 cycles)
128M:
 21.97ns (~33.0 cycles)
 25.89ns (~38.8 cycles)
218.52ns (~327.8 cycles)
265.81ns (~398.7 cycles)
265.81ns (~398.7 cycles)
256M:
 21.95ns (~32.9 cycles)
 25.88ns (~38.8 cycles)
218.85ns (~328.3 cycles)
218.85ns (~328.3 cycles)
Производительность SDRAM сильно зависит от конкретных производителей микросхем и того, на сколько качественно сделана разводка печатной платы. Для DDR4 все очень жестко.

Можно издеваться, а можно готовиться к
будущему и делать реальные дела..!


Не за горами время, когда начнётся массовое
"компиляторописАние" для процессоров
VLIW-архитектуры...


Я с 2016 г. стараюсь готовить студентов
"Вышки" и МИРЭА в области системного
программирования (тема — разработка
математических основ распараллеливающих
трансляторов с максимальным
использованием ресурсов
процессора — режим максимальной
плотности кода) к решению задач
оптимизации выполнения
параллельного кода для вычислителей
VLIW-архитектуры (это как раз ЭЛЬБРУС).


Далее идёт материал об этом (от самого
общего и примитивного до реальной
разработки с количественными
результатами):
https://habr.com/ru/post/530078/
https://habr.com/ru/post/534722/
https://habr.com/ru/post/535926/
https://habr.com/ru/post/540122/
https://habr.com/ru/post/545498/
https://habr.com/ru/post/551688/

Спасибо, пробегал как-то ваши статьи, довольно интересно, оставлю в сообществе по Эльбрусам, пусть ознакомятся.

Вопросы генерации рационального ("осмысленного", обладающего максимальной плотностью кода) сверхдлинного слова для VLIW-процессоров - здесь https://vk.com/valery_bakanov?w=wall647639183_106 (стр. 154)..!

Спасибо, ознакомились сообществом Фан клуб Процессоры Эльбрус. Но нужны идеи как это внедрить в компиляторы, либо новый параллельный ЯП.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий