Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine


    Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.


    В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно – производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас «никакая», и чтобы догнать «топовых» производителей потребуются десятилетия (т.е. в условиях нынешней реальности — никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем «догнать и перегнать» ведущих мировых производителей процессоров.


    Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры x86-64.


    Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


    Регистрация на вебинар


    Тестовый стенд


    Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ «сырой емкости» или 5,7 ТБ «полезной» емкости, если используем RAID-10).


    Схематично стенд выглядит следующим образом.



    Стенд №1 e2k (Эльбрус)


    Конфигурация оборудования следующая:


    • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) – 1шт.
    • Коммутатор FC 16 G – 2 шт.
    • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) — 1 шт

    Стенд №2 x86-64 (Intel)


    Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на x86-64:


    • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) – 1шт.
    • Коммутатор FC 16 G – 2 шт.
    • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) — 1 шт

    Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно «плохо, но не долго». Эльбрус 8СВ (в наличии его у нас пока нет, но скоро будет) поддерживает DDR4.


    Методика тестирования


    Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


    Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем компрессию, дедупликацию и RAM-кэш.


    Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


    Выполняться будут основные и популярные сценарии использования СХД, в частности:


    первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


    1) Случайное чтение маленькими блоками 4k
    a. Размер блока = 4k
    b. Чтение/запись = 100%/0%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Full Random


    2) Случайная запись маленькими блоками 4k
    a. Размер блока = 4k
    b. Чтение/запись = 0%/100%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Full Random


    вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


    3) Последовательное чтение маленькими блоками 4k
    a. Размер блока = 4k
    b. Чтение/запись = 100%/0%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Sequential


    4) Последовательная запись маленькими блоками 4k
    a. Размер блока = 4k
    b. Чтение/запись = 0%/100%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Sequential


    третья группа тестов эмулирует работу потокового чтения (пример – онлайн трансляции, восстановление резервных копий) и потоковой записи (пример – видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


    5) Последовательное чтение большими блоками 128k
    a. Размер блока = 128k
    b. Чтение/запись = 0%/100%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Sequential


    6) Последовательная запись большими блоками 128k
    a. Размер блока = 128k
    b. Чтение/запись = 0%/100%
    c. Количество работ = 8
    d. Глубина очереди = 32
    e. Характер нагрузки = Sequential


    Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.


    Результаты тестов


    Результаты тестов сведены в две таблицы.


    Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



    Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



    Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


    Если говорить о случайной нагрузке небольшими блоками, то:


    • с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
    • с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

    В последовательной нагрузке небольшими блоками картина другая:


    • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень «не любит» последовательные нагрузки небольшими блоками. Явно есть над чем работать.

    А вот в последовательной нагрузке большими блоками картина прямо противоположная:


    • оба процессора показали примерно равный результат в MB/s, но есть одно НО…. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры x86-64). Будем надеяться, что этот успех получит дальнейшее развитие.

    Есть ещё одна интересная особенность Эльбруса, на которую читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 – 30%, не более.


    О чем это говорит? О том, что Эльбрус «очень любит» запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.


    Выводы и ближайшее будущее


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


    Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


    При случайной записи небольшими блоками оба процессора показывают равные результаты.


    По показателям задержки Эльбрус выглядит значительно лучше Intel-а в потоковой нагрузке, т.е. в последовательном чтении и записи большими блоками.


    Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
    Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


    • информационные системы с преобладанием операций записи;
    • файловый доступ;
    • онлайн-трансляции;
    • видеонаблюдение;
    • резервное копирование;
    • медиа-контент.

    Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.


    Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО «МЦСТ» выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования — на том же процессоре и с теми же частотами.


    Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.


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


    Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами x86-64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


    Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар «ОколоИТ», чтобы в прямом эфире на эти вопросы дать ответы.


    В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


    Регистрация на вебинар


    Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

    AERODISK
    AERODISK — российский производитель СХД.

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

      +12
      Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня

      вы сильно отстали от жизни, протестированный e5 — это никак не «средний уровень».


      никто не говорит о топовых или даже средних процессорах, но вот что-то более-менее похожее из начальных современных xeon можно было взять, хотя бы silver 4215R.


      Эльбрус «очень любит» запись

      Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину.

      извините, но это уровень ниже плинтуса. что-то намерили, а где причины? тем более странно выглядит с учётом того, что вы тестируете не какое-то стороннее решение, а своё собственное.

        0
        silver 4215R другого класса и вчетверо дороже тестируемого.

        Современный аналог это Xeon Bronze 3204
          +1
          Если взять Е5 второго поколения, то SIlver в 10 раз дороже…
          Все таки E5 v4 уже выходят с эксплуатации и сравнивать с ними как-то не очень перспективно.
            +2
            silver 4215R другого класса и вчетверо дороже тестируемого.

            silver дороже эльбруса?

              +1
              Цены на Эльбрусы сложновато найти в публичном доступе… Если очень поискать, то можно найти предложение Е8С-mITX за 133 тыр (~1600 USD, это материнка с процессором, без памяти и прочего). За такую цену можно взять что-то на Xeon Silver притом еще с корпусом в сборе…
                0
                зато можно найти тендеры на СХД Aerodisk от наших госов.
                в одном из найденных тендеров на закупку AERODISK Engine N2 фигурировала начальная цена в почти 5 млн. похоже мой коммент к прошлому посту про схд на эльбрусах про то, что за цену этого схд можно собрать 25-гигабитную сеть и гиперконвергентный кластер на винде целиком на sata ssd оказывается не так далеко от истины. и эти 5 млн были на sas hdd+ несколько, видимо, кэширующих SSD.
                Да, это цена не на решение на эльбрусах, но есть подозрение, что на эльбрусе дешевле не выйдет.
                  –1
                  Я нашел какой-то тендер на 4.5 млн рублей, видимо это оно. К сожалению я не знаком с номенклатурой, чтобы понять насколько это нормально. Но обычно в тендерах кроме СХД предполагается еще договор на обслуживание, а они у любого вендера стоят чуть ли не больше самой СХД. Так что в таком контексте цена может быть даже сопоставимой с аналогичным решением от NetApp или Dell EMC. Понятно что не имея их на руках сравнение в целом невозможно, конечно.
                  Но само собой, на Эльбрусе я предполагаю, что будет только дороже (возможно даже существенно).
            0

            Так ведь если сравнивать не с младшим xeon e5 2016 года, а с чем-то более современным/мощным, то всё станет совсем плохо.

              +1
              Поэтому и не сравнивают, ни в одном известном мне обзоре Эльбруса. Им же это продавать надо…
                0
                Поэтому и сравнивают везде, то с Intel Core 2-4 поколений (когда в ходу 8-9е), то с первыми «бульдозерами» (AMD FX), которые даже на момент своего выхода (почти 10 лет назад) большинство дразнило «ну первый блин комом» и «да лучше бы они просто Феномы на новый тех процесс перевели».
                  +2
                  Справедливости ради, Эльбрус 8С тоже 2016 года.
                  И сравнивался, насколько я понимаю, «середнячок» схожей тактовой частоты (даже более высокой, Эльбрус 1300 Мгц, Xeon — 1700)
                    0

                    Имхо более справедливый способ сравнения — производительность на единицу денег, только вот именно эта составляющая остаётся тайной

                +2

                Сам работаю с эльбрусами. Могу сказать точно что "догнать и обогнать" более чем реально, если бы не несколько НО которые в суровых реалиях почти военной разработки не стопорили процесс.

                  +5
                  «Не хватает кадров и ресурсов»
                    +3

                    это как раз мелочи жизни
                    а вот тотальная закрытость всего и вся очень сильно втыкает палки в колёса.

                      +1
                      Цитату не следует воспринимать в буквальном смысле, а лучше ознакомиться с первоисточником.
                        0

                        Попытался найти первоисточник, но увы.

                          +4
                          Картинка
                          image
                  +16

                  Что за идиотская парадигма "догнать и перегнать"? Вы ещё постучали бы башмаком и помахали кукурузой…
                  Ощущение, что идеологически по крайней мере автор застрял в 60х годах, когда такие лозунги со всех сторон вещали. Вот такая тупая гонка была нацелена на сиюминутный результат в угоду качеству. Смиритесь, вы никогда не перегоните Интел и Амд. Сконцентрируйтесь на качестве и цене и найдёте свою нишу. А от того что это Русские процессоры, они в плане практического использования лучше не стали…

                    +2
                    Хм. Догнать и перегнать — это парадигма жизни. Устройство (должно) обладать списком конкурентных преимуществ. Вот их и ищут (пока безуспешно). И планируют в каких областях следующие устройства будут более конкурентными (это вряд ли).
                      0
                      Иногда Не должно. Как госкорпорации не обязаны приносить прибыль.

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

                      Или вы правда думаете что эту продукцию собираются позиционировать на потребительский (коммерческий) и тем более зарубежный рынок?)
                      +8

                      Думаю, что нишу они и так нашли: российская разработка по сути для государственных нужд. Решающий фактор: отсутствие иностранных закладок. Работает и ладно.

                        +3
                        Совершенно верно! Считаю что надо не допиливать под свою архитектуру готовые образцы ПО, а создать своё, работающее со всеми преимуществами архитектуры и заточенное под них, тогда производительность может быть даже больше в ряде узконаправленных задачах. На них и делать ставку.
                        +9

                        А можно сделать такой же тест, но в vdbench и с включенной компрессией, дедупликацией и кэшем?

                          +6
                          Вот да. Отключить все задачи, где работает процессор, а затем сравнивать.
                            +1
                            Ну мне кажется, что СХД в продакте, в любом случае будет работать с включенной компрессией, дедупликацией и кэшем? Будь он на Intel/AMD или же на Эльбрусе.

                            Надо же сравнивать их в условиях максимально приближенных к реальной эксплуатации и делать выводы исходя из этого. А выключать оптимизацию нагрузки на CPU чтобы увидеть разницу в процессорах, это же мало что даст… принять решения на основании этого будет сложно.
                          +8

                          А можно посчитать все то же самое, но в деньгах? Сравнение iops в сферическом коне — хорошо, но давайте производительность на доллар выделенного на схд бюджета пересчитаем? Спасибо!

                            0
                            Вангую — 8:1 в пользу х86.
                              0
                              16:1, но что стоят доллары, когда ты под санкциями. Как глонассы делать-то? (40% импорта по самым скромным оценкам)
                                +3
                                Но где Глонасс и где СХД?
                                  +1
                                  Аргумент с санкциями звучит немного странно, с учетом того что Эльбрус-8С делается на TSMC и под более жесткие санкции попадет и его производство.
                                    –1

                                    Ну вот не знаю, как нужно накосячить, чтобы процессоры x86/arm и винты попали в список запрещенки. Наверное, только северная корея под настолько жёсткими санкциями, не уверен. Ну и есть Китай, который продаст в любом случае. Объективно — делать свой национальный general purpose CPU — это безумие, конечно.

                                      +1
                                      Не конкретные процессоры, а доступ к продвинутой литографии (на которой можно производить что угодно и сложно проконтролировать если поставляются ПП пластины, а все остальные операции происходят уже на стороне заказчика).

                                      Свежий пример же буквально под рукой — Хуавей обложили санкциями и теперь он лишился доступа к ПП производству на TSMC.

                                      А одно время и весь Китай (а когда-то СССР/Россию) был под санкциями запрещающими поставки любых высокопроизводительных процессоров.
                                        0

                                        В китае есть свои фабы, самый передорвой до 14нм
                                        https://ru.wikipedia.org/wiki/SMIC

                                          0

                                          Угу, и этот SMIC тоже не может поставлять процессоры для Huawei — санкции.

                                            +1
                                            Но так как на SMIC тоже объявили санкции, то возможно и сможет)
                                +10
                                Странная статья. Интел выигрывает почти по всем iops, но
                                Сравнительные тесты процессоров… показали примерно равные и одинаково достойные результаты. Кажется, этим выражением можно и описать всю платформу Эльбрус пока что.

                                А фокус с задежкой в 0,5мс у Эльбруса вообще похож на ошибку измерения. Может где кэш случайно прогретый забыли. Ну не согласуется он со строками выше в таблице (а в целом там задержка нарастает сверху вниз, либо остается на одном уровне с какой-то из предыдущих строк).
                                  +3
                                  Мне бы вообще хотелось увидеть скрипты тестирования и размеры тестовых сетов данных. Потому что гонять час можно цикличную перезапись файла размером 32 МБ или что-нибудь в таком же духе и это будет чуть другая нагрузка…
                                    +1
                                    Может и не ошибка, в просто разница в используемом наборе ОС/ПО и их настроек. Судя по тому, что итоговая скорость примерно та же (а на чтение даже выше), а задержи отличаются на порядок, то похоже на разные алгоритмы работы с очередями команд диска в условиях многопоточной нагрузки.
                                      +1
                                      Судя по тому, что итоговая скорость примерно та же (а на чтение даже выше), а задержи отличаются на порядок, то похоже на разные алгоритмы работы с очередями команд диска в условиях многопоточной нагрузки.

                                      Верный вывод. Вообще архитектура e2k значительно отличается от других. Я думаю мы ещё много нового о ней узнаем.


                                      Так получилось, что адаптацией Эльбруса под реальные задачи практически никто (кроме МЦСТ и Альта) серьезно в России не занимался. Мы походу одни из первых, вот и ловим нежданчики.

                                      +1
                                      А фокус с задежкой в 0,5мс у Эльбруса вообще похож на ошибку измерения. Может где кэш случайно прогретый забыли. Ну не согласуется он со строками выше в таблице (а в целом там задержка нарастает сверху вниз, либо остается на одном уровне с какой-то из предыдущих строк).

                                      Мы тоже так подумали, поэтому перепроверили все два раза. Кэшы на хосте и СХД были выключены.


                                      Дабы не вводить народ в заблуждение в следующей статье, где будем тестировать СХД на Эльбрусе (уже на ядре 5.4.) выложим побольше тех. данных.

                                      +9
                                      Статья в целом не тянет, на мой взгляд, по уровню на сравнение, скорее на блог-замтеку с целой рекламы изделий. Чтобы было интересно с технической точки зрения, стоило бы добавить:
                                      1. Информацию о ПО в по обоим СХД и клиентам в саму статью. Сейчас что-то про ядро есть только для СХД на Эльбрусе. Про sysctl'и нет вообще нигде и ничего.
                                      2. Подробная разбивка по загрузке CPU. Например, сейчас абсолютно непонятно что там по ядрам, так как есть только некая общая мера, я б даже сказал средняя. В идеале должно быть два графика — CPU по ядрам от времени и задержек от времени.
                                      3. Непонятно какие значения подразумеваются под пропускной способностью и задержкой — минимум, максимум, среднее, какой-то конкретный перцентиль?
                                      4. Хотелось бы увидеть обоснование выбора конкретного железа (ну кроме «другого не было»). Потому что E5-2603v4 все же один из младших CPU в линейке с ценой в 213$ и совсем непонятно зачем он был выбран.
                                      5. Хотелось бы увидеть анализ почему такой latency в ситуациях когда он выше ожидаемого.
                                      6. Непонятно почему не было более приближенных к реальным нагрузкам тестов — например смешанных нагрузок?

                                      Без ответов на эти вопросы совсем непонятно как можно делать какие-либо выводы. Например близость показателей чтения и записи могла быть обусловлена тем, что СХД на Эльбрусе на чтении просто напросто уперлось либо в шину либо в близкую к 100% утилизацию какого-то другого ресурса.

                                      И я еще уверен, что люди профессионально занимающиеся СХД могут задать еще больше вопросов, которые я просто по незнанию тематики упустил.

                                      А вместо непонятного вебинара (который еще и будет через несколько недель), где требуется предоставить много персональных данных, хотелось бы все же видеть вовлечение в ответы на вопросы в комментариях.
                                        +2
                                        Еще забыл указать, что хотелось бы по возможности знать как были подключены диски, например какой SAS контроллер в обоих случаях и с какими настройками (например в каком режиме) и модели дисков бы еще. Иначе сложно сказать, какие значения были бы теоретически ожидаемыми и возможными (простая проверка на разумность полученных значений — попытаться предсказать что можно выжать из СХД в теории и сравнить с практикой)
                                          +2
                                          Информацию о ПО в по обоим СХД и клиентам в саму статью. Сейчас что-то про ядро есть только для СХД на Эльбрусе. Про sysctl'и нет вообще нигде и ничего.

                                          ПО на обоих системах одинаковое A-CORE актуальной версии. Оно идентично на системах Engine и Восток


                                          Подробная разбивка по загрузке CPU. Например, сейчас абсолютно непонятно что там по ядрам, так как есть только некая общая мера, я б даже сказал средняя. В идеале должно быть два графика — CPU по ядрам от времени и задержек от времени.

                                          Можно сделать, идея хорошая, спасибо. На теста ядра 5.4 выложим побольше графиков.


                                          Непонятно какие значения подразумеваются под пропускной способностью и задержкой — минимум, максимум, среднее, какой-то конкретный перцентиль?

                                          Среднее за час


                                          Хотелось бы увидеть обоснование выбора конкретного железа (ну кроме «другого не было»). Потому что E5-2603v4 все же один из младших CPU в линейке с ценой в 213$ и совсем непонятно зачем он был выбран.

                                          Это стандартный процессор в системе Engine N2 для недорогой гибридной конфигурации (для более мощных, например all-flash конфигураций используются значительно более мощные процессоры).


                                          Хотелось бы увидеть анализ почему такой latency в ситуациях когда он выше ожидаемого.

                                          Не очень понятен вопрос, поясните какого рода анализ вы ждете.


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

                                          Вам прям всё и сразу хочется, так не бывает :-). Сейчас сделали первое приближение. Это не последняя публикация про производительность наших СХД на Эльбрусах. Будут ещё минимум две. Не всё сразу :-)

                                            +3
                                            ПО на обоих системах одинаковое A-CORE актуальной версии. Оно идентично на системах Engine и Восток


                                            Из статьи в текущей момент абсолютно не ясно какое ядро и настройки, как минимум. Это может быть важно, как минимум для воспроизведения ситуации. Потому что мне, как читателю — абсолютно непонятно что такое «A-Core» и что это означает.

                                            Среднее за час

                                            Довольно плохая метрика, потому что несколько экстримально низких или экстримально высоких значений могут испортить картину. Советую подумать о перцентилях.

                                            Это стандартный процессор в системе Engine N2 для недорогой гибридной конфигурации (для более мощных, например all-flash конфигураций используются значительно более мощные процессоры).


                                            В статье это не указано, а также это не отвечает почему именно этот процессор выбран для железки. Иначе создается впечатление небольшого читерства когда берется система с процессором за условную 1000$ и ей противопоставляется относительно устаревшая система с процессором ценой в 300$ (на момент выхода).

                                            Не очень понятен вопрос, поясните какого рода анализ вы ждете


                                            Смотрите, сейчас Вы получили какие-то значения и сделали выводы. Проблема выводов в том, что полностью отсутствует все рассуждение между «мы получили 91к write iops и 100k read iops» и «Эльбрусы больше предпочитают запись». Просто выводы довольно спорные и не очевидные и без анализа причин таких чисел (архитектурного анализа, типа ткнуть в документацию и сказать «вот эта штука объясняет», либо настроек системы, версии ядра или еще чего-то подобного) такие выводы кажутся абсолютно неочевидными, более того, такая картина как описана в статье именно в плане разницы read vs write производительности больше похожа на то, что вы уперлись при чтении в какое-то узкое место (чтоб понять в какое — как раз и нужны графики загрузки цпу по типу и ядрам, анализ банального количества прерываний, теоретические расчеты задержек и пропускной способности по шинам и т.п.).

                                            Также и про latency в 0.3мс для Эльбруса — интересно бы увидеть объяснение отличий, с анализом причин такой разницы (например снятые системые метрики, конфигурация теста и какое-то доказательство что вы не просто случайно протестировали кэш).

                                            Ну и опять же, хочется больше деталей про условия тестирования, так как сейчас из всего железа известны только модели ЦПУ. Неизвестно ни какие диски использовались, ни информации про дисковый контроллер, поэтому анализ читателем — затруднителен, если вообще возможен.
                                              0
                                              Это не последняя публикация про производительность наших СХД на Эльбрусах. Будут ещё минимум две

                                              обратите внимание на этот комментарий:
                                              https://habr.com/ru/company/aerodisk/blog/520888/#comment_22117148
                                              что-то у вас не сходится

                                            +2
                                            А что там с поддержкой RDMA? и разве имеет смысл в, том, что казалось бы, должно быть future-proof решением использовать FC, когда проще строить сети на Ethernet(учитывая что сейчас есть недорогие 25-40-100 gbps ethernet коммутаторы? Более чем уверен, что если использовать iscsi over rdma, задержки и скорости, внезапно, будут намного ниже
                                              +1

                                              RDMA в наших системах ожидается в q1 2021. На тему future-proof и FC. Если отбросить маркетинг, на тему что "FC умер, т.к. есть RDMA и 100GbE за недорого", а посмотреть на реальные задачи реальных заказчиков, то пока все идет к тому, что FC ещё будет жить очень долго.

                                                0

                                                Какой ещё маркетинг? Мы можем открыть прайс mellannox и увидеть 25gbps коммутаторы за 600 с копейками тысяч.и говоря про реальные задачи: давайте посчитаем, что будет дешевле:1) оборудовать и поддерживать чисто Ethernet сеть 2) оборудовать и поддерживать fc и Ethernet сети. Надо помнить, что Ethernet во втором сценарии используется не только для схд, а вот FC уже большого толку на мой взгляд не имеет

                                              +3
                                              Пессимисты говорят, что производительность Эльбруса сейчас «никакая», и чтобы догнать «топовых» производителей потребуются десятилетия
                                              ну учитывая что в ваших же тестах эльбрус уступает xeon'у 8-летней давности, получается задержка как раз порядка 10 лет
                                              т.е. в условиях нынешней реальности — никогда
                                                  –1

                                                  А толку-то, если Эльбрус 8С отстаёт на 1-2 поколения. Для сравнения надо было брать ещё более старый XEON c DDR3, PCIe 2.0 и т.д. Там бы и цифры сопоставимые получлись бы.

                                                    +1
                                                    да, перепутал с другим E5-2603. Схемы именования конечно что-то с чем-то
                                                      0
                                                      Да, у Intel в серверных процессорах раньше был цирк еще тот (сейчас в общем тоже, но уже поменьше). Одна и так же модель процессора, но с разными приписками в конце (версия 2/3/4/etc) обозначает совершенно разные процессоры из разных поколений с сильно разными характеристиками между которыми вообще почти ничего общего нет. Кроме разве что рыночного позиционирования (но и то — в разные годы).

                                                    +4
                                                    Я не думаю, что без какого-либо анализа результатов со стороны авторов и более подробной методики тестирования тут справедливо делать какие либо выводы, так как непонятно как оценивать результаты из статьи. Сейчас просто напросто не объяснено чем обусловлены отличия и какие вообще теоретически возможные результаты могли бы быть получены.
                                                    –1
                                                    На советской компьютерной промышленности был поставлен крест в 60-х годах из за трагического решения ЦК полностью скопировать процессор IBM System/360, вместо того чтобы развивать собственные на тот момент очень перспективные разработки.
                                                      0
                                                      Думаю, что в то время и на той технике было почти не реально достичь достойных результатов, поэтому решили скопировать.
                                                      +3
                                                      а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем «догнать и перегнать» ведущих мировых производителей процессоров
                                                      А производители, надо понимать, вежливо постоят и подождут.
                                                      «Здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее»
                                                        –1

                                                        если сравнивать планы эльбруса с тем, что сделали intel и amd за последнюю пару лет, то становится грустно, разрыв только увеличился.

                                                        +5
                                                        Есть интересный вопрос: а из-за каких таких «особенностей архитектуры» Эльбрус выдает вдесятеро меньшие задержки в последних двух тестах? Потому как если его отставание в первых четырех — это ожидаемое поведение, то внезапный триумф здесь — это довольно странно, и без внятного объяснения будет классифицирован как подкрутка результатов.
                                                          +1

                                                          В архитектуре Эльбруса особенностей и разных "ноу-хау" довольно много, например, суперскалярность, внеочередное исполнение операций, анализ кода с помощью компилятора и т.п.


                                                          e2k крайне интересная архитектура и, на наш субъективный взгляд, потенциал её значительно превышает x86-64(amd64).


                                                          Более подробно про архитектуру e2k можно почитать в нашей статье:


                                                          https://habr.com/ru/company/aerodisk/blog/482434/


                                                          В ней же (внизу) есть ссылки на источники, где больше деталей.


                                                          Кроме того, вопросы по существу можно будет задать непосредственно представителю разработчика Эльбруса, Константину Трушкину. Ссылка на регистрацию в статье выше.

                                                            +3
                                                            В архитектуре Эльбруса особенностей и разных «ноу-хау» довольно много, например, суперскалярность, внеочередное исполнение операций

                                                            Это всё есть в x86 уже лет 20. В статье конечно написано, что у нас оно появилось раньше, но конкретно сейчас этим никого не удивить.
                                                            анализ кода с помощью компилятора

                                                            Вот такое пытался провернуть Intel в процессорах Itanium. И где они сейчас?
                                                              0
                                                              Тогда и условия другие были. Сейчас во времена ml/ai и возросших вычислительных возможностей появилась возможность применить это для эффективной оптимизации при компиляции.
                                                              +Многое ПО сегодня шлет телеметрию в облако, сюда же можно включить данные профилировки для обучения компилятора
                                                                0
                                                                Это всё есть в x86 уже лет 20.

                                                                В итаниуме — да, как и другие "ноу-хау" в других архитектурах по отдельности, но не в x86.


                                                                Вот такое пытался провернуть Intel в процессорах Itanium. И где они сейчас?

                                                                В x86 внезапно, EFI QPI и наработки по компилятору все перетекли в x86 из итаниума.

                                                                  0
                                                                  но не в x86.

                                                                  Чего из процитированного списка
                                                                  например, суперскалярность, внеочередное исполнение операций

                                                                  нет в x86?
                                                                  В x86 внезапно, EFI QPI и наработки по компилятору все перетекли в x86 из итаниума.

                                                                  Взяли пару удачных вещей, в основном, для лёгкого переноса с тонущего на актуальную архитектуру.
                                                                    0
                                                                    Чего из процитированного списка нет в x86?

                                                                    Если по чесноку то ничего, x86 это система команд (или архитектура в терминах интела), которая реализовывалась поверх самых разных микроархитектур в том числе и без внеочередного исполнения (например старые атомы). Так что у интела суперскалярность и внеочередное исполнение часть микроархитектуры конкретного семейства и появилось оно впервые не 20 лет назад а больше, в процессорах пентиум если я не ошибаюсь да и чуть ли не позже чем оно появилось у всех остальных.


                                                                    А вот как раз спекулятивность/суперскалярность на уровне системы команд (как в эльбрусе) появилась в итаниуме 20лет назад. Поэтому даты верные, сравнения не верные.


                                                                    Взяли пару удачных вещей

                                                                    Взяли просто x86 от которого они уже поняли что не избавятся и посадили на итаниумовскую шину и все остальное так появилось поколение i7-i5, а сам итаниум и легаси x86 платформу закопали. AMD кстати свой HyperTransport купила у трансметы (надеюсь не надо говорить кто это), да и технологии всякие типа nxBit тоже оттуда понатасканы, так что вклад внесен немалый.

                                                                      +1
                                                                      А вот как раз спекулятивность/суперскалярность на уровне системы команд (как в эльбрусе) появилась в итаниуме 20лет назад.

                                                                      так на уровне команд это сомнительное благо, динамическая суперскалярность явно более продвинутая вещь. тот же SMT целиком и полностью существует за счёт этой самой суперскалярности.
                                                                      VLIW, конечно имеет свои плюсы, в первую очередь он гораздо проще, за счёт этого тем же числом транзисторов в числодробилках можно большей производительности достичь, но числодробилки — это далеко не все задачи.

                                                                        0
                                                                        тот же SMT целиком и полностью существует за счёт этой самой суперскалярности.

                                                                        Это вопрос каверзный, из за того что ОоО-суперскаляр не может загрузить свои исполнительные блоки ему придумывают SMT, чтоб хоть забить его разными потоками. Влив в такой парадигме существовать не обязан если тебе надо много потоков — делай влив с небольшим числом устройств и пусть их будет много, а то и вообще оставь одно большое и окружи его кучей мелких как будто у тебя IBM cell


                                                                        VLIW, конечно имеет свои плюсы, в первую очередь он гораздо проще, за счёт этого тем же числом транзисторов в числодробилках можно большей производительности достичь, но числодробилки — это далеко не все задачи.

                                                                        Ну вот статически откомпилированные программы только в числодробилках хорошо работают? Нет, но какие то вещи на них делать сложнее чем на динамических языках, а какие то вещи (как например ООП в плюсах) так и вовсе оказалось можно вполне реализовать статически без рантайма и как то это работает вполне успешно.
                                                                        Вот так же и с вливом примерно

                                                                          +1

                                                                          а как у эльбруса обрабатывается обращение к памяти, вызвавшее промах кэша? ЕМНИП, тормозится исполнение всего потока команд.
                                                                          процессор с SMT в таком случае может пока исполнять задания из параллельного потока.


                                                                          или если компилятор не смог нагрузить всю ширину инструкции — исполнительные блоки у VLIW будут простаивать, а в случае SMT они могут быть заняты чем-то ещё.


                                                                          ИМХО правильнее делать суперскалярность на основе потока мелких команд с явно прописанными зависимостями, условно говоря, как в makefile. это было бы и относительно просто в реализации, и позволило бы более полно утилизировать исполнительные блоки за счёт SMT.

                                                                            0
                                                                            а как у эльбруса обрабатывается обращение к памяти, вызвавшее промах кэша? ЕМНИП, тормозится исполнение всего потока команд.
                                                                            Никак, да, боль и унижение. Хотя вообще то мог бы на другом конвеере что то исполнять в таких случаях, у него их там несколько штук для подготовки колов/переходов.

                                                                            процессор с SMT в таком случае может пока исполнять задания из параллельного потока.

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


                                                                            ИМХО правильнее делать суперскалярность на основе потока мелких команд с явно прописанными зависимостями, условно говоря, как в makefile

                                                                            Еще один плюс VLIW на нем наглядней видно как все работает и гораздо быстрее все усваивать. Процессоры устроены немного сложней

                                                                    +1
                                                                    В итаниуме — да, как и другие «ноу-хау» в других архитектурах по отдельности, но не в x86.


                                                                    Суперскалярные x86: P5 (Pentium первый), Nx586, AMD K5. То есть примерно с 1993 года.

                                                                    Внеочередное исполнение операций — Pentium Pro и AMD K5 были первыми среди x86. То есть с ~1995 года.

                                                                    А так уши у всего этого растут вообще из мейнфреймов 196x годов.

                                                                    Или имелось в виду, что в x86 это не ноу-хау?
                                                                      +1

                                                                      Не имелось в виду то что выше написал. В эльбрусах и итаниумах как такового внеочередного исполнения вообще нет они строго in-order superscalar, но там есть возможность переставить команды


                                                                      с помощью компилятора и т.п.

                                                                      и таким образом реализуется внеочередное исполнение. И его нельзя напрямую сравнивать с железным внеочередным исполнением, они разные и в чем-то лучше один, а в чем-то другой.

                                                                        0
                                                                        В чем железное внеочередное исполнение может быть хуже? В потреблении энергии что ли?
                                                                          +1
                                                                          В чем железное внеочередное исполнение может быть хуже? В потреблении энергии что ли?

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

                                                                            +1
                                                                            Планировщику и не нужно видеть команды, которые когда-то в него придут, ему нужно нагружать работой пул исполнительных устройств. Команда пришла, есть где ее исполнять — отдаем, нет — сохраняем и парсим следующую. Более того, при прочих равных фронтенд, обрабатывающий одну команду, будет работать быстрее, чем VLIW-фронтенд, обрабатывающий пакет команд, следовательно команда сможет уйти на выполнение раньше и отработать быстрее. Но да, все эти асинхронные планировщики и исполнительные устройства осилить намного сложнее, чем VLIW.
                                                                              +1
                                                                              Команда пришла, есть где ее исполнять — отдаем, нет — сохраняем и парсим следующую.

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


                                                                              будет работать быстрее, чем VLIW-фронтенд, обрабатывающий пакет команд, следовательно команда сможет уйти на выполнение раньше и отработать быстрее.

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

                                                                                0
                                                                                внеочередное исполнение вытаскивает наиболее потенциально долгие команды (например лоады или деление) и исполняет их как можно раньше
                                                                                И это еще быстрее. А VLIW сложил два числа и ждет соседний load.
                                                                                Как он может быть быстрее, если во вливе ассемблер это практически уже микрокод который прям как написан так и исполняется, декодирование там настолько простое что команда за один такт должна оказаться на конвейере иначе код просто ломается.
                                                                                Во-первых, я сказал «при прочих равных» — если Вы представили идеальный простой VLIW-процессор, то сравнивайте с идеальным простым обычным процессором, который тоже мгновенно все декодирует. Во-вторых, даже на современных реализациях x86, которую ругают за сложное декодирование все кому не лень, упереться во фронтенд практически невозможно.
                                                                                  0
                                                                                  И это еще быстрее. А VLIW сложил два числа и ждет соседний load.

                                                                                  Некие меры в Э предприняли:
                                                                                  www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf

                                                                                  Для решения проблемы с блокировками конвейера, вызванными операциями чтения, в архитектуре
                                                                                  «Эльбрус» предусмотрено несколько методов:
                                                                                  ˆ Ациклические участки кода:
                                                                                  – совмещение блокировок;
                                                                                  – ограничение на простановку маловероятных чтений в спекулятивный режим.
                                                                                  ˆ Цикловые участки кода:
                                                                                  – cовмещение блокировок в конвейеризированных циклах;
                                                                                  – выявление регулярных чтений, предподкачка с помощью prefetch (ld->empty);
                                                                                  – использование аппаратно-программного механизма для подкачки линейных данных


                                                                                  Если при выполнении программы эти меры подействовали, то данные будут к моменту использования лежать тепленькими в кэше
                                                                                    +1
                                                                                    Так как это пособие является практическим, описание совмещения блокировок компилятором и про-
                                                                                    становки маловероятных чтений в спекулятивный режим будет пропущено.

                                                                                    И как без описания понять что это такое? Про линейные участки и префетчь хоть понятно примерно, а вот что такое "совмещение блокировок" да еще каким то программным способом — непонятно.

                                                                                    0
                                                                                    И это еще быстрее. А VLIW сложил два числа и ждет соседний load.

                                                                                    Конвейризованные архитектуры так не работают, там команда за командой запускается каждый такт и никто никого не ждет, но если у тебя следующая команда оперирует теми же регистрами на которых ты в предыдущем такте сложение или лоад запустил, то она будет ждать пока регистры не будут готовы. Арифметика имеет фиксированное число стадий исполнения поэтому легко предугадывается в коде, и до нее можно еще пихнуть команд. Ну а нечего пихнуть можно выровнять нопами.
                                                                                    Другое дело лоад, при котором неизвестно где данные окажутся и первая же команда которая обращается к этому регистру, заблокирует конвеер на ожидании готовности. У оут-оф-ордера есть преимущество — он может отложить все операции которые зависят от лоада. Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается. Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.


                                                                                    Так что преимущество не очевидно так как ОоО тоже далек от идеала.


                                                                                    если Вы представили идеальный простой VLIW-процессор, то сравнивайте с идеальным простым обычным процессором

                                                                                    Я представил существующий в железе и работающий эльбрус, и можно его же представить в виде обычного риск процессора, просто выписав все инструкции из широких команд в линеечку — декодер будет такой же, просто во вливе он широкий параллельный а в риске маленький на одну инструкцию.

                                                                                      0
                                                                                      Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается.
                                                                                      Да там ведь кэши куда ни глянь, разве нет?
                                                                                      Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.
                                                                                      Нет, не получится, потому что VLIW не предлагает ничего принципиально более гибкого по сравнению с OoO. Если дефолтному OoO приходится ждать — значит есть некая затратная операция, от которой зависит дальнейшее выполнение, которую VLIW придется точно так же ждать. Только он в это время ничего не сможет делать (на Эльбрусе в случае чтении из памяти вроде как сможет, судя по информации от yalex1442, но это уже по сути небольшой отход от VLIW-парадигмы). А еще ведь есть спекулятивное выполнение и подобные оптимизации, которые во VLIW просто неприменимы.
                                                                                      Я представил существующий в железе и работающий эльбрус
                                                                                      Ну если его сравнить с существующим в железе и работающим x86, то сами знаете что получается.
                                                                    +1
                                                                    В общих чертах я осведомлен об этих особенностях, но сама по себе эта осведомленность не наталкивает меня ни на какие выводы. Вот и хотелось бы что-бы кто-нибудь пояснил подробнее.
                                                                    P. S. Ну и VLIW в 2020 уж никак на ноу-хау не тянет, разве что на хорошо забытое старое…
                                                                  +7
                                                                  А ничего, что задержка и iops — это величины, напрямую связанные формулой через параллелизм?

                                                                  iops = параллелизм / задержка
                                                                  задержка = параллелизм / iops

                                                                  Таким образом, например, у вас:

                                                                  Intel (128k, T8Q32 read) = 2618 MB/s, то есть 20944 iops (1 io = 128 KB), то есть задержка ~12 мс
                                                                  E2K (128k, T8Q32 read) = 2918 MB/s, то есть 23304 iops, то есть задержка ~11 мс

                                                                  Откуда взяты цифры 0.4 и 5 мс — неизвестно, взяты с неба.
                                                                    +2
                                                                    А я кстати чисто случайно напилил свой сторадж. Блочный, распределённый, быстрый. vitastor.io
                                                                      –1
                                                                      И что? К чему это здесь? Тестировали на Эльбруасах? Нет, тогда к чему этот коментарий? Похвастаться?
                                                                        +1
                                                                        Ну да :) а что, прям нельзя? :)
                                                                          –1
                                                                          Ну вот протестируйте на Эльбрусах с Интелом, выложите результат сюда )
                                                                            +2
                                                                            Мне надо ядро 5.4+ и компилятор с поддержкой лямбд C++. Не уверен, что у них это есть — компилятор же закрытый. Больше того, они GPL нарушают в binutils — патченый binutils распространяют, а исходники к нему не дают.

                                                                            Собственно, в binutils есть objdump и когда они таки перестанут нарушать GPL — вся их Секретная Документация По Опкодам (тоже бред тот ещё, процессор с закрытой системой команд) в тот же момент перестанет быть секретной. В общем такая себе политика — как линуксы открытые запускать, так в первых рядах, а как GPL соблюсти…

                                                                            Ну и железо само в конце концов тоже не сказать чтобы просто взять, да :)) ещё и с дисками.
                                                                      –1
                                                                      Какая то лютая бредятина в статье. Тестить процессор на i\o операциях реально? При нагрузке 70% реально? Афтар жжот, мне даже лень обосновывать столь очевидную некомпетентность. Результаты по Cinebench в студию пожалуйста.
                                                                        +2

                                                                        не соглашусь. статью написала компания-разработчик СХД, в том числе и СХД на Эльбрусах, именно про производительность СХД и ожидаешь увидеть в этой статье.


                                                                        другое дело, что можно было бы сравнить влияние компрессии, дедупликации, разных уровней RAID на производительность СХД на базе Xeon/Эльбрус, это было бы интереснее.


                                                                        вообще статья больше расчитана на некомпетентных читателей ИМХО: «смотрите, у нас есть какие-то цифирки, Эльбрус где-то немного хуже, где-то много лучше, можно брать».

                                                                          +1

                                                                          Статья рассчитана на тех, кому это интересно.


                                                                          Задача данного теста — "голая" производительность на флэше.


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


                                                                          Повторим этот + добавим тесты с фичами (дедуп, компрессия, гибридные конфигурации и т.п.)

                                                                            0
                                                                            Резюмируя ваши слова, можно сказать, что если сравнивать Ладу и Ламборджини, то они едут плюс минус одинаково если у Ламбы ограничить педаль газа. Хорошая статья для телеканала ОРТ, для ура-патриотов и т.д.
                                                                          0
                                                                          Эльбрус 8*1,2=9,6
                                                                          Intel 6*1,7=10,2
                                                                          При прочих равных производительность примерно одинаковая, хотя интел на 6% мощнее.
                                                                          В целом цифры выглядят реалистично за исключением разницы на порядок, явно какая-то не отключенная буферизация.
                                                                            +2
                                                                            Только рассчитывать мощности таким образом абсолютно некорректно…
                                                                              0

                                                                              Это примерно как в машине пробовать считать мощность исходя из объема двигателя

                                                                              +1
                                                                              Тут исходники XP утекли… Может пришло время скомпилировать достойную ему ОС?
                                                                                +1

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

                                                                                  +1
                                                                                  Нарисовать результат ещё можно. )))

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

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