Комментарии 98
Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня
вы сильно отстали от жизни, протестированный e5 — это никак не «средний уровень».
никто не говорит о топовых или даже средних процессорах, но вот что-то более-менее похожее из начальных современных xeon можно было взять, хотя бы silver 4215R.
Эльбрус «очень любит» запись
Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину.
извините, но это уровень ниже плинтуса. что-то намерили, а где причины? тем более странно выглядит с учётом того, что вы тестируете не какое-то стороннее решение, а своё собственное.
Современный аналог это Xeon Bronze 3204
Все таки E5 v4 уже выходят с эксплуатации и сравнивать с ними как-то не очень перспективно.
silver 4215R другого класса и вчетверо дороже тестируемого.
silver дороже эльбруса?
в одном из найденных тендеров на закупку AERODISK Engine N2 фигурировала начальная цена в почти 5 млн. похоже мой коммент к прошлому посту про схд на эльбрусах про то, что за цену этого схд можно собрать 25-гигабитную сеть и гиперконвергентный кластер на винде целиком на sata ssd оказывается не так далеко от истины. и эти 5 млн были на sas hdd+ несколько, видимо, кэширующих SSD.
Да, это цена не на решение на эльбрусах, но есть подозрение, что на эльбрусе дешевле не выйдет.
Но само собой, на Эльбрусе я предполагаю, что будет только дороже (возможно даже существенно).
Так ведь если сравнивать не с младшим xeon e5 2016 года, а с чем-то более современным/мощным, то всё станет совсем плохо.
И сравнивался, насколько я понимаю, «середнячок» схожей тактовой частоты (даже более высокой, Эльбрус 1300 Мгц, Xeon — 1700)
Сам работаю с эльбрусами. Могу сказать точно что "догнать и обогнать" более чем реально, если бы не несколько НО которые в суровых реалиях почти военной разработки не стопорили процесс.
Сейчасть просто продвигают это в госсектор. После изменения закона о закупках, летом завернули закупку серверного и другого оборудования в нашей обасти на 500 лямов, потому что процессоры не российского производства. Полки отлично пойдут под реализацию нац.проектов вроде центрального архива медицинских изображений и других вещей.
Или вы правда думаете что эту продукцию собираются позиционировать на потребительский (коммерческий) и тем более зарубежный рынок?)
Думаю, что нишу они и так нашли: российская разработка по сути для государственных нужд. Решающий фактор: отсутствие иностранных закладок. Работает и ладно.
А можно сделать такой же тест, но в vdbench и с включенной компрессией, дедупликацией и кэшем?
Надо же сравнивать их в условиях максимально приближенных к реальной эксплуатации и делать выводы исходя из этого. А выключать оптимизацию нагрузки на CPU чтобы увидеть разницу в процессорах, это же мало что даст… принять решения на основании этого будет сложно.
А можно посчитать все то же самое, но в деньгах? Сравнение iops в сферическом коне — хорошо, но давайте производительность на доллар выделенного на схд бюджета пересчитаем? Спасибо!
Ну вот не знаю, как нужно накосячить, чтобы процессоры x86/arm и винты попали в список запрещенки. Наверное, только северная корея под настолько жёсткими санкциями, не уверен. Ну и есть Китай, который продаст в любом случае. Объективно — делать свой национальный general purpose CPU — это безумие, конечно.
Свежий пример же буквально под рукой — Хуавей обложили санкциями и теперь он лишился доступа к ПП производству на TSMC.
А одно время и весь Китай (а когда-то СССР/Россию) был под санкциями запрещающими поставки любых высокопроизводительных процессоров.
В китае есть свои фабы, самый передорвой до 14нм
https://ru.wikipedia.org/wiki/SMIC
Сравнительные тесты процессоров… показали примерно равные и одинаково достойные результаты. Кажется, этим выражением можно и описать всю платформу Эльбрус пока что.
А фокус с задежкой в 0,5мс у Эльбруса вообще похож на ошибку измерения. Может где кэш случайно прогретый забыли. Ну не согласуется он со строками выше в таблице (а в целом там задержка нарастает сверху вниз, либо остается на одном уровне с какой-то из предыдущих строк).
Судя по тому, что итоговая скорость примерно та же (а на чтение даже выше), а задержи отличаются на порядок, то похоже на разные алгоритмы работы с очередями команд диска в условиях многопоточной нагрузки.
Верный вывод. Вообще архитектура e2k значительно отличается от других. Я думаю мы ещё много нового о ней узнаем.
Так получилось, что адаптацией Эльбруса под реальные задачи практически никто (кроме МЦСТ и Альта) серьезно в России не занимался. Мы походу одни из первых, вот и ловим нежданчики.
А фокус с задежкой в 0,5мс у Эльбруса вообще похож на ошибку измерения. Может где кэш случайно прогретый забыли. Ну не согласуется он со строками выше в таблице (а в целом там задержка нарастает сверху вниз, либо остается на одном уровне с какой-то из предыдущих строк).
Мы тоже так подумали, поэтому перепроверили все два раза. Кэшы на хосте и СХД были выключены.
Дабы не вводить народ в заблуждение в следующей статье, где будем тестировать СХД на Эльбрусе (уже на ядре 5.4.) выложим побольше тех. данных.
1. Информацию о ПО в по обоим СХД и клиентам в саму статью. Сейчас что-то про ядро есть только для СХД на Эльбрусе. Про sysctl'и нет вообще нигде и ничего.
2. Подробная разбивка по загрузке CPU. Например, сейчас абсолютно непонятно что там по ядрам, так как есть только некая общая мера, я б даже сказал средняя. В идеале должно быть два графика — CPU по ядрам от времени и задержек от времени.
3. Непонятно какие значения подразумеваются под пропускной способностью и задержкой — минимум, максимум, среднее, какой-то конкретный перцентиль?
4. Хотелось бы увидеть обоснование выбора конкретного железа (ну кроме «другого не было»). Потому что E5-2603v4 все же один из младших CPU в линейке с ценой в 213$ и совсем непонятно зачем он был выбран.
5. Хотелось бы увидеть анализ почему такой latency в ситуациях когда он выше ожидаемого.
6. Непонятно почему не было более приближенных к реальным нагрузкам тестов — например смешанных нагрузок?
Без ответов на эти вопросы совсем непонятно как можно делать какие-либо выводы. Например близость показателей чтения и записи могла быть обусловлена тем, что СХД на Эльбрусе на чтении просто напросто уперлось либо в шину либо в близкую к 100% утилизацию какого-то другого ресурса.
И я еще уверен, что люди профессионально занимающиеся СХД могут задать еще больше вопросов, которые я просто по незнанию тематики упустил.
А вместо непонятного вебинара (который еще и будет через несколько недель), где требуется предоставить много персональных данных, хотелось бы все же видеть вовлечение в ответы на вопросы в комментариях.
Информацию о ПО в по обоим СХД и клиентам в саму статью. Сейчас что-то про ядро есть только для СХД на Эльбрусе. Про sysctl'и нет вообще нигде и ничего.
ПО на обоих системах одинаковое A-CORE актуальной версии. Оно идентично на системах Engine и Восток
Подробная разбивка по загрузке CPU. Например, сейчас абсолютно непонятно что там по ядрам, так как есть только некая общая мера, я б даже сказал средняя. В идеале должно быть два графика — CPU по ядрам от времени и задержек от времени.
Можно сделать, идея хорошая, спасибо. На теста ядра 5.4 выложим побольше графиков.
Непонятно какие значения подразумеваются под пропускной способностью и задержкой — минимум, максимум, среднее, какой-то конкретный перцентиль?
Среднее за час
Хотелось бы увидеть обоснование выбора конкретного железа (ну кроме «другого не было»). Потому что E5-2603v4 все же один из младших CPU в линейке с ценой в 213$ и совсем непонятно зачем он был выбран.
Это стандартный процессор в системе Engine N2 для недорогой гибридной конфигурации (для более мощных, например all-flash конфигураций используются значительно более мощные процессоры).
Хотелось бы увидеть анализ почему такой latency в ситуациях когда он выше ожидаемого.
Не очень понятен вопрос, поясните какого рода анализ вы ждете.
Непонятно почему не было более приближенных к реальным нагрузкам тестов — например смешанных нагрузок?
Вам прям всё и сразу хочется, так не бывает :-). Сейчас сделали первое приближение. Это не последняя публикация про производительность наших СХД на Эльбрусах. Будут ещё минимум две. Не всё сразу :-)
ПО на обоих системах одинаковое A-CORE актуальной версии. Оно идентично на системах Engine и Восток
Из статьи в текущей момент абсолютно не ясно какое ядро и настройки, как минимум. Это может быть важно, как минимум для воспроизведения ситуации. Потому что мне, как читателю — абсолютно непонятно что такое «A-Core» и что это означает.
Среднее за час
Довольно плохая метрика, потому что несколько экстримально низких или экстримально высоких значений могут испортить картину. Советую подумать о перцентилях.
Это стандартный процессор в системе Engine N2 для недорогой гибридной конфигурации (для более мощных, например all-flash конфигураций используются значительно более мощные процессоры).
В статье это не указано, а также это не отвечает почему именно этот процессор выбран для железки. Иначе создается впечатление небольшого читерства когда берется система с процессором за условную 1000$ и ей противопоставляется относительно устаревшая система с процессором ценой в 300$ (на момент выхода).
Не очень понятен вопрос, поясните какого рода анализ вы ждете
Смотрите, сейчас Вы получили какие-то значения и сделали выводы. Проблема выводов в том, что полностью отсутствует все рассуждение между «мы получили 91к write iops и 100k read iops» и «Эльбрусы больше предпочитают запись». Просто выводы довольно спорные и не очевидные и без анализа причин таких чисел (архитектурного анализа, типа ткнуть в документацию и сказать «вот эта штука объясняет», либо настроек системы, версии ядра или еще чего-то подобного) такие выводы кажутся абсолютно неочевидными, более того, такая картина как описана в статье именно в плане разницы read vs write производительности больше похожа на то, что вы уперлись при чтении в какое-то узкое место (чтоб понять в какое — как раз и нужны графики загрузки цпу по типу и ядрам, анализ банального количества прерываний, теоретические расчеты задержек и пропускной способности по шинам и т.п.).
Также и про latency в 0.3мс для Эльбруса — интересно бы увидеть объяснение отличий, с анализом причин такой разницы (например снятые системые метрики, конфигурация теста и какое-то доказательство что вы не просто случайно протестировали кэш).
Ну и опять же, хочется больше деталей про условия тестирования, так как сейчас из всего железа известны только модели ЦПУ. Неизвестно ни какие диски использовались, ни информации про дисковый контроллер, поэтому анализ читателем — затруднителен, если вообще возможен.
Это не последняя публикация про производительность наших СХД на Эльбрусах. Будут ещё минимум две
обратите внимание на этот комментарий:
https://habr.com/ru/company/aerodisk/blog/520888/#comment_22117148
что-то у вас не сходится
RDMA в наших системах ожидается в q1 2021. На тему future-proof и FC. Если отбросить маркетинг, на тему что "FC умер, т.к. есть RDMA и 100GbE за недорого", а посмотреть на реальные задачи реальных заказчиков, то пока все идет к тому, что FC ещё будет жить очень долго.
Какой ещё маркетинг? Мы можем открыть прайс mellannox и увидеть 25gbps коммутаторы за 600 с копейками тысяч.и говоря про реальные задачи: давайте посчитаем, что будет дешевле:1) оборудовать и поддерживать чисто Ethernet сеть 2) оборудовать и поддерживать fc и Ethernet сети. Надо помнить, что Ethernet во втором сценарии используется не только для схд, а вот FC уже большого толку на мой взгляд не имеет
Пессимисты говорят, что производительность Эльбруса сейчас «никакая», и чтобы догнать «топовых» производителей потребуются десятилетияну учитывая что в ваших же тестах эльбрус уступает xeon'у 8-летней давности, получается задержка как раз порядка 10 лет
т.е. в условиях нынешней реальности — никогда
А толку-то, если Эльбрус 8С отстаёт на 1-2 поколения. Для сравнения надо было брать ещё более старый XEON c DDR3, PCIe 2.0 и т.д. Там бы и цифры сопоставимые получлись бы.
а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем «догнать и перегнать» ведущих мировых производителей процессоровА производители, надо понимать, вежливо постоят и подождут.
«Здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее»
В архитектуре Эльбруса особенностей и разных "ноу-хау" довольно много, например, суперскалярность, внеочередное исполнение операций, анализ кода с помощью компилятора и т.п.
e2k крайне интересная архитектура и, на наш субъективный взгляд, потенциал её значительно превышает x86-64(amd64).
Более подробно про архитектуру e2k можно почитать в нашей статье:
https://habr.com/ru/company/aerodisk/blog/482434/
В ней же (внизу) есть ссылки на источники, где больше деталей.
Кроме того, вопросы по существу можно будет задать непосредственно представителю разработчика Эльбруса, Константину Трушкину. Ссылка на регистрацию в статье выше.
+Многое ПО сегодня шлет телеметрию в облако, сюда же можно включить данные профилировки для обучения компилятора
Это всё есть в x86 уже лет 20.
В итаниуме — да, как и другие "ноу-хау" в других архитектурах по отдельности, но не в x86.
Вот такое пытался провернуть Intel в процессорах Itanium. И где они сейчас?
В x86 внезапно, EFI QPI и наработки по компилятору все перетекли в x86 из итаниума.
Чего из процитированного списка нет в x86?
Если по чесноку то ничего, x86 это система команд (или архитектура в терминах интела), которая реализовывалась поверх самых разных микроархитектур в том числе и без внеочередного исполнения (например старые атомы). Так что у интела суперскалярность и внеочередное исполнение часть микроархитектуры конкретного семейства и появилось оно впервые не 20 лет назад а больше, в процессорах пентиум если я не ошибаюсь да и чуть ли не позже чем оно появилось у всех остальных.
А вот как раз спекулятивность/суперскалярность на уровне системы команд (как в эльбрусе) появилась в итаниуме 20лет назад. Поэтому даты верные, сравнения не верные.
Взяли пару удачных вещей
Взяли просто x86 от которого они уже поняли что не избавятся и посадили на итаниумовскую шину и все остальное так появилось поколение i7-i5, а сам итаниум и легаси x86 платформу закопали. AMD кстати свой HyperTransport купила у трансметы (надеюсь не надо говорить кто это), да и технологии всякие типа nxBit тоже оттуда понатасканы, так что вклад внесен немалый.
А вот как раз спекулятивность/суперскалярность на уровне системы команд (как в эльбрусе) появилась в итаниуме 20лет назад.
так на уровне команд это сомнительное благо, динамическая суперскалярность явно более продвинутая вещь. тот же SMT целиком и полностью существует за счёт этой самой суперскалярности.
VLIW, конечно имеет свои плюсы, в первую очередь он гораздо проще, за счёт этого тем же числом транзисторов в числодробилках можно большей производительности достичь, но числодробилки — это далеко не все задачи.
тот же SMT целиком и полностью существует за счёт этой самой суперскалярности.
Это вопрос каверзный, из за того что ОоО-суперскаляр не может загрузить свои исполнительные блоки ему придумывают SMT, чтоб хоть забить его разными потоками. Влив в такой парадигме существовать не обязан если тебе надо много потоков — делай влив с небольшим числом устройств и пусть их будет много, а то и вообще оставь одно большое и окружи его кучей мелких как будто у тебя IBM cell
VLIW, конечно имеет свои плюсы, в первую очередь он гораздо проще, за счёт этого тем же числом транзисторов в числодробилках можно большей производительности достичь, но числодробилки — это далеко не все задачи.
Ну вот статически откомпилированные программы только в числодробилках хорошо работают? Нет, но какие то вещи на них делать сложнее чем на динамических языках, а какие то вещи (как например ООП в плюсах) так и вовсе оказалось можно вполне реализовать статически без рантайма и как то это работает вполне успешно.
Вот так же и с вливом примерно
а как у эльбруса обрабатывается обращение к памяти, вызвавшее промах кэша? ЕМНИП, тормозится исполнение всего потока команд.
процессор с SMT в таком случае может пока исполнять задания из параллельного потока.
или если компилятор не смог нагрузить всю ширину инструкции — исполнительные блоки у VLIW будут простаивать, а в случае SMT они могут быть заняты чем-то ещё.
ИМХО правильнее делать суперскалярность на основе потока мелких команд с явно прописанными зависимостями, условно говоря, как в makefile. это было бы и относительно просто в реализации, и позволило бы более полно утилизировать исполнительные блоки за счёт SMT.
а как у эльбруса обрабатывается обращение к памяти, вызвавшее промах кэша? ЕМНИП, тормозится исполнение всего потока команд.
Никак, да, боль и унижение. Хотя вообще то мог бы на другом конвеере что то исполнять в таких случаях, у него их там несколько штук для подготовки колов/переходов.
процессор с SMT в таком случае может пока исполнять задания из параллельного потока.
Если у тебя две задачи запущены на одном ядре, то одно не заблокирует другое вот и все. Но так же оно у тебя и на физических ядрах не заблокируется, а больше ничего SMT и не дает, скорее как раз отнимает интерфейс памяти у одного потока, так бы он мог несколько загрузок сделать и что то уже посчитать пока тут на регистры загружается, а так у тебя другой поток каналы чтения записи в кэш забрал и отнять их теперь нельзя.
ИМХО правильнее делать суперскалярность на основе потока мелких команд с явно прописанными зависимостями, условно говоря, как в makefile
Еще один плюс VLIW на нем наглядней видно как все работает и гораздо быстрее все усваивать. Процессоры устроены немного сложней
В итаниуме — да, как и другие «ноу-хау» в других архитектурах по отдельности, но не в x86.
Суперскалярные x86: P5 (Pentium первый), Nx586, AMD K5. То есть примерно с 1993 года.
Внеочередное исполнение операций — Pentium Pro и AMD K5 были первыми среди x86. То есть с ~1995 года.
А так уши у всего этого растут вообще из мейнфреймов 196x годов.
Или имелось в виду, что в x86 это не ноу-хау?
Не имелось в виду то что выше написал. В эльбрусах и итаниумах как такового внеочередного исполнения вообще нет они строго in-order superscalar, но там есть возможность переставить команды
с помощью компилятора и т.п.
и таким образом реализуется внеочередное исполнение. И его нельзя напрямую сравнивать с железным внеочередным исполнением, они разные и в чем-то лучше один, а в чем-то другой.
В чем железное внеочередное исполнение может быть хуже? В потреблении энергии что ли?
Ну да, оно ведь профили программ не составляет и код в оптимальном порядке никуда не сохраняет, сколько раз ему одно и то же сунешь он столько же раз его будет перепланировать расходуя ток. И здесь проявляется второй недостаток — планировщик очень ограниченный и не видит инструкции которые еще не прошли через фронтенд и не попали в буфер переупорядочивания. Последнее частично фиксится оптимальным выстраиванием потока инструкций компилятором, но система команд полноценно это делать не позволяет. Ну и как следствие устройств много не натыкаешь так как планировщик усложняется в след за их добавлением.
Команда пришла, есть где ее исполнять — отдаем, нет — сохраняем и парсим следующую.
Это обычный суперскаляр с конвеером так работает, а внеочередное исполнение вытаскивает наиболее потенциально долгие команды (например лоады или деление) и исполняет их как можно раньше не дожидаясь даже проверки условия (здравствуй spectre) или откладывая эксепшн в случае деления на ноль.
будет работать быстрее, чем VLIW-фронтенд, обрабатывающий пакет команд, следовательно команда сможет уйти на выполнение раньше и отработать быстрее.
Как он может быть быстрее, если во вливе ассемблер это практически уже микрокод который прям как написан так и исполняется, декодирование там настолько простое что команда за один такт должна оказаться на конвеере иначе код просто ломается.
внеочередное исполнение вытаскивает наиболее потенциально долгие команды (например лоады или деление) и исполняет их как можно раньшеИ это еще быстрее. А VLIW сложил два числа и ждет соседний load.
Как он может быть быстрее, если во вливе ассемблер это практически уже микрокод который прям как написан так и исполняется, декодирование там настолько простое что команда за один такт должна оказаться на конвейере иначе код просто ломается.Во-первых, я сказал «при прочих равных» — если Вы представили идеальный простой VLIW-процессор, то сравнивайте с идеальным простым обычным процессором, который тоже мгновенно все декодирует. Во-вторых, даже на современных реализациях x86, которую ругают за сложное декодирование все кому не лень, упереться во фронтенд практически невозможно.
И это еще быстрее. А VLIW сложил два числа и ждет соседний load.
Некие меры в Э предприняли:
www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf
Для решения проблемы с блокировками конвейера, вызванными операциями чтения, в архитектуре
«Эльбрус» предусмотрено несколько методов:
Ациклические участки кода:
– совмещение блокировок;
– ограничение на простановку маловероятных чтений в спекулятивный режим.
Цикловые участки кода:
– cовмещение блокировок в конвейеризированных циклах;
– выявление регулярных чтений, предподкачка с помощью prefetch (ld->empty);
– использование аппаратно-программного механизма для подкачки линейных данных
Если при выполнении программы эти меры подействовали, то данные будут к моменту использования лежать тепленькими в кэше
Так как это пособие является практическим, описание совмещения блокировок компилятором и про-
становки маловероятных чтений в спекулятивный режим будет пропущено.
И как без описания понять что это такое? Про линейные участки и префетчь хоть понятно примерно, а вот что такое "совмещение блокировок" да еще каким то программным способом — непонятно.
И это еще быстрее. А VLIW сложил два числа и ждет соседний load.
Конвейризованные архитектуры так не работают, там команда за командой запускается каждый такт и никто никого не ждет, но если у тебя следующая команда оперирует теми же регистрами на которых ты в предыдущем такте сложение или лоад запустил, то она будет ждать пока регистры не будут готовы. Арифметика имеет фиксированное число стадий исполнения поэтому легко предугадывается в коде, и до нее можно еще пихнуть команд. Ну а нечего пихнуть можно выровнять нопами.
Другое дело лоад, при котором неизвестно где данные окажутся и первая же команда которая обращается к этому регистру, заблокирует конвеер на ожидании готовности. У оут-оф-ордера есть преимущество — он может отложить все операции которые зависят от лоада. Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается. Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.
Так что преимущество не очевидно так как ОоО тоже далек от идеала.
если Вы представили идеальный простой VLIW-процессор, то сравнивайте с идеальным простым обычным процессором
Я представил существующий в железе и работающий эльбрус, и можно его же представить в виде обычного риск процессора, просто выписав все инструкции из широких команд в линеечку — декодер будет такой же, просто во вливе он широкий параллельный а в риске маленький на одну инструкцию.
Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается.Да там ведь кэши куда ни глянь, разве нет?
Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.Нет, не получится, потому что VLIW не предлагает ничего принципиально более гибкого по сравнению с OoO. Если дефолтному OoO приходится ждать — значит есть некая затратная операция, от которой зависит дальнейшее выполнение, которую VLIW придется точно так же ждать. Только он в это время ничего не сможет делать (на Эльбрусе в случае чтении из памяти вроде как сможет, судя по информации от yalex1442, но это уже по сути небольшой отход от VLIW-парадигмы). А еще ведь есть спекулятивное выполнение и подобные оптимизации, которые во VLIW просто неприменимы.
Я представил существующий в железе и работающий эльбрусНу если его сравнить с существующим в железе и работающим x86, то сами знаете что получается.
P. S. Ну и VLIW в 2020 уж никак на ноу-хау не тянет, разве что на хорошо забытое старое…
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 мс — неизвестно, взяты с неба.
Собственно, в binutils есть objdump и когда они таки перестанут нарушать GPL — вся их Секретная Документация По Опкодам (тоже бред тот ещё, процессор с закрытой системой команд) в тот же момент перестанет быть секретной. В общем такая себе политика — как линуксы открытые запускать, так в первых рядах, а как GPL соблюсти…
Ну и железо само в конце концов тоже не сказать чтобы просто взять, да :)) ещё и с дисками.
не соглашусь. статью написала компания-разработчик СХД, в том числе и СХД на Эльбрусах, именно про производительность СХД и ожидаешь увидеть в этой статье.
другое дело, что можно было бы сравнить влияние компрессии, дедупликации, разных уровней RAID на производительность СХД на базе Xeon/Эльбрус, это было бы интереснее.
вообще статья больше расчитана на некомпетентных читателей ИМХО: «смотрите, у нас есть какие-то цифирки, Эльбрус где-то немного хуже, где-то много лучше, можно брать».
Статья рассчитана на тех, кому это интересно.
Задача данного теста — "голая" производительность на флэше.
Очевидно, что дедуп и компрессия будут влиять, но это совсем другой тест и мы его тоже сделаем, но уже на ядре 5.4.
Повторим этот + добавим тесты с фичами (дедуп, компрессия, гибридные конфигурации и т.п.)
Intel 6*1,7=10,2
При прочих равных производительность примерно одинаковая, хотя интел на 6% мощнее.
В целом цифры выглядят реалистично за исключением разницы на порядок, явно какая-то не отключенная буферизация.
А как повторить, чтобы при одинаковых размерах блока и характерах трафика, получить на порядок отличающиеся задержки, а скорость передачи примерно одинаковую? Я кроме как "ставить на порядок большую паузу между запросами (!) с нагрузочной машины" не придумал ничего.
Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine