По итогам тестирования серверов на «Эльбрусах» Сбербанк в ближайшие годы использовать их не станет
В предположении Жбанкова, чтобы соблюсти большую часть требований нужно просто переупаковать сервер, не трогая сам процессор и ОС. «Надеемся, в МЦСТ нас услышат, и в будущем серверы будут в более доступном варианте для применения в таких компаниях как Сбербанк. Такие серверы сейчас в эксплуатацию взять не можем».
В тестах, которые вместе с оценкой результатов заняли четыре месяца, участвовали два различных типа серверов ( двух- и четырехпроцессорные) на восьмиядерных процессорах «Эльбрус 8С». Отметим, что МЦСТ уже подготовила массовое появление на рынке следующей серверной модели своих чипов — «Эльбрус-8СВ». На сайте компании говорится, что они серийно выпускаются с 2020 г., но рынок с ними пока знаком ограниченно. В то же время CNews известны отзывы производителей вычислительной техники, в соответствии с которыми эти новые изделия заметно превосходят своих младших братьев.
Как еще испытывались серверы на «Эльбрусах»В отношении серверов на российских чипах Сбербанк применил свою стандартную многоуровневую систему тестов. В обычном случае, после провала первого уровня, рассмотренного выше, остальные этапы уже не проводятся. Для «Эльбрусов» Сбербанк сделал исключение.
На других этапах было проведено синтетическое тестирование на основе известных бенчмарков PGbench из пакета PostgreSQL и SPEC CPU 2017, а также прикладное тестирование на основе Java-приложения, реализующего бизнес-логику.
В качестве критериев по оценке продуктов использовались ценовая эффективность (количество транзакций на $100 млн), средняя производительность на сервер с типовой нагрузкой, а также время старта и отклика Java-приложения.
Сравнение проводилось по отношению к серверу на базе 20-ядерного чипа с частотой в 2,1 ГГц — Intel Xeon Gold 6230. В Сбербанке такую технику называют классической (не топовой); она тысячами закупается этой организацией.
Изделия на российских чипах уступили зарубежному конкуренту по всем параметрам, однако полученные результаты сотрудников Сбербанка все же «неожиданно и очень приятно» удивили.
«Мы ожидали, что разница будет не в разы, а в 20-30 раз, — отмечает Жбанков. — Для нас это реально удивительно». Вторым фактором удивления для тестировщиков стал вывод о том, что перед ними оказался законченный продукт. По словам специалиста, обычно российские разработчики приходят к ним с предложениями об использовании своих решений, имея на руках просто чертеж.
«На данный момент “Сбер” говорит нет, но мы приятно удивлены, что это вообще работает, — резюмирует Жбанков.
Рекомендации СбербанкаПо итогам тестирования в Сбербанке делают вывод, что процессоры семейства «Эльбрус» имеют теоретический потенциал роста производительности: увеличение тактовой частоты, увеличение количества ядер, увеличение объема и ускорение памяти (в т. ч. числа контроллеров памяти).
«Рекомендуем перейти на более современный техпроцесс и использовать современные стандарты оперативной памяти, — говорится в справке банка. — Необходимо провести тестирование серверов «Эльбрус» под управлением сертифицированных ФСТЭК операционных систем по профилю не ниже ОС.А4 (для применения в проектах, связанных с персональными данными и ГИС). Для конкуренции с лидирующими зарубежными решениями необходимо разработать новый процессор, сопоставимый с ними по характеристикам и производительности на момент его выхода».
Комментарии МЦСТК выступлению Жбанкова с описанными заявлениями на партнерском мероприятии МЦСТ (разработчик «Эльбрусов») специалисты компании подготовили свои комментарии, слайд с которыми был включен в его презентацию.
В этих комментариях сообщается, что стоимостные показатели «железа» МЦСТ планируется улучшить для поколения серверов на базе «Эльбрус-8СВ», с оптимизацией конфигурации под требования Сбербанка.
«За время тестирования улучшили время старта Java-приложений на 30%, — указывают специалисты МЦСТ. — Над ускорением troughput не работали. Запланирована работа по дальнейшему улучшению характеристик Java-машины. Часть функциональных требований невозможно выполнить на не-х86 платформах в принципе».
Также планируется доработка системы менеджмента и конструкции серверов для новой платформы «Эльбрус-8СВ». В МЦСТ полагают, что необходим диалог со службой эксплуатации Сбербанка для выявления первостепенных и второстепенных функциональных требований.
«В будущих версиях платформы “Эльбрус” планируется увеличение объема ОЗУ: сервер “Эльбрус-8СВ” до 1 ТБ, сервер “Эльбрус-16С” до 4 ТБ на сервер, — заверяют в компании. — В будущих версиях платформы “Эльбрус” планируется поддержка стандартов ОЗУ: сервер “Эльбрус-8СВ” до DDR4-2400, “Эльбрус-16С” до DDR4-3200. Для поддержки Enterprise-сред для контейнеризации и виртуализации для использования в облачных платформах заложены технические возможности в процессор “Эльбрус-16С”».
Уже вне презентации Жбанкова МЦСТ представила некоторые дополнительные комментарии.
«Java-приложение: это сложный ПАК, включает Java-application и СУБД, МЦСТ не имело доступа к приложению, что не позволило провести полноценный анализ, — говорится в них. — Удалось вслепую улучшить время старта Java-приложения и задержку отклика в три раза только подбором опций запуска Java-машины».
Для цели тестирования Сбербанком было разработано и передано макетное приложение, — продолжают сотрудники МЦСТ. — Для этого макетного приложения за счет доработки Java-машины и подбора опций улучшили среднее время отклика на процессоре “Эльбрус-8С” с исходных 24 мс до 4 мс (в шесть раз), при этом на X86 (Соге i7-9700 CPU 3 GHz) оно получилось 3 мс».
«При запуске Java-приложения на сервере загружались не более четырех ядер, что позволило платформе х86 поднимать частоту до 3,9 ГГц, что, скорее всего, не соответствует частоте ядер полностью загруженного сервера (2,1 ГГц)», — добавляют в МЦСТ.
"Фух! Оно не взорвалось!"
На данный момент “Сбер” говорит нет, но мы приятно удивлены, что это вообще работает, — резюмирует Жбанков.
"The number of transistors in a dense integrated circuit (IC) doubles about every two years."
Представитель «Сбера» пояснил, что передал производителю все замечания по внешнему виду, необходимым для установки системам (доработать кабельную подводку, добавить рельсы, сделать индикацию на каждый элемент и реализовать систему мониторинга и удаленного управления) и результаты тестирования производительности серверов."
Сервак, Карл, сервак у которого вообще нет ни мониторинга, ни удаленного управления...
nuff said)
Ясно конечно. Ответ очевиден - распил бабла, но блядь...
Алгебраи́ческий тип да́нных — в информатике наиболее общий составной тип, представляющий собой тип-сумму из типов-произведений. Алгебраический тип имеет набор конструкторов, каждый из которых принимает на вход значения определённых типов и возвращает значение конструируемого типа. Конструктор представляет собой функцию, которая строит значение своего типа на основе входных значений. Для последующего извлечения этих значений из алгебраического типа используется сопоставление с образцом.
Простым примером алгебраического типа данных является список. Действительно, список имеет два конструктора — конструктор пустого списка и конструктор пары, первым элементом которой является значение определённого типа, а вторым — список.
https://en.wikipedia.org/wiki/Algebraic_data_type
Или:
Тип-сумма (англ. sum type; также Σ-тип, меченое объединение) — конструкция в языках программирования и интуиционистской теории типов, тип данных, построенный как дизъюнктное объединение исходных типов.
Наряду с типом-произведением является одной из важнейших форм алгебраического типа данных и одним из способов конструирования типов в интуиционистской теории типов и её вариантах. Перечисляемый тип может быть рассмотрен как вырожденная форма типа-суммы — размеченное объединение единичных типов (англ. unit types).
С точки зрения изоморфизма Карри — Ховарда, сопоставляющего типы данных и конструктивные математические доказательства, тип-сумма соответствует логической дизъюнкции.
https://en.wikipedia.org/wiki/Tagged_union
Я не буду тебе копировать всю википедию, но если интересно то можно с неё начать, если загуглить "алгебраические типы данных в теории типов" и собственно "Тип-сумма". Желательно на английском.
А касательно джавы, то как оказалось этот вид типов таки добавили год назад - https://openjdk.java.net/jeps/360 там есть и объяснения и ссылки дальше зачем и почему.
Хорошо, что все похуй, ведь это вдруг прийдеться понимать семантику стоящую за синтаксисом, уж лучше продолжать страдать и лепить xml конфиги и ебаные атрибуты. Зато миллионы мух смогут продолжать жужжать про джжаву и про интерпрайз-з-з.
Но на деле, даже Scala программисты не всегда заморачиваются с этой замудрённой академической дичью, просто потому, что им нужно решать задачу, а не делать диссертацию.
В Java, и прочих промышленных языках, излишнее усложнение чего-лоибо вообще будет катастрофой, потому что цена обучения не-портачащих программистов увеличится в разы, а профита от этого примерно ноль.
Промышленный инструмент обязан быть простым, однозначным, и интуитивно понятным, без вдумчивого изучения сложных теоретических талмудов, которые на практике не только не нужны, но и вредны.
Только это враньё про "простой инструмент" - часто идет борьба с языком, что бы подпереть его костылями из бесконечных талмудов про паттерны, ковыряние в чужих фреймворках слепленные такими полудурками, которые из-за непонимания базиса делает интуитивно непонятные программные интерфейсы с нарушениями этих ваших солидов где только можно.
Я не утверждаю, что надо написать диссертацию, но если понимания нет, а язык был кастрированный, то и жопной боли будет намного больше. Потому что система типов предназначена для написания человеческого т.н. ДДД, и отлова ошибок на этапе компиляции, а не потом. Так что в этом смысле из-за абьюза конфигов и атрибутов джава код сосет как промышленный инструмент.
2. Для более сложной логики берут более подходящий инструмеет. Только оперируют не в тех терминах, что прислал ты, а в более приземленных, хотя это то же самое.
3. При необходимости, это совмещается. Конкретно жаба и скала прекрасно позволяют использовать компоненты друг друга, бо компилятся совместно в один байткод.
Так и запишем "джава - для обезьян".
Ты видимо даже не прочитал обоснование зачем это все надо было добавлять в джаву15. Наоборот, именно потому что приходится писать сложный код для простых вещей и как-раз работа про перекладывание и преобразование данных очень неплохо описано и облегчается, когда ты можешь объекты не только умножать, но и складывать. А так то да, обезьяны уже подписывали такого, что люди делают бизнес на выпуске бесконечных талмудов как рефакторить код или раскладывать говно по коробочкам. Только говно остаеться говном, сколько кровати не двигай.
2)...
Ну так почему не брали?
И 3) в огороде бузина, в байткоде - скала. Речь же идёт о косяках в джаве и похожих языках. Наличие скалы не делает джаву лучше. Это как говорит, что питон хороший, потому что есть Джулия, или си++ из-за раста
ну и нахрен тебе йава тогда? возьми счёты и считай свой кровавый энтерпрайз.
а ещё от тебя попахивает айтишным нигилизмом.
Можно сколько угодно рассуждать о преимуществах паруса, или даже дизеля с гребным винтом. Более того, эти преимущества очевидны.
Но на галере кровавого энтерпрайза гребцам нужно давать вёсла. Простые, понятные, и без излишеств и возможности сильно навредить при их использовании. И без требований к сложному обучению использования этого инструмента.
>навредить
ахаха, вот только сегодня хабр пишет про дырищу в log4j
https://habr.com/ru/post/595935/
туда же можно добавиль множество уязвимостей с buffer overflow в openssl (правда это не йава, но С, как раз "без требований к сложному обучению использования этого инструмента".
короче мыши плакали кололись, но продолжали жрать кактус
сума типов: это или то
произведение типов: это и то.
если так не понятно, то собеседник дебил. чего тут ещё объяснять?
хлебинтегралы у белорусоввсё просрутстанут не такими стыдными.на разработанной ARM архитекрурескопипащен со старого Intel-овского чипа. И выпускалсяTSMC"Квазаром".Но конечно грустно, сколько наших денег жрут эти уебища...
А, на счёт частности тоже большой вопрос - компания была основана на базе МФТИ, кто владеет акциями не известно, зато Ростех уже подбивает клинья к ним.
А на счёт неплохой продукт... Как ты назовешь продукт который уступает по характеристикам аналогам и стоит не дешевле? Я бы назвал это плохой продукт, который покупают только те кто не может отказаться от отечественного производителя.
Ну а распил и рукожопство неотъемлемая часть гос контрактов, тут не работает презумпция невиновности.
>околонулевая поддержка в софте
>"пока не дотягивает до лидеров рынка"
тактичненько
Никто не продаст эльбрусу что-то новое за ту цену, которые они предлагают, потому что пилить бабки нельзя будет, а вот барахлишко, которое никому не всралось и пытаться на их базе создавать замену лидеров рынка - это просто ебанный стыд и бабки в никуда. Собственно как и вся путинская история правления.
ну и понятное дело, что обыватели не привыкли замерять на латентность системы, оно им и не нужно.
А вот в серверах латентность замеряют, т.к влияет на количество обрабатываемых запросов.
Вот тебе примеры специфических тестов на латентность, в большинстве тестов используется именно миллисекунды для измерения:
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=2
Вообще на самом деле VLIW с академической точки зрения тема достаточно веселая, может, они реально что-то толковое в этом направлении сделали, вот только рынок уже давно решил, что VLIW нинужин, сейчас все ставят на суперскалярность. Такие дела.
... полная лажа, даже теоретически в режиме dsp упирающаяся в количество алу и скорость памяти. а если код с джампами так вообще ад и содомия в плане скорости. изучил бы эту самую академию то.
современные штеуды быстрые за счёт предсказателя ветвлений, который на кристалле больше половины места занимает, а остальное - кэш.
россиянским воякам он и интересен как dsp, а не как процессор общего назначения.
А бранч предиктор тебе и на VLIW ничего не мешает сделать. Вообще по сути VLIW во многом идеологически похож на суперскалярщину, только вместо риал-тайм распределения у тебя все веселье происходит ещё в компиляторе. По-моему, с академической точки зрения должно быть интересно и весело придумывать, как переставлять и паковать инструкции так, чтобы получилось нормальное распределение по алу вне зависимости от бранчей (в отличие от суперскалярного цпу, которому похуй, потому что в отличие от компилятора там есть бранч предиктор, можно смотреть в BTB и сразу наполнять ROB). Естественно, на многих задачах это окажется менее эффективно. У VLIW и другие минусы есть - например, эффективного распределения алу при smt/гипертрединге не выйдет =)
Короче, я ни разу не говорил, что это нужно и полезно в обобщённом случае. Поэтому рыночек и зарешал. Но - весело. Интересный концепт. По идее, в некоторых конкретных ситуациях, если в коде реально дохуя параллелизма, и хочется поменьше энергии тратить, то VLIW реально может оказаться выгоднее стандартного ооо суперскаляра. Пример - как ты и сказал, некоторые dsp.
Как-то остальные страны живут без своих автомобилей, самолетов, кораблей и много чего другого...
Зато нахуя
Осталось построить десяток закидывательных установок с достаточной грузоподъемностью.
Насколько я знаю, африканские страны покупают иностранную технику и частенько бу, собственно системы им достаются скорее всего так же.
Например Namibian CPU producer PEBL - в 2015 чё-то делала да так что Интел возбудилась, хз может патенты воровала.
Гугл чето не находит статьи - но в 2000 лично видел прайс для вояк на процы\микроконтроллеры 3x86 80x86 2x86 из Киевского завода с указанием количества произведённого в году и кол-ва на складе и цены. Кол-во за год от 1000 до 10 000 штук цена за штуку 50-1000$.
А за пруфф можно и срок словить... - подписка толи 5 толи 15 лет.
2) зачем это нужно? почему не вложиться в тот же SPARC, MIPS, POWER или любую другую открытую архитектуру, которая хоть как-то поддерживается в софте?
>тестовые образцы у нас действительно делают> где и/или как? Тут такое дело, что процы свою рыночную цену потому что конвейер, а без конвейера единичное производство будет стоить миллиарды. А если получится брак? Скептически
Ну , возможно, но уровень всё таки немного другой, а может просто скопировали оборудование, а диски закупали под него,особо данных нет.
Это все штучные продукты и ни у одной страны нет монополии на полный цикл производства.
Людей обученных как раз полно, но сейчас им приходится уезжать за бугор, т.к. нет такой востребованности, в том же Зеленограде все не могут уйти в NXP, Миландр и прочее.
Но это все же лучше чем как в других республиках просто убивают эти направления.
Вот китай свой х86 на основе VIA выпустил и не "вы*бывается" с уникальностью... горы отлаженого софта. А не самобытное ПО - для запуска которого надо парочку высших образований в сегменте ИТ и знание ЛИЧНОГО телефона разработчика.
https://3dnews.ru/1008235/vsestoronnie-testi-tsp-zhaoxin-x86-kitay-sokrashchaet-razriv
"К концу 2019 года согласно данным «Спарк-Интерфакс» «Байкал Электроникс» получило субсидий от Минпромторга на 2,2 миллиарда рублей. ... Всего же компания получила от государства около 5 миллиардов рублей."
Но я к тому, что без сторонних финансовых поддержек любой проект обречён на провал, думаю никто не назовет успешный проект, который смог выплыть и стать успешным и полезным обществу и исключительно на бюджетных вливаниях.
Использовать их я, конечно же, не стану.
А люди реально не понимают, что в AMD/Intel/Nvidia работают профессионалы которые всю жизнь только ASICи и проектируют которые учились у таких же профессионалов, а не как у нас ASICами занимается бывшие ПЛИСеры. У этих компаний есть деньги и на ОКРы и на большие ЗП для своих больших спецов.
Я не спорю, что у МЦСТ или других отечественных фирм есть проблемы с менеджментом, но требовать от них того же что и короли индустрии делают это бред. Даже пусть они на бюджетные деньги свои процессоры проектируют. Всю равно на плитку в Москве больше денег тратят, чем на всю российскую микроэлектронику.
"На плитку больше воруют"
"А так пускай воруют, повод погордиться"
Ну а во вторых, не эффективные статьи расхода классифицируются как растрата по УК.
Блять, ну красиво они обыграли "другой, нормальный процессор дайте, плес"
накатили бы x86-64 нативно да еще и под какойнить уже существующий сокет, цена внедрения этой поделки настолько высока, что единственный повод внедрять её, если тебя заставляют и ты не можешь эмигрировать.
"The 80486 processor has been on the market for more than 20 years and so cannot be subject to patent claims. The pre-586 subset of the x86 architecture is therefore fully open." (c)
Как вариант, не хотите меинстрим, сертифицируйте mips, что собственно baical и сделали, но им тоже до нормальных образцов топать и топать, оба проекта, что Эльбрус и баикал, считаю роспилом, ибо они изначально неконкурентно способные, теже китаицы напрягут mediatek или huawei и наштампуют на арм гораздо более производительные системы.
производство эльбрусов, кстати, могут отключить точно также - быстро и решительно внеся МЦСТ в бан-лист
Хотел бы увидеть на тех же эльбрусах как люди пытаются запустить виндовые приложения, потому что на тех же байкалах винду можно запустить дописав драйвер чипсета, но она остается без драйверов (привет Дмитрию Бачило).
само собой пинать хуи посреди пустыни и родить 14нм которые даже мегакорпорации рожали 30 лет не получится, а если получится то ценник будет такой, что можно еще 30 лет пинать хуи пока найдётся хоть один покупатель.