Содержание

7. А если x86 процессор будет имитировать Эльбрус?

Возможно, читая статью, вы задавались вопросом: «Морис, а почему ты не стесняешься в статье применять нецензурную брань?». Ответ прост: я уверен на 99%, что эту статью у себя МЦСТ публиковать не будут. А при публикации на сайте Стаса мне нет нужды сдерживаться в выражениях. То, что я в этой главе вам покажу, скорее всего, очень не понравится людям в МЦСТ. Может быть, представители МЦСТ опубликовали бы мою статью и сослались бы на неё, если бы я не вставил в статью эту главу. Они бы вполне лояльно отнеслись к критике Эльбруса (которая дальше тоже последует), но из-за этой главы они этого делать не станут (если её репостнут, я ах@ею).

А почему я пишу эту главу? Потому, что я хочу показать, что МЦСТ сделали реально крутую вещь. Но чтобы это показать, мне надо будет несколько расстроить представителей МЦСТ. Вот так диллема. Ладно, пойду на это, раз уж я решил, что хочу помочь МЦСТ своим материалом, даже если самим МЦСТ моя статья из-за этой главы придётся совсем даже не по нраву.

Что же не так в этой главой? Почему она такая особенная? Сейчас я продемонстрирую эмулятор Эльбруса, qemu-e2k. Я искал на официальных ресурсах МЦСТ, в том числе и в официальном Телеграм-канале МЦСТ, какие-либо упоминания qemu и не нашёл ни одного такого. Скорее всего, представители МЦСТ предпочитают не поднимать эту тему, и я догадываюсь почему (см. главу 8 далее). Скорее всего, они предпочтут не постить у себя мою статью в принципе, чем запостить её вот с этой 7-й главой.

Мы с вами уже поняли, что безопасность на Эльбрусе обеспечивается несколькими аппаратными методами. И одним из тех факторов, который за это отвечает, является разграничение на 3 стека при работе с данными в регистрах. Также на Эльбрусе отсутствует спекулятивное выполнение команд, благодаря чему он не подвержен уязвимостям Spectre и Meltdown. и им подобным.

На итоговую производительность Эльбруса может влиять то, что у него архитектура заточена под большую степень защищённости. Но так ли это – хз, я – не эксперт. Но, возможно, следующий тест здесь что-то прояснит.

Как мне заставить x86 процессор работать в схожих условиях? Не придумал ничего лучше использования эмулятора. Ставится он так:

                            git clone --recursive https://github.com/OpenE2K/qemu-e2k; cd qemu-e2k; ./configure --target-list=e2k-linux-user && make -j$(nproc);
                        

После того, как я загрузил и собрал из исходного кода эмулятор qemu-e2k, мне потребовалась Операционная Система с Эльбруса (нужно же программам, что я запускаю, опираться на какие-то компоненты, базовые утилиты). Для этого я вытащил SSD из Эльбруса и скопировал с него на мой SSD в ноутбуке раздел, содержащий ext4 файловую систему с установленной Эльбрус ОС 7.1, и использовал этот дистрибутив Linux для работы уже собранного эмулятора qemu. После того, как я провёл тест, я снёс Эльбрус ОС под e2k с SSD своего ноутбука, т.к. на нём она мне более не требовалась.

Для запуска теста с dav1d я воспользовался следующей командой:

dav1dversion="0.9.3-git-6aaeeea6"; buildargs="-O4"; dav1d="e2k-lcc-1.26.09/dav1d-$dav1dversion$buildargs/build/tools/dav1d"; postargs="-o - --threads 8 --muxer=null"; ~/qemu-e2k/build/qemu-e2k –version | head -n 1; for testvideo in "Chimera-2397fps-AV1-10bit-1920x1080-3365kbps.obu" "Chimera-AV1-8bit-1920x1080-6736kbps.ivf" "Chimera-AV1-10bit-1920x1080-6191kbps.ivf"; do /usr/bin/time -f "Elapsed: %E (%e secs). dav1d$buildargs. Video: $testvideo" /bin/bash -c "QEMU_LD_PREFIX=/mnt/elbrus7.1/ /home/moris/qemu-e2k/build/qemu-e2k ./$dav1d -i ./$testvideo $postargs"; done

Итак, что в итоге?

Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

Скриншот 147. Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

Мягко говоря, я ахренел. Я не преувеличиваю сейчас ни разу. Тот сэмпл, который за 10.5 минут декодировался с нативной версией из C кода, сейчас обрабатывался больше суток (аж 27 часов). У меня глаза как арбузы...

Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

Гистограмма 120. Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

Гистограмма 121. Тест dav1d (из C кода с оптимизациями -O4) на Xiaomi (i7 8550U) в нативе и с qemu-E2K.

У меня производительность при использовании эмулятора просела в среднем в 165 раз! Я просто в шоке. А я ведь тестировал версию с оптимизациями lcc компилятором под E2K при помощи опций -O4 и -ffast (на x86 с компилятором gcc использовал опцию -O3, т.к. -O4 равнозначен -O3 в случае с gcc).

Тест dav1d (из C кода с -O4 и -ffast) на Эльбрус 8С (OSL 7.1) и Xiaomi (i7 8550U) с qemu-E2K.

Скриншот 148. Тест dav1d (из C кода с -O4 и -ffast) на Эльбрус 8С (OSL 7.1) и Xiaomi (i7 8550U) с qemu-E2K.

Тест dav1d (из C кода с -O4 и -ffast) на Эльбрус 8С (OSL 7.1) и Xiaomi (i7 8550U) с qemu-E2K.

Скриншот 149. Тест dav1d (из C кода с -O4 и -ffast) на Эльбрус 8С (OSL 7.1) и Xiaomi (i7 8550U) с qemu-E2K.

Если сравнивать мои результаты в эмуляции на Xiaomi с теми, что были у Эльбрус 8С, то мой Xiaomi медленнее в среднем в 90 раз. Не в 4 раза, как, когда мы на Эльбрусе через RTC сравнивали с Xiaomi dav1d, собранный из Ассемблера под x86, а в чёртовых 90 раз!!! i7 соснул в 90 раз! Ахренеть!

Да, уточню: эмулятор не задействует AVX и SSE инструкции, т.е. по идее при грамотной бинарной трансляции можно было бы выжать больше скорости с E2K кода при запуске на x86 машине. Но альтернатив эмулятору нет, а с ним, сами видите, производительность просела в 165 раз. Тяжко x86 машина жуёт E2K код. Вот что будет, если натянуть сову на глобус 3 стека на 1 стек и в целом начать работать с «макетом» E2K процессора в x86 среде.

А могут ли инструкции AVX и SSE в значительной мере повлиять на ситуацию? Или же работа с данными в 3 стека и прочие нюансы архитектуры E2K имеют больше значения для x86 процессора, чем инструкции SSE/AVX?

Почему MATLAB на процессорах AMD работает медленнее, чем на Intel. Источник: reddit.

Скриншот 150. Почему MATLAB на процессорах AMD работает медленнее, чем на Intel. Источник: reddit.

Если помните, в 2019-м году был скандал, связанный с тем, что библиотека Intel для мат. задач на процессорах AMD задействовала устаревшие инструкции SSE 1, тогда как с Intel использовались свежие AVX. Эта «дискриминация» приводила к тому, что производительность CPU от AMD в MATLAB и других инструментах была в несколько раз ниже.

Разница между SSE 1 и AVX инструкциями на Источник: статья на habr.

Скриншот 151. Разница между SSE 1 и AVX инструкциями на Источник: статья на habr.

Тогда и в статьях на habr фигурировала эта информация. И вот в этом и заключается загвоздка. На процессорах AMD обход ограничений и принудительное задействование AVX инструкций вместо SSE 1 позволял увеличить производительность максимум в 4 раза (зависит от задачи).

Допустим, вы сможете ускорить эмулятор в 5 раз за счёт использования SSE и AVX. Окей, разница тогда сократится со 165 раз до 33 раз в сравнении с нативным исполнением команд. Но это всё равно невероятная разница.

И единственный вывод, к которому я прихожу в этой главе: если вам нужен процессор с богатой аппаратурой для обеспечения высокой степени защищённости при работе, хрен вы что найдёте быстрее Эльбруса. Да, во многих задачах, если не оптимизировать ПО специально под него, он будет не особо быстр. Но среди защищённых процессоров нет ничего быстрее.

Эх, вот за этот аспект моя статья и не будет тиражироваться МЦСТ. Но я уже решил, что лучше это осветить, так что тут уж извините, куда деваться.