LINUX.ORG.RU

Сбербанк провёл испытания процессоров «Эльбрус»

 , , , ,

Сбербанк провёл испытания процессоров «Эльбрус»

0

3

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

Представитель лаборатории новых технологических решений Сбербанка Антон Жбанков дал следующие комментарии: «Технические выводы достаточно простые: очень слабо для сравнения с Intel Xeon — мало памяти, медленная память, мало ядер, мало частоты. Функциональные требования катастрофически не выполнены».

Сбербанк проводил изучение серверов по различным методикам. Приведенные критические оценки в первую очередь относятся к итогам функционального тестирования по методике Sberinfra на соответствие корпоративным эксплуатационным требованиям банка.

В результате тестирования, как отметил Жбанков, «чуда не произошло» — серверы показали соответствие 7 из 44 параметров («наличие лапки кабель-менеджмента, наличие рельсов, наличие индикации каждого элемента, наличие удаленного управления» и пр.) — 16%.

Изделия на российских чипах уступили зарубежному конкуренту по всем параметрам, однако полученные результаты сотрудников Сбербанка все же «неожиданно и очень приятно» удивили. «Мы ожидали, что разница будет не в разы, а в 20-30 раз, — отмечает Жбанков. — Для нас это реально удивительно». Вторым фактором удивления для тестировщиков стал вывод о том, что перед ними оказался законченный продукт.

Фрагмент с выступлением руководителя лаборатории новых технологических решений «Сбера» Антона Жбанкова на партнерской конференции АО «МЦСТ» по поводу проведения этого тестирования доступен по данной ссылке (таймкод уже применён: 2:14:44).

Из комментариев МЦСТ: «Для цели тестирования Сбербанком было разработано и передано макетное приложение. Для этого макетного приложения за счет доработки Java-машины и подбора опций улучшили среднее время отклика на процессоре “Эльбрус-8С” с исходных 24 мс до 4 мс (в шесть раз), при этом на X86 (Соге i7-9700 CPU 3 GHz) оно получилось 3 мс».

8-ядерный российский процессор «Эльбрус-8С» на архитектуре E2K выпускает АО «МЦСТ». У данного производителя есть и другие более современные процессоры — «Эльбрус-8СВ» и «Эльбрус-16С», который еще не вышел на рынок. В планах компании выпустить «Эльбрус-32С». Планируется, что «Эльбрус-32С» будет создан по технологии 7 нм, а первые рабочие образцы российского 32-ядерного процессора появятся в 2025 году.

>>> Подробное описание новости на cnews.ru

★★★

Проверено: Harald ()
Последнее исправление: a1batross (всего исправлений: 9)

Ответ на: комментарий от anc

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

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

В какой именно?

В ЭТОЙ

Ворую там, где есть деньги.

В Сингапуре есть деньги, а вот с воровством прям беда.

anc ★★★★★
()
Ответ на: комментарий от LightDiver

Это ты будешь определять кто мошенник, а кто нет?

Да.

Факт мошенничества определяют специально назначенные человеки

Специально назначенные мошенниками.

anonymous
()
Ответ на: комментарий от anc

Это тот самый Сингапур, который поднялся на транзите наркоты, потом жесткой диктатуре и фактической монархии? Великолепный пример. Давай не сравнивать моногорода со странами. И я более чем уверен, что с воровством там все в порядке. Где монархия, там правящая семья обирает остальных будь здоров.

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 2)
Ответ на: комментарий от anc

Мне надо там быть, чтобы знать, что правящая партия занимает 98%? Что самый жесткий диктатор последнего времени передал власть своему сыну? Это смешно.

Это не страна, это моногород. По сути корпорация единая под жестким управлением. А воруют там больше, где больше денег. До настоящих стран естественно сингапуру далеко в этом.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Скажите вам шашечки или ехать? Так вот ехать там очень-очень комфортно. Но вы продолжайте читать «советские газеты» и верить что там негров линчуют.
Кстати о притеснениях народа. Вы забыли упомянуть, что местным запрещено посещать казино! Караул, там притесняют! Свободу слова Анжеле Девис! Правда не только местным, китайцам и вот тут могу ошибаться, малазийцам тоже.

