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)

А тем временем Apple успел запилить M1…

Для справки - M1 арм со своей микроархитектурой, выступил на уровне современных x86, и кристалл не с ладонь размером.

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

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

напомни, сколько правительство сша инвестировало в винду или x86 процы?

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

проще говоря для не-числодробилок эльбрус не готов и готов не будет в принципе

cvs-255 ★★★★★
()
Ответ на: комментарий от petyanamlt

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

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

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

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

Как раз надо. Мировая практика показывает, что все производители процов этим занимаются.

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

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

Я понять не могу почему не изобретают нового. Зачем насилуют изобретенное десятилетия назад.

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

Чо ? Я что то упустил ?

В конструкциях типа:

switch(a)
{
  ...
}
...
b = f(x); // f - чистая

Эльбрус вычислит b до окончания выполнения switch (вместо операций ожидания). Аппаратное спекулятивное вычисление так сможет только в том случае, если расстояние от начала switch’а до вычисления b не более 31 инструкции и если не сбросит конвейер на условном переходе.

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

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

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

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

f - чистая

В этом случае важен компилятор, а не архитектура.

Аппаратное спекулятивное вычисление так сможет только в том случае, если расстояние от начала switch’а до вычисления b не более 31 инструкции и если не сбросит конвейер на условном переходе.

Можно более развёрнуто?

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

У конкурентов код работает все быстрее с новым поколением процессоров

На Core i7 код, оптимизированный для SSE2 тормозит существенно (на фоне того же кода перекомпилированного).

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

Пока новые поколения отличаются количеством ядер и кэшем. Полная бинарная совместимость.

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

В этом случае важен компилятор, а не архитектура.

Для аппаратного конвейера не поможет. Если компилятор передвинет в начало, то f вычислится до switch’а и switch начнёт выполняться позже. Запихнуть в пустые такты во время switch’а никак.

Можно более развёрнуто?

Аппаратное спекулятивное вычисление:

Читаем вперед некоторое количество инструкций (для Intel от 18 до 31), если натыкаемся на инструкцию, которая требует несколько тактов, в ожидание вставляем инструкцию из очереди. Если натыкаемся на ветвление, спекулятивно вычисляем наиболее вероятную ветку.

Компиляторное спекулятивное вычисление:

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

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

Пока новые поколения отличаются количеством ядер и кэшем. Полная бинарная совместимость.

v1 => v2 нет обратной совместимости. Удалили некоторые инструкции.

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

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

У Эльбруса вроде нет никаких предсказаний ветвлений итд.

У Эльбруса компилятор явно указывает, что вставлять в пустые такты. И операция ветвления состоит из двух команд: disp (если переход по метке) или movtd (если по значению), а затем через 5-9 тактов команда ct (выполнение подготовленного перехода, можно дополнительно проверить условие). И чем занять эти 5-9 тактов компилятор пишет сам. Или может начать готовить переход за 9 тактов до инструкции if или вызова виртуального метода.

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

У тебя неверные представления о работе OoOE и спекулятивного исполнения.

Так напиши правильное.

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

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

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

v1 => v2 нет обратной совместимости. Удалили некоторые инструкции.

Какие? На http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_prog_2020-05-30.pdf указан один набор команд на все процессоры линейки. Также как и единые задержки (стр. 57).

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

Разумеется. У Эльбруса явное спекулятивное выполнение: что именно выполнять должен указать компилятор или программист.

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

Так напиши правильное.

Давай начнём с того, что:

не более 31 инструкции

Это даже меньше чем у Pentium II (40 µop ROB, 20 µop RS/Queue), при условии что все инструкции декодированы в 1 µop.

Остальное даже не хочу комментировать.

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

ты путаешь микрокоманды и команды процессора, у Эльбрусов нет микрокоманды.

Речь идёт про Intel.

@monk Читаем вперед некоторое количество инструкций (для Intel от 18 до 31)

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

которые неизвестно куда будут отправлять наши данные вместо наших, проверенных ФСБ и ГНИ.

пачинилниблагадари

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

Ничего не забыл?

Нет платного туалета.

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

Это даже меньше чем у Pentium II (40 µop ROB, 20 µop RS/Queue), при условии что все инструкции декодированы в 1 µop.

Так Эльбрус разве с Pentium II сравнивают?

Для Nehalem заявлено 18 Entry Instruction Queue. Для Prescott - был конвейер на 31 стадию. Я не туда смотрю?

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

20 µop RS/Queue

Так это же и есть очередь инструкций. Нет?

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

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

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

Для Nehalem заявлено 18 Entry Instruction Queue.

Это буфер куда идёт декодирование, чтобы дальнейшие стадии не голодали.

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

У P-core в Alder Lake он равен 512 «записей».

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

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

Хорошо. Согласен. В числах примерно на порядок ошибся.

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

P.S. Пока компилятор Эльбруса даёт не очень оптимальный код. Например цикл в https://habr.com/ru/post/576420/ вполне можно уменьшить с 13 тактов до 8 (убрать 2 такта ожидания из начала цикла, сделать подготовку disp %ctpr1, .L619 единоразово перед циклом в ctpr2 и убрать задержку в 3 такта).

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

если новые данные имеют сходное распределение, то может работать быстрее

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

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

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

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

P.S. Пока компилятор Эльбруса даёт не очень оптимальный код. Например цикл в https://habr.com/ru/post/576420/ вполне можно уменьшить с 13 тактов до 8 (убрать 2 такта ожидания из начала цикла, сделать подготовку disp %ctpr1, .L619 единоразово перед циклом в ctpr2 и убрать задержку в 3 такта).

Нет. Регистры подготовленных переходов не переживают вызовы процедур. Вот такое соглашение о вызовах процедур когда-то приняли в МЦСТ.

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

Нет. Регистры подготовленных переходов не переживают вызовы процедур. Вот такое соглашение о вызовах процедур когда-то приняли в МЦСТ.

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

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

Одно непонятно: зачем вы так себя мучаете? В России достаточно банков, они с удовольствием выдают карты, кредиты и прочую банковскую чешую.

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

Россия весьма большая и кое где сбер монополист. Например у нас кроме сбера нет никого. А еще многие годы не было никого кроме билайна.

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

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

Мне как-то неслыханно повезло и я в Москве забрёл в отделение, которое является подмосковным о_О. Я хотел через кассира денег на карту закинуть, но так как карта выдана московским офисом, то положить могут, но возьмут комиссию. Предложили закинуть через банкомат - там без комиссии.

Уже давно не так.

Но самое забавное было у коллеги: у него было 2 карты, одну получил в Москве, вторую в подмосковье и как только он одну привязывал к номеру телефона, то вторая отвязывалась и наоборот.

У меня показывает 3+2 карты. При этом телефон для 2 разных людей. Также относительно давно.

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

Уже (давно) лучше.

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

LightDiver

Анус себе заблокируй слабовая обслуга от РКН.

Россия весьма большая и кое где сбер монополист. Например у нас кроме сбера нет никого.

Как узнать что слабовая обслуга врёт? Она создаёт сообщение - враньё.

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

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

Не буду повторяться про наглую ложь.

Приходишь и оформляешь корректный перевод/платёж на счёт лица занимающимся ЖКХ с соответствующей пометкой (можешь не быть «оформленным» клиентом банка), только данные укажи правильно, лол. И такое давно применяется.

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

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

Кредиты: что-то я на тот момент на нашёл другого банка выдающего ипотеку под 7.6% на длительный срок без подтверждения дохода и всяких справок; Найди мне выгоднее условия.

продавец квартиры может захотеть провести сделку через определённый банк.

Прочая банковская чешуя мне вообще неинтересна.

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

Да чего далеко ходить. От меня три обращения в прокуратуру только за 2021 год было на сбер, после двух из которых все резко исправили в срок от 3 часов до 3 дней, после чего мне позволнили из роспотребнадзора, спросили - исправлено ли и попросили забрать заявления. Третье все еще в работе.

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

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

У них с переводами по СБП заморочки, её они ещё и долго не вводили, но так как мне переводы обычно не нужны, то я не парюсь.

То есть мне просто нет смысла менять шило на мыло.

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

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

Да. Я именно про это. С процедурами в цикле компилятор как раз лучше справляется - просто делает подстановку (inline). Блок оптимизации ведь стандартный. А вот с правильной явной спекуляцией пока всё в начале пути, так как все алгоритмы пишутся с нуля.

То есть можно надеяться на ещё несколько десятков процентов прироста скорости за счёт компилятора.

Отсюда и рекомендации собирать ПО для Эльбруса с PGO. Но это не панацея в его случае, динамика никуда не девается.

В часто встречающихся задачах динамика вредна, так как чаще важен худший случай, а не лучший. Например, каким редактором удобнее пользоваться: у которого время реакции на команду 0,4-0,6 секунды или время реакции 0,1-3 секунды? Даже если 3 секунды попадает всего в 10% случаев второй редактор будет восприниматься как тормозящий. При управлении оборудованием всё ещё жёстче: если алгоритм не успел завершиться в заданное время, может быть авария.

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

У меня в глухом селе вообще альтернатив нету. Мне и менять то не на что. Нужно работать с тем, что есть.

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

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

Что-то он гонит. Была же новость про 2 (два) сервера на SPARC, которые вдвоем занимались всеми переводами сбербанка еще 10 лет назад.

Кто дал этим неучам неспособным адаптировать программное обеспечение право рот открывать? Это только программисты после оптимизации и адаптации кода могли бы дать на тюнинг пробу админу самому лучшему чтобы он покрутив параметры раз так в 70 увеличил бы скорость работы базы данных. А потом уже дали бы специалисту память для ее разгона и получения скажем 25% прироста методом прошивки таймингов в чипы памяти и уже потом только тестировать заново и делать какие-то заявления. Откуда такие непрофессиональные работники, делающие пространные заявления в Сбербанке непонятно.

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

Если разница в разы между 8 ядрами Эльбруса и 28 ядрами на интеле, то конечно разница в разы «удивительна». Это только какой-то Петя со школы такое может заявлять без глубокого вдумчивого разбора и цифр. А тут предлагают верить «спецам» Сбербанка. Ну зачем так позорить собственную деловую репутацию?

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

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

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

Суть в том, что идея Эльбруса не выстрелила

Ну хватит горячку пороть - все у кого она не выстрелила были уже другие решения, с которыми им было проще работать и они уже давали результат - очевидно, что тот же интел понимал, что х86 развивать им проще, т.к. он а) уже был б) под него уже разработано было достаточно ПО в) дешевле и доступнее разработка оптимизирующих компиляторов 4) широкое слово - было тупо конкурентом самим себе, особенно с учётом того, что во время когда начали забивать на широкое слово одной из причин стал подъём АМД, поэтому итаниум забросили с точки зрения экономии и перераспределения ресурсов. Это ситуационная, а не абсолютная выгода - выстреливающая на короткой дистанции, без гарантий на длинной.

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

А как предлагаете, в начале нулевых заниматься спарком и всё ? Особенно при том что он заведомо был на догоняющих ролях по сравнении с х86 и при том факте, что у нас ЖЕЛЕЗЯЧНИКОВ мало, а РАЗРАБОТЧИКОВ много. Я полагаю Эльбрус сохранили потому, что все спецы понимали и понимают, что он перспективнее собратьев на длинной дистанции, плюс основное достоинство ведь не в широком слове и пр., а в отсутствии спекулятивщины, что в том числе улучшает определённость вычислений и большую безопасность.

AKonia ★★
()
Последнее исправление: AKonia (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.