Это не страна, это моногород. По сути корпорация единая под жестким управлением. А воруют там больше, где больше денег. До настоящих стран естественно сингапуру далеко в этом.

Что такое «настоящая страна»?

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

А ты правда думаешь, что в России нет пяти миллионов человек, которые живут лучше, чем население Сингапура?

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

А ты правда думаешь, что в россии нет пяти миллионов человек, которые живут лучше, чем население Сингапура?

И ещё 141млн который живет хуже.

Чтобы избавиться от воровства, нужно избавляться от необходимости в нем и возможности потратить наворованное.

Вот! Сами же и ответили. Но в Сингапе добавили ещё маленький нюанс. Бремя доказательства возлагается не на обвинение, а на обвиняемого. Т.е. это не обвинение должно доказывать, что ты своровал, а ты должен доказать что не своровал.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Доказывать свои доходы нужно много где например в США. Но с воровством в США лучше всех. Там распиливают так, как не снилось никому. Сократи Россию до одного города, поставь на пути транзита крупного потока наркоты и получишь тот же Сингапур. Все в мире закономерно.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Чтобы подавать иск, например, не нужны полномочия, ну. Мошенником не становятся после суда, а являются до.

anonymous
()
Ответ на: комментарий от Aber

как Сбербанк должен был переписать софт под эльбрусы?

Пусть наймут бабушек, которые перепишут софт на КОБОЛе. КОБОЛ, кстати, ГОСТовский язык, а java, насколько я знаю, нет. А заиметь оптимизирующий компилятор КОБОЛа - это уже забота разработчиков платформы.

anonymous
()
Ответ на: комментарий от LightDiver

Доказывать свои доходы нужно много где например в США.

А если не докажешь на электрическом стуле дадут посидеть?

anc ★★★★★
()
Ответ на: комментарий от anc

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

LightDiver ★★★★★
()
Ответ на: комментарий от anc

За коррупцию нет, там коррупция узаконена. Но есть и наказания за всякое. Ты же понимаешь, что то что можно одному, нельзя другому?

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

За коррупцию нет

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

anc ★★★★★
()
Ответ на: комментарий от anonymous

Не знает.

Знает. Если для x86 может быть mov eax, [ebx]; call eax и весь кэш надо сбрасывать, то в Эльбрусе будет movtd %dr0, %ctpr1; 9 тактов всякого кода; ct %ctpr1. И за эти 9 тактов менеджер памяти успевает получить адрес перехода и загрузить в кэш все необходимые инструкции.

Скорости никогда не «хватает».

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

monk ★★★★★
()
Ответ на: комментарий от monk

Теперь понял про что. Да, с алиасингом по-другому никак.

Не только. У небольшого базового блока очень большие шансы быть объединённым с другими.

Когда в e2k начинается работа с памятью, то всё становится намного веселее. Часть/части базовых блоков начинают мигрировать выше нагружая процессор бесполезной работой, если исполнение не лежит через эту ветку. Но с другой стороны это повышает загруженность ШК и избавляет от и без того медленных ветвлений в e2k.

В e2k всегда будет обращаться в память, даже если эту ветку не надо исполнять. Кеш-промахи будут в любом случае. :)

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

  • e2k https://ce.mentality.rip/z/5Gq8qn
    • Ожидания памяти не будет в худшем случае, но будет вариативная задержка (если не ошибаюсь, 4-7 такта до 16C и 4-5 для 16C) из-за невыставленных nop для fmuld.
  • amd64 https://godbolt.org/z/3v64c3re1
    • Не взятые ветвления обычно дешевле.

Хотя ты заметишь, что можно было бы спланировать и лучше, но lcc частенько так «косячит», так что привыкай. Только не надо вновь загонять про «вот напишут нормальный компилятор и заживём». Это не такая простая задача как может показаться на первый взгляд.

Вообще-то подготовленный переход позволяет из одной точки перейти на разные метки. А ibranch технически должен быть равен некоему disp на скрытый регистр при начале выполнения + ct (то есть задержка в 3 такта гарантированно прошла).

disp => ct == 5 тактов.

И если бы он был больше одного такта, то в конце был бы не ibranch .L45, а ct %ctpr1 (если даже считать, что rbranch содержит магию и на ct не заменяется).

Нет всё верно, это тот самый «unhappy path». Зачем зря греть воздух и подготавливать переход? Тем более, что количество доп. конвейеров очень ограничено. В реальных программах компилятор так не делает, т.к. они обычно заняты.

numas13
()
Последнее исправление: numas13 (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

Не будут. В 1С есть система стандартов и методик разработки. Сам себе можешь любой говнокод писать, но если у тебя внутри цикла вызов метода нетипизированного объекта, статус 1С:Совместимо такой код не получит.

monk ★★★★★
()
Ответ на: комментарий от numas13

disp => ct == 5 тактов.

Да. Ошибся.

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

Ну может быть. Для меня всё равно этот спор чисто теоретический. Там, где я собираюсь использовать Эльбрусы (безопасное хранение данных, корпоративная сообщалка) мне и производительности Pentium II бы хватило.

monk ★★★★★
()
Ответ на: комментарий от numas13

В e2k всегда будет обращаться в память, даже если эту ветку не надо исполнять. Кеш-промахи будут в любом случае. :)

При аппаратном спекулятивном выполнении тоже. Причём при аппаратном ещё и уязвимости типа Spectre в комплекте.

Хотя ты заметишь, что можно было бы спланировать и лучше, но lcc частенько так «косячит», так что привыкай. Только не надо вновь загонять про «вот напишут нормальный компилятор и заживём». Это не такая простая задача как может показаться на первый взгляд.

Всё так. Но, тем не менее, будет чем дальше, тем лучше.

monk ★★★★★
()
Ответ на: комментарий от monk

В e2k всегда будет обращаться в память, даже если эту ветку не надо исполнять. Кеш-промахи будут в любом случае. :)

При аппаратном спекулятивном выполнении тоже.

Если предсказатель ошибся, а в e2k ВСЕГДА если так решит компилятор. Разница в том, что OoOE процессор не ждёт пока код исполнится, декодировал за 1-2 такта в этом конкретном случае и пошёл обратно в вызывающую процедуру. В Эльбрусах вынужден ждать (если очень везучий то до +100 тактов или больше) и ничего не делать. И не забывай про разницу в тактовой частоте, 130 тактов условного Эльбруса это больше раза в 2 чем в условном x86 на 4 ГГц.

Причём при аппаратном ещё и уязвимости типа Spectre в комплекте.

Отдельная тема разговора или это уже пошёл фол последней надежды? :)

Всё так. Но, тем не менее, будет чем дальше, тем лучше.

Кто о чём, а вшивый о бане. :)

numas13
()
Ответ на: комментарий от monk

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

Менеджер памяти ничего не знает. В кеш загружается память по всем возможным переходам и бранчам if/else if/else, и эти инструкции выполняются параллельно. Большая часть этой памяти в кеше – ненужная, она не будет использоваться никогда.

Тратится время на долгие операции (загрузка памяти) для того, чтобы быстрые операции (арифметика) могли выполняться в параллель. Загрузка памяти тоже может выполняться в параллель, но проблема в том, что когда память в уже кеше, то эта загрузка не нужна. Обидно ждать загрузку памяти для одного из бранчей if/else if/else, которые не исполнится никогда.

ttnl ★★★★★
()
Ответ на: комментарий от numas13

Если предсказатель ошибся, а в e2k ВСЕГДА если так решит компилятор.

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

И не забывай про разницу в тактовой частоте, 130 тактов условного Эльбруса это больше раза в 2 чем в условном x86 на 4 ГГц.

Так память примерно на равной скорости и чтение из памяти съест в два раза больше тактов условного x86.

Отдельная тема разговора или это уже пошёл фол последней надежды? :)

Скорее второе. Хотя для меня как раз основной аргумент: количество возможных уязвимостей в Эльбрусе меньше.

Кто о чём, а вшивый о бане. :)

Ну да. :-) Ещё я Haskell люблю, в котором тоже всё было бы хорошо, если бы был идеальный компилятор.

monk ★★★★★
()
Ответ на: комментарий от monk

Вроде в OOO всегда все ветки читаются.

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

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

Если они расположены последовательно в памяти. Но если адреса случайные, то L1d будет засоряться ненужным в данный момент мусором и вытеснять потенциально нужные данные.

Так память примерно на равной скорости и чтение из памяти съест в два раза больше тактов условного x86.

В том то и дело. Что в этом примере пока Эльбрус будет ~130-150 (если не повезёт) тактов ждать данных для ненужной ветки, условный OoOE 300 тактов будет выполнять программу. Поэтому важно, чтобы компилятор не вставлял инструкции использующие результат чтения из памяти до ветвления. Хотя от вытеснения полезных данных это не спасёт, но по крайней мере CPU не встанет колом. Но что если необходимо загрузить из памяти указатель (u8 **)?

Скорее второе. Хотя для меня как раз основной аргумент: количество возможных уязвимостей в Эльбрусе меньше.

Неуловимый Джо. :)

Но если без шуток, то в Эльбрусе есть хорошие вещи. Например отдельный стек для адресов возвратов, но защищённый режим мне не нравится. К нему много вопросов.

numas13
()
Ответ на: комментарий от numas13

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

Если бы данные не подтягивались в кэш, то случайные данные обрушивали бы скорость не в полтора раза, а в 100.

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

Можно даже не случайные. Достаточно массив с длинными строками по столбцам обойти.

Что в этом примере пока Эльбрус будет ~130-150 (если не повезёт) тактов ждать данных для ненужной ветки, условный OoOE 300 тактов будет выполнять программу.

Почему? В L2 Эльбрус также тянет всё, что можно. А из L2 в L1 подымается при подготовке перехода (хотя может я и не прав).

Но что если необходимо загрузить из памяти указатель (u8 **)?

Здесь при любой архитектуре будет чтение из памяти. Чудес не бывает.

Неуловимый Джо. :)

И это тоже. По этому критерию ARM/Linux лучше, чем x86/Windows, а El2k/Linux ещё лучше.

Например отдельный стек для адресов возвратов

Я его и имел в виду. Адрес возврата запороть невозможно.

monk ★★★★★
()
Ответ на: комментарий от monk

Тебя начинает нести в какую-то другую сторону. Напоминаю:

@numas13 https://ce.mentality.rip/z/9Ks6Kv

@numas13 В e2k всегда будет обращаться в память, даже если эту ветку не надо исполнять. Кеш-промахи будут в любом случае. :)

@monk При аппаратном спекулятивном выполнении тоже.

@numas13 Если предсказатель ошибся, а в e2k ВСЕГДА если так решит компилятор.

@monk Разве? Вроде в OOO всегда все ветки читаются.

double f(int c, double x, double y, double *z, double w, double u) {
    if (c) {
        x = x * y;
    } else {
        x = x / *z;                   <<<< чтение памяти
    }
    return x * w;
}

f(int, double, double, double*, double, double):
{
  setwd wsz = 0x4, nfx = 0x1, dbl = 0x0
  return        %ctpr3
  ldd,0,sm      %dr3, 0x0, %dg16      <<<< чтение памяти
  fmuld,1,sm    %dr1, %dr2, %dg17
}
{
  nop 3
  cmpesb,0      %r0, 0x0, %pred0
}
{
  fdivd,5,sm    %dr1, %dg16, %dg16    <<<< использование до ветвления, ожидание в любом случае если данные не в L1d
}
{
  ct    %ctpr3 ? ~%pred0
  fmuld,3       %dg17, %dr4, %dr0 ? ~%pred0
}
{
  nop 7
}
{
  nop 3
}
{
  ct    %ctpr3 ? %pred0
  fmuld,3       %dg16, %dr4, %dr0 ? %pred0
}

Здесь при любой архитектуре будет чтение из памяти. Чудес не бывает.

В OoOE пока данные будут считываться будет происходить исполнение другого кода, а в in-order VLIW будет ожидание данных. Ты не видишь разницу? Максимум что VLIW сможет выполнить, это инструкции между первым и вторым чтением (3-5 тактов в зависимости от поколения Эльбруса). В OoOE на сколько хватит RoB и других внутренних структур.

Давай закончим этот бесполезный спор.

numas13
()
Ответ на: комментарий от numas13

использование до ветвления, ожидание в любом случае если данные не в L1d

Понял. Да, был неправ.

monk ★★★★★
()
Ответ на: комментарий от Odalist

Более чем нужны. Они были со времён Месопотамии, и даже СССР не смог от них избавиться (при госмонополизации всего и вся). На данный момент нет вариантов функционирования без них.

NeTC ★★★
() автор топика
Ответ на: комментарий от LightDiver

Например у нас кроме сбера нет никого.

В 21-ом-то году? Где-то в России отменили интернет?

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

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

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 2)
Ответ на: комментарий от grem

Я себя не мучаю: карту мне предоставил работодатель, я не плачу за обслуживание и вообще не занимался вопросом оформления.

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

Предварительно кажется, что по всем вопросам, включая ипотеку, есть лучшие решения. Например, сын брал в начале 21-го в Открытии, и, по-моему, под меньший процент. Да, я понимаю, что ставка рефинансирования с тех пор выросла в 2 раза. В общем, если есть желание, можно продолжить в толксах. Если нет, хочу пожелать удачи и терпения в общении со Сбером.

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

лучшие решения. Например, сын брал в начале 21-го в Открытии

На новостройку можно меньше найти разумеется; на вторичку, где уже кто-то жил, возможно, но менее вероятно. Так как доп. снижение ставки во всех банках идёт «зарплатникам»,а низкие ставки на новостройку по «госпрограмме» молодым семьям. К тому же продавец квартиры может не захотеть другой банк (да, может захотеть и любой другой), просто потому, что ему лень переть куда-то, для заключения сделок, а тут все операции со счетами менеджер проведёт - ему так спокойнее.

О каком терпении идёт речь? Я с ним не общаюсь.

grem ★★★★★
()
Ответ на: комментарий от numas13

В OoOE пока данные будут считываться будет происходить исполнение другого кода, а в in-order VLIW будет ожидание данных.

Ты только что говорил про бесполезную работу которую делает эльбрус и постоянную нагрузку на память, и тут же выдаешь это за достоинство в суперскаляре. В in-order VLIW эта нагрузка на память управляемая, в суперскаляре нет - вот и вся разница.

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

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

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

Я написал, что это будет только в случае ошибки предсказателя.

В in-order VLIW эта нагрузка на память управляемая, в суперскаляре нет - вот и вся разница.

Давай рассмотрим простейший случай.

Будь другом, можешь посчитать сколько там ненужной работы? Cколько может занять время исполнения такого кода тоже было бы полезно?

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

Мне кажется, или кто-то путается в своих показаниях? :)

В in-order VLIW эта нагрузка на память управляемая, в суперскаляре нет - вот и вся разница.

numas13
()
Ответ на: комментарий от numas13

Будь другом, можешь посчитать сколько там ненужной работы? Cколько может занять время исполнения такого кода тоже было бы полезно?

Лишней работой там занимаются только конвееры которые заполняются бранчами на которых никогда не будет перехода и ты это видишь воочию и делаешь выводы. В амд64 ты видишь только ассемблерный фронтенд который перемалывается в такую же примерно хрень из микропов и ты уже никак на нее не можешь повлиять.

Мне кажется, или кто-то путается в своих показаниях? :)

Ну так это не спекулятивность процессора отключается, а специальные костыльные патчи в ядре мешают процессору прогружать функции, по сути мешают работать - это то к чему надо стремиться ты считаешь?

uin ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.