-
![[image]](https://www.balancer.ru/cache/sites/to/4p/4pda/s/128x128-crop/Cd9ZVz0Tz02ZwuedZdOVFPtyPpDGZY0p.jpg)
Импортозамещение в ИТ
попытка использовать процессор байкал вместо импортныхТеги:
U235
yacc> Именно.
yacc> Поэтому когда Татарин говорит о легкости переноса на процессоры 10 летней давности - я падаю со стула.
yacc> А он, походу, в этом уверен
Ну тогда ты точно упадешь со стула узнав что значительная часть современных сервисов на процессорах 10 летней давности крутится. Сервера - штука дорогая и их так часто не меняют.
yacc> Поэтому когда Татарин говорит о легкости переноса на процессоры 10 летней давности - я падаю со стула.
yacc> А он, походу, в этом уверен
Ну тогда ты точно упадешь со стула узнав что значительная часть современных сервисов на процессорах 10 летней давности крутится. Сервера - штука дорогая и их так часто не меняют.
инфо
инструменты
U235> Ну тогда ты точно упадешь со стула узнав что значительная часть современных сервисов на процессорах 10 летней давности крутится. Сервера - штука дорогая и их так часто не меняют.
Это если это IBM
Это если это IBM
Bredonosec
собаки лают, а караван идет.
Baikal-M: какую экосистему успел собрать вокруг себя первый российский ARM-процессор
Появления этого процессора действительно ждали. Минпромторгу нужно было не просто удостовериться в том, что финансовая поддержка разработки чипа не пропала зря, но и закрыть вопрос об отсутствии во вверенном министерству сегменте рынка конкурентной среды. С выходом Baikal-M в России исчезла монополия в сфере процессоров общего назначения: доступных отечественных линеек такого рода чипов стало не одна, а две. Что касается российских разработчиков «железа» и софта, а также его госзаказчиков, то для них, наконец, открылись более широкие возможности полноценного включения в программы импортозамещения, столь широко декларируемые и поддерживаемые в России на госуровне уже в течение нескольких лет. Часть этих разработчиков CNews опросил в рамках подготовки данного обзора.
Baikal с литерой «М»
Полтора года назад на микроэлектронном рынке России произошло весьма примечательное событие. В октябре 2019 г. компания «Байкал Электроникс» представила первый отечественный процессор общего назначения, реализованный на архитектуре ARM (от англ. Advanced RISC Machine).
Новинка получила название Baikal-М. Она представляет собой выпускаемую по техпроцессу 28 нм так называемую систему на кристалле. В ее основе лежит восемь 64-битных ядер ARM Cortex-A57 (ARMv8-A; четыре кластера по два ядра) с частотой до 1,5 ГГц и 8-ядерный графический процессор Mali-T628 с частотой до 700 МГц с аппаратным ускорением воспроизведения видео в форматах H.264/H.265. Объем кэша третьего уровня (L3) — 8 МБ. Параметры оперативной памяти: 2 × DDR3/DDR4-2133 64 bit DRAM, ECC. Заявленное энергопотребление: менее 30 Вт.
Партнерские отношения с британской корпорацией ARM (правообладатель одноименной архитектуры) у «Байкал Электроникс» возникли еще в 2014 г., когда компания приобрела лицензию на самое современное на тот момент процессорное ядро, которое и легло в основу будущего чипа.
В то время компания уже заканчивала разработку своего первого 28-нанометрового процессора Baikal-Т, увидевшего свет в середине 2015 г. Но он был реализован на принципиально иной архитектуре — MIPS (также созданной в соответствии с концепцией RISC, то есть для процессоров с сокращенным набором команд) и нацелен на использование в телеком-оборудовании, СХД, встраиваемых системах.
В этой связи проявившийся интерес к архитектуре ARM в «Байкал Электроникс» тогда объяснили, в первую очередь, обширностью экосистемы, которая развивается одними из самых быстрых темпов в мире и является критически важной для рыночного успеха процессора общего назначения, которым является Baikal-M.
Литеру «M» в названии ARM-процессора Baikal-M можно воспринимать как отсылку к мобильности. Наиболее широкое применение архитектура ARM в силу своих особенностей нашла в чипах для смартфонов и других портативных устройств. Однако в последние годы архитектурная специализация стала изрядно размываться, а чипы становятся более универсальными. Поэтому Baikal-M ориентирован, прежде всего, на использование в настольных ПК и моноблоках, мини-серверах, промышленных системах.
Его упрощенные версии Baikal-M/2 и Baikal-M/2+, о начале разработки которых «Байкал Электроникс» объявил в октябре 2020 г., нацелены на сегменты легких рабочих станций и тонких клиентов.
Блок-схемы упрощенных чипов «Байкал-М/2»
При этом сейчас компании заканчивает работу над следующим ARM-процессором — Baikal-S с топологией 16 нм, который предназначен, ни много ни мало, для серьезных серверных систем. Также компания уже ведет работу над следующими перспективными процессорами, как на архитектуре ARM для пользовательских систем, так и на архитектуре RISC-V для встроенных и телеком-применений. Подробные характеристики данных проектов пока не сообщаются.
Статус российской микросхемы и перспективы спроса на нее
Ровно через год после презентации Baikal-M Минпромторг присвоил ему статус российской микросхемы второго уровня, свидетельствующий о том, что он официально относится к промышленной продукции, произведенной на территории России. На основании этого, процессор был включен в тематический реестр министерства. Именно на этот реестр чиновники обязаны ориентироваться в приоритетном порядке при тематических госзакупках.
В соответствии с действующей нормативной базой, разработчик российской микросхемы второго уровня обязан обладать правами на его конструкторскую документацию, а проектирование, разработка и испытания микросхем должны происходить в границах нашей страны. От микросхем первого уровня они принципиально отличаются только тем, что их непосредственное производство осуществляется за рубежом.
Сегодняшнее положение дел в России таково, что ни одна процессорная разработка малой топологии получить статус первого уровня не может по определению — у нас просто нет соответствующих производственных мощностей. Создание в России фабрик, способных выпускать чипы с топологией 28 нм и ниже (вплоть до 5 нм), прописано в утвержденной в январе 2020 г. стратегии развития электронной промышленности на период до 2030 г. — но без указания каких-либо четких сроков. А пока самое развитое в этом отношении зеленоградское предприятие «Микрон» наладило серийный выпуск продукции только по нормам 90 нм и обзавелось мощностями, способными произвести процессоры по топологии 65 нм для опытно-конструкторских разработок. В этой связи все разработчики продвинутых отечественных чипов, как правило, заказывают их выпуск на тайваньской фабрике TSMC.
Так или иначе, для Baikal-M присвоенный статус в конце 2020 г. стал крайне актуальным в силу того, что наметилась тенденция к исключению из вышеупомянутого реестра Минпромторга той техники, которая в своей основе имеет зарубежные чипы.
Так, уже с 1 января 2021 г., чтобы считаться произведенной на территории России, на отечественных процессорах обязаны строиться все СХД. А в самом конце декабря 2020 г. правительство аналогичные законодательные нормы утвердило и для ряда других категорий оборудования: ноутбуков и планшетов, настольных ПК и моноблоков, твердотельных накопителей, материнских плат, сканеров, принтеров, МФУ и пр. Для различных категорий продукции вступление в силу законодательных изменений наступит в разное время — в интервале от 1 июля 2021 г. до 1 января 2022 г.
Новое финансирование, новые тиражи
В пользу того, что «Байкал Электроникс» сумеет удовлетворить наметившийся масштабный спрос на свои процессоры, говорит факт появления у компании нового инвестора и анонсированные сразу после этого планы по-настоящему массового выпуска чипов.
Ранее ключевыми акционерами «Байкал Электроникс» выступали компания «Т-Платформы» и Т-Нано (технологический центр «Роснано»). Разработки Baikal-M, равно как и Baikal-T, и Baikal-S, осуществлялись в основном на средства Т-Нано с привлечением финансирования со стороны Минпромторга.
Теперь все указывает на то, что контрольный пакет акций компании (то есть не менее 50%) окажется во владении группы «Вартон». О появлении этого инвестора стало известно в октябре 2020 г. Слово «группа» в отношении него можно использовать лишь условно. Как ранее отметил в разговоре с CNews представитель «Вартона», речь идет о некоем конгломерате юридически не объединенных очень разнонаправленных бизнесов (выпуск светодиодов, разработка софта и пр.).
Сделка с «Вартоном» пока не закрыта; возможно, все юридические вопросы будут закрыты в апреле 2021 г. Однако еще в октябре 2020 г., со слов гендиректора «Байкал Электроникс» Андрея Евдокимова, можно было заключить, что «Вартон» уже в тот момент начал принимать самое активное участие в развитии компании.
Тогда же было объявлено, что на тайваньской фабрике TSMC был размещен заказ на 13 тыс. Baikal-M, до конца 2020 г. там же будет заказана партия в 100 тыс. изделий, а в I квартале 2021 г. — еще не менее 100 тыс. штук. По текущей информации, с учетом крайнего дефицита мощностей у всех производителей полупроводников в мире, компания рассчитывает начать поставку чипов из первой партии в 130 тыс. штук в III квартале 2021 г. Следующие партии, большие по объему, ожидаются в 2022 г.
Тиражи подобного масштаба для «Байкал Электроникс» являются явным прорывом. Чипов Baikal-T за пять лет, прошедших с момента их разработки, было выпущено всего около 50 тыс. штук, а в отношении новых Baikal-M компания располагала лишь инженерными образцами из небольшой партии порядка 2 тыс. штук.
Более того, заказы сотен тысяч чипов можно считать и совершенно новым явлением для современной России. У главного конкурента «Байкалов» планы на выпуск его продукции, как выяснил CNews, в разы скромнее.
Отметим также, что публичные планы по разработке вышеупомянутых новых упрощенных чипов Baikal-M/2 и Baikal-M/2+ появились у «Байкал Электроникс» также после выхода на арену «Вартона». До этого анонсы своих новинок компания последний раз выпускала в январе 2016 г.
Бизнес-модель: равные условия для всех партнеров
Примечательно, что c появлением у «Байкал Электроникс» новых акционеров бизнес-модель производителя, по заверениям генерального директора Андрея Евдокимова, не претерпит серьезных изменений. Компания сохранит фокус на разработке чипов для вычислительной техники широкого спектра, а продуктовая линейка будет расширяться, ориентируясь на рыночный запрос. Он также отметил, что производством конечных устройств (компьютеров, моноблоков, ноутбуков и пр.) «Байкал Электроникс» заниматься не собирается.
«Перед командой сейчас стоит задача в короткий срок обеспечить совместимость процессоров Baikal со всеми основными элементами российского ИТ-ландшафта. Это подразумевает укрепление сотрудничества со всеми отечественными вендорами оборудования и ПО на равных условиях, развитие технологического партнерства в части интеграции продуктов и создания комплексных программно-аппаратных решений, в чем мы уже достигли немалых успехов», — подчеркнул Андрей Евдокимов.
Адаптация российских ОС
Доказательством справедливости приведенных выше слов Андрея Евдокимова могут служить комментарии конкурирующих друг с другом отечественных разработчиков ОС, которые активно ведут проекты по интеграции с Baikal-M.
В частности, в компании «Базальт СПО», разрабатывающей линейку ОС «Альт» в разговоре с CNews подчеркнули, что реализованная в Baikal-M ARM-платформа aarch64 — это одна из целевых архитектур для данной организации. Летом 2020 г. компания выпустила новый обобщенный ISO-образ операционной системы, который работает на Baikal-M, а осенью того же года вышел универсальный защищенный дистрибутив, недавно сертифицированный ФСТЭК.
В компании говорят, что плотно работают с «Байкал Электроникс» по формированию универсального ядра Linux, в котором реализована поддержка Baikal-M. «Байкал Электроникс» регулярно выпускает новые версии SDK (software development kit) — набор прошивок, обновляющих функциональность материнской платы; в этот набор включаются и обновления ядра Linux. Представители «Базальт СПО» заверяют, что на сегодняшний день ОС «Альт» работают на всех существующих платах с процессорами Baikal-M.
В этой связи в компании напоминают, что ее разработки, выполненные для поддержки aarch64, размещаются в открытом репозитории «Сизиф». Разработчики различных приложений могут использовать эти пакеты для создания своих продуктов, способных работать на устройствах с процессорами Baikal-M.
Представители «Ред Софт» — разработчика операционной системы «Ред ОС» на базе ПО с открытым кодом — заверили CNews, что считают Baikal-M с ОС этой компании на борту отличной базой для офисных машин начального уровня и информационных стендов. В «Ред Софт» отмечают, что с переходом «Ред ОС» на самое свежее ядро Linux 5.10 была актуализирована поддержка входящего в Baikal-M графического ускорителя Mali, что позволяет более комфортно работать с медиа-контентом, а также повысило отзывчивость графического интерфейса операционной системы. На данный момент под Baikal-M производится адаптация «Ред ОС» версии 7.3.
В дочерней компании «Ростелекома» — «Открытая мобильная платформа» (ОМП), которая занимается разработкой и внедрением первой российской мобильной ОС «Аврора», отметили в разговоре с CNews, что имеют опыт сотрудничества с «Байкал Электроникс» еще по линии Baikal-T — в рамках научно-исследовательской работы. Данное взаимодействие с появлением Baikal-M получило мощный импульс для дальнейшего развития, особенно с учетом опыта и экспертизы ОМП в поддержке ARM-архитектуры, наиболее распространенной на рынке мобильных устройств.
В ноябре 2019 г. было подписано соглашение о создании информационных киосков на базе отечественного производства, элементной базы и ОС «Аврора» между ОМП, «Байкал Электроникс» и научно-производственным предприятием «Итэлма». Такие киоски предназначены для использования в качестве инфоматов в МФЦ, префектурах, мэриях, в судебных учреждениях, в качестве инфоматов и терминалов саморегистрации в медицинских учреждениях, в качестве устройств для автоматической экзаменации в ГИБДД, а также в качестве терминалов самообслуживания в службах занятости.
В 2020 г. на индустриальных выставках были представлены первые результаты этого сотрудничества: инфокиоски на Baikal-M с защищенной ОС «Аврора» версии 3.2.1.
Что же касается Astra Linux, по словам генерального директора Ильи Сивцева, взаимодействие с «Байкал Электроникс» велось и ведется по двум направлениям: поддержка аппаратной платформы и развитие экосистемы ПО.
В части совместимости с аппаратной платформой обеспечена полноценная работа ОС Astra Linux на SOC Baikal-M, включая поддержку видеочипа Mali-T628, в том числе с использованием «свободных» видеодрайверов. В настоящее время основной задачей является обеспечение корректного функционирования Astra Linux на всех новых материнских платах российских производителей. В рамках проектных работ также решается вопрос оптимизации производительности и энергопотребления Astra Linux на отечественном вычислительном оборудовании.
В области развития экосистемы партнеры «Байкал Электроникс» успешно портировали на Astra Linux Special Edition, работающую на процессорах Baikal, офисный пакет «МойОфис», антивирус Dr.Web, «КриптоПро CSP», VipNet Client, VDI-клиент Termidesk, средство резервного копирования RuBackup, клиент видеоконференций TrueConf, платформу чат-ботов WorksPad и другие программные решения. Подтверждено стабильное и эффективное функционирование среды разработки и запуска Java — Liberica JDK, за счет чего многие российские компании смогут использовать свои приложения на java без внесения изменений в исходный код.
«В сотрудничестве с «Байкал Электроникс» мы провели комплексные исследования и смогли предоставить заказчикам на пилотные испытания готовые программно-аппаратные комплексы с процессором Baikal-M под управлением операционной системы Astra Linux в различных исполнениях: рабочая станция, терминальная станция и моноблок. Кроме того, нам удалось реализовать актуальные для потребителей практические сценарии применения ОС на российской вычислительной платформе. Мы всегда поддерживали отечественных разработчиков СВТ, но теперь это направление стало стратегическим, поэтому любое их изделие сразу же получает приоритет первого уровня на интеграцию со всем стеком продуктов ГК Astra Linux», — отмечает Илья Сивцев.
Базовое «железо»
Описание складывающейся вокруг Baikal-M хардверной инфраструктуры стоит начинать с материнских плат. В октябре 2020 г. Андрей Евдокимов из «Байкал Электроникс» отмечал, что на тот момент наибольшее распространение успели получить собственные платы компании в форм-факторе Mini-ITX, которые она производит по лицензии «Т-Платформ», а также изделия «Эдельвейс» и «Проект Лагранж».
Пионером на этом поле стал «Эдельвейс», презентовавший свою разработку в форм-факторе Mini-ITX в июле 2020 г. В компании указывают, что ее плата имеет компактный и унифицированный дизайн и может быть использована в составе любого десктопного решения совместимого с Mini-ITX.
В ходе подготовки данного обзора в «Эдельвейсе» отметили факт появления также и своей серверной платы E107, предназначенной для построения линейки серверов общего назначения начального уровня, платформ распределенных СХД в формате стоечных или блейд-серверов, а также продвинутых NAS-платформ.
«Проект Лагранж» выступает разработчиком процессорного модуля Lagrange Sarmah SoM в форм-факторе 70x70 мм с интегрированной оперативной памятью DDR4. Представители компании сообщили CNews, что в совокупности с ее интерфейсными платами (carrierboard) данное решение позволяет организации предложить покупателю целый модельный ряд материнских плат на Baikal-М: в формате Micro-ATX, Mini-ITX и Pico-ITX.
Серийные образцы как самих процессорных модулей «Лагранжа», так и материнских плат на их основе поступят в продажу в конце марта 2021 г. При этом компания бесплатно предоставляет инженерные образцы материнских плат с предустановленной ОС Альт Линукс во временное пользование для тестирования и оценки применимост
К настоящему моменту о разработках своих плат на Baikal-М CNews также рассказали в компаниях 3Logic Group, Aquarius и «Депо». В первой из них сообщили, что освоение серийного производства соответствующих изделий запланировано на лето 2021 г. А пока произведены инженерные образцы, которые представлены в демо-центре 3Logic.
В «Депо» отмечают, что этой компанией была разработана материнская плата для персональных устройств и однопроцессорная серверная материнская плата для серверов и СХД. При этом в компании заверили CNews, что ею уже разрабатывается двухпроцессорная серверная материнская плата для готовящегося к выходу Baikal-S. Она найдет применение в серверах и СХД «Депо», которые появятся в конце 2022 — начале 2023 гг.
Вычислительная техника
Пионером в производстве готовых технических решений на Baikal-М, возможно, также является «Эдельвейс». В конце августа 2020 г. компания сообщила о выпуске своего сенсорного моноблока на этом чипе под управлением ОС «Альт». Система поддерживает до 64 ГБ оперативной памяти типа DDR4.
Также в ассортименте «Эдельвейса» на Baikal-М представлены системный блок формата SFF, системный блок со встроенным источником бесперебойного питания и защитой от нарушений электроснабжения и линейка компьютеров в форм-факторе компактного десктопа для создания автоматизированных рабочих мест.
Моноблок «Эдельвейс» на процессоре Baikal-M
У «Проекта Лагранж» с использованием Baikal-М создан компактный неттоп размером чуть меньше жесткого диска 3,5 дюйма на основе материнской платы Lagrange Sarmah. Развитием данного изделия в компании называют блейд-сервер, позволяющий в одном серверном корпусе форм-фактора 3U разместить до 15 вычислительных машин на базе Baikal-M, а также сочетать их с компьютерами и ускорительным оборудованием на других архитектурах (x86/64 и FPGA) — для построения гетерогенного вычислителя. Кроме того, «Лагранжем» сейчас ведется разработка моноблока на базе Baikal-M и платы Lagrange Sarmah c диагональю экрана 27 дюймов.
У научно-технического центра 3Logic Group, который свое вычислительное оборудование выпускает под маркой «Гравитон», на Baikal-M помимо вышеупомянутых плат разработана линейка настольных моноблоков, двухконтурных моноблоков, настольных и малоформатных ПК. Серийное производство этого оборудования, как и плат, запланировано на лето 2021 г. Инженерные образцы техники также доступны в демо-центре 3Logic Group.
В «Депо» CNews рассказали, что компания на базе собственных плат уже разработала персональный компьютер в корпусе компактного настольного ПК, моноблочный компьютер и двухконтурный комплекс, объединяющий два физически изолированных ПК в одном корпусе моноблока. Образцы данных устройств станут доступны для заказа в рамках программы тестирования в июле-сентябре 2021 г.
На серверном направлении «Депо» на своих платах разработала универсальный сервер начального уровня с производительностью 100 ГФлопс, одноконтроллерные СХД на 8-12 накопителей и отказоустойчивую двухконтроллерную СХД на 24 накопителя. Образцы серверов уже доступны к заказу, образцы СХД появятся в июле 2021 г.
В серийное производство упомянутые данные модели будут запущены во II-III кварталах 2021 г. Сейчас «Депо» работает над получением заключений Минпромторга о подтверждении производства указанных моделей на территории России.
Примечательно, что «Депо» уже приступила к разработке линейки тонких клиентов и ноутбуков на базе разрабатываемых в данный момент «Байкал Электроникс» мобильных процессоров Baikal-М/2 и Baikal-М/2+.
В «Аквариус» сообщили CNews, что на 2021 г. в компании намечен выпуск на Baikal-М нескольких клиентских устройств и серверов. В 2022-2024 гг. компания планирует расширение ряда клиентских устройств (ПК, моноблоки, ноутбуки, тонкие клиенты), одно- и двухсокетных серверов и СХД — на базе как Baikal-М, так и Baikal-S.
Прикладное ПО
На четвертом, по определению самом обширном, уровне экосистемы Baikal-М «Байкал Электроникс», по заверению Андрея Евдокимова, взаимодействует с очень широким кругом отечественных разработчиков. В их числе «Лаборатория Касперского», «Доктор Веб», создатели продуктов «Мой офис» и «Р7-офис», TrueConf, Termidesk, «Тионикс» и др.
Причем количество и качество этих связей растет буквально на глазах. Например, сообщение разработчиков российского офисного пакета «Мой офис» о совместимости его настольных редакторов с аппаратной платформой Baikal-M было опубликовано буквально во время подготовки CNews данного обзора.
«Сейчас наши основные усилия сосредоточены именно на развитии экосистемы ПО вокруг процессоров «Байкал», что очень важно для удовлетворения потребностей конечных пользователей вычислительной техники. К счастью, мы делаем это далеко не в одиночестве, уже десятки российских компаний-разработчиков убедились в перспективности данного направления, поверили в него и выпустили релизы совместимости своих продуктов с «Байкалами». Все вместе мы делаем очень большую работу и до конца текущего года ожидаем дальнейшее серьезное расширение экосистемы Baikal, особенно в области прикладного ПО», — отмечает Андрей Евдокимов.
Прямая речь
В заключении этого обзора (на абсолютную полноту он не претендует; CNews удалось пообщаться далеко не со всеми представителями экосистемы Baikal-M) приведем высказывания топ-менеджеров опрошенных партнеров «Байкал Электроникс» относительно первого ARM-процессора этой компании.
«Baikal-M зарекомендовал себя как современное решение отечественной электроники, которое отвечает высочайшим мировым стандартам, при этом являясь одним из самых экономически привлекательных», — отмечает Алексей Коган, директор по стратегическому развитию компании «Открытая мобильная платформа».
«Baikal-M — это разработка достойного уровня, — говорит Сергей Белкин, вице-президент «Аквариус», руководитель технической дирекции. — «Байкал Электроникс» вносит значимый вклад в развитие отечественной микроэлектроники. Применение распространенных архитектур, таких как AArch64, имеющих обширную экосистему, позволяет упростить построение прикладных решений и миграцию; это преимущество. Недостатки тоже есть, но они по большей части временные и связаны с тиражностью и ценой».
«Мы рады, что нам одним из первых удалось реализовать потенциал процессора Baikal-M для создания функциональных и безопасных рабочих мест, — сказал Александр Грищенков, гендиректор «Эдельвейса». — Пилотные проекты продемонстрировали высокий уровень интереса к нашим решениям, и мы готовим к выпуску новую линейку устройств в ближайшее время».
«Возможности Baikal-M позволяют создавать конкурентоспособные отечественные вычислительные системы, которые будут востребованы государственными и корпоративными заказчиками», — поделился своим мнением Антон Лебединец, директор по продукции научно-технического центра 3Logic Group.
«Перспективы процессоров ARM на всем спектре оборудования сегодня не вызывают сомнений, — рассуждает Евгений Синельников, руководитель саратовского подразделения «Базальт СПО». — Главная проблема разработки ОС, особенно с современными требованиями к безопасности, — стандартизация, отход от стиля разработки для встроенных устройств, когда для каждого из них выпускаются свое ядро и привязанный к нему загрузчик. Только когда пользователь сможет использовать любую ОС для ARM64 для любого устройства на этой архитектуре, мы достигнем действительно ценного для наших клиентов результата. Замечу, что это не только российская, но и общая международная проблема. Надеюсь, что мы будем ее решать совместно с «Байкал Электроникс» и другими разработчиками и производителями аппаратных средств».
«Мы как разработчики отечественных материнских плат такой процессор ждали, — заверяет Александр Корнев, гендиректор «Проекта Лагранж». — Для нас значение имеет как быстродействие, позволяющее построить полноценный ПК, так и доступность документации, и техническая поддержка для обеспечения возможности спроектировать собственную материнскую плату. Все это мы получили в новом процессоре. Производительность Baikal-М даже превзошла наши ожидания. Мы развернули в лаборатории экспериментальное рабочее место разработчика прикладного ПО на компьютере с нашей материнской платой Lagrange Sarmah. Работа на нем оставляет приятное впечатление: полноценное разрешение экрана, быстрая компиляция приложений в среде QtCreator, хорошая скорость отклика в пакете офисных программ. Мы считаем, что Baikal-M имеет все шансы стать по-настоящему массовым и доступным для широкого круга потребителей».
«Важно, с нашей точки зрения, что производитель процессора развернут лицом к рынку и нацелен на массовость применения, а не замыкается на производстве собственных ПК, — добавляет Роман Жарких, технический директор «Проекта Лагранж». — Такой подход многих ведущих зарубежных производителей позволил им увеличить тиражи своих чипов до огромных масштабов. А где большие тиражи, там и качество выше, и цена ниже. При таком подходе производитель, однако, вынужден поддерживать разработчиков открытыми сопроводительными материалами: референс-дизайнами, открытыми дистрибутивами, форумами по обмену опытом — тем, что формирует инженерное сообщество. При такой поддержке решение разработчика о переходе на Baikal-М станет частым явлением, а скорость выхода новых разработок на рынок значительно увеличится».
«Мы крайне позитивно оцениваем появление еще одного отечественного чипа, который может применяться в тонких клиентах и рабочих станциях начального уровня, — говорит Петр Щеглов, заместитель директора по продуктам «Мой офис». — Процессор Baikal-M хорошо подходит для создания существенно более надежных с точки зрения информационной безопасности решений за счет особенностей дизайна чипа. «Мой офис» ожидает дальнейшего развития линейки продуктов «Байкал Электроникс» и появления более мощных чипов Baikal, которые позволят решать еще больше задач на этой платформе».
Baikal-M: какую экосистему успел собрать вокруг себя первый российский ARM-процессор
Появления этого процессора действительно ждали. Минпромторгу нужно было не просто удостовериться в том, что финансовая... // www.cnews.ruBaikal-M: какую экосистему успел собрать вокруг себя первый российский ARM-процессор
Появления этого процессора действительно ждали. Минпромторгу нужно было не просто удостовериться в том, что финансовая поддержка разработки чипа не пропала зря, но и закрыть вопрос об отсутствии во вверенном министерству сегменте рынка конкурентной среды. С выходом Baikal-M в России исчезла монополия в сфере процессоров общего назначения: доступных отечественных линеек такого рода чипов стало не одна, а две. Что касается российских разработчиков «железа» и софта, а также его госзаказчиков, то для них, наконец, открылись более широкие возможности полноценного включения в программы импортозамещения, столь широко декларируемые и поддерживаемые в России на госуровне уже в течение нескольких лет. Часть этих разработчиков CNews опросил в рамках подготовки данного обзора.
Baikal с литерой «М»
Полтора года назад на микроэлектронном рынке России произошло весьма примечательное событие. В октябре 2019 г. компания «Байкал Электроникс» представила первый отечественный процессор общего назначения, реализованный на архитектуре ARM (от англ. Advanced RISC Machine).
Новинка получила название Baikal-М. Она представляет собой выпускаемую по техпроцессу 28 нм так называемую систему на кристалле. В ее основе лежит восемь 64-битных ядер ARM Cortex-A57 (ARMv8-A; четыре кластера по два ядра) с частотой до 1,5 ГГц и 8-ядерный графический процессор Mali-T628 с частотой до 700 МГц с аппаратным ускорением воспроизведения видео в форматах H.264/H.265. Объем кэша третьего уровня (L3) — 8 МБ. Параметры оперативной памяти: 2 × DDR3/DDR4-2133 64 bit DRAM, ECC. Заявленное энергопотребление: менее 30 Вт.
Партнерские отношения с британской корпорацией ARM (правообладатель одноименной архитектуры) у «Байкал Электроникс» возникли еще в 2014 г., когда компания приобрела лицензию на самое современное на тот момент процессорное ядро, которое и легло в основу будущего чипа.
В то время компания уже заканчивала разработку своего первого 28-нанометрового процессора Baikal-Т, увидевшего свет в середине 2015 г. Но он был реализован на принципиально иной архитектуре — MIPS (также созданной в соответствии с концепцией RISC, то есть для процессоров с сокращенным набором команд) и нацелен на использование в телеком-оборудовании, СХД, встраиваемых системах.
В этой связи проявившийся интерес к архитектуре ARM в «Байкал Электроникс» тогда объяснили, в первую очередь, обширностью экосистемы, которая развивается одними из самых быстрых темпов в мире и является критически важной для рыночного успеха процессора общего назначения, которым является Baikal-M.
Литеру «M» в названии ARM-процессора Baikal-M можно воспринимать как отсылку к мобильности. Наиболее широкое применение архитектура ARM в силу своих особенностей нашла в чипах для смартфонов и других портативных устройств. Однако в последние годы архитектурная специализация стала изрядно размываться, а чипы становятся более универсальными. Поэтому Baikal-M ориентирован, прежде всего, на использование в настольных ПК и моноблоках, мини-серверах, промышленных системах.
Его упрощенные версии Baikal-M/2 и Baikal-M/2+, о начале разработки которых «Байкал Электроникс» объявил в октябре 2020 г., нацелены на сегменты легких рабочих станций и тонких клиентов.
Блок-схемы упрощенных чипов «Байкал-М/2»
При этом сейчас компании заканчивает работу над следующим ARM-процессором — Baikal-S с топологией 16 нм, который предназначен, ни много ни мало, для серьезных серверных систем. Также компания уже ведет работу над следующими перспективными процессорами, как на архитектуре ARM для пользовательских систем, так и на архитектуре RISC-V для встроенных и телеком-применений. Подробные характеристики данных проектов пока не сообщаются.
Статус российской микросхемы и перспективы спроса на нее
Ровно через год после презентации Baikal-M Минпромторг присвоил ему статус российской микросхемы второго уровня, свидетельствующий о том, что он официально относится к промышленной продукции, произведенной на территории России. На основании этого, процессор был включен в тематический реестр министерства. Именно на этот реестр чиновники обязаны ориентироваться в приоритетном порядке при тематических госзакупках.
В соответствии с действующей нормативной базой, разработчик российской микросхемы второго уровня обязан обладать правами на его конструкторскую документацию, а проектирование, разработка и испытания микросхем должны происходить в границах нашей страны. От микросхем первого уровня они принципиально отличаются только тем, что их непосредственное производство осуществляется за рубежом.
Сегодняшнее положение дел в России таково, что ни одна процессорная разработка малой топологии получить статус первого уровня не может по определению — у нас просто нет соответствующих производственных мощностей. Создание в России фабрик, способных выпускать чипы с топологией 28 нм и ниже (вплоть до 5 нм), прописано в утвержденной в январе 2020 г. стратегии развития электронной промышленности на период до 2030 г. — но без указания каких-либо четких сроков. А пока самое развитое в этом отношении зеленоградское предприятие «Микрон» наладило серийный выпуск продукции только по нормам 90 нм и обзавелось мощностями, способными произвести процессоры по топологии 65 нм для опытно-конструкторских разработок. В этой связи все разработчики продвинутых отечественных чипов, как правило, заказывают их выпуск на тайваньской фабрике TSMC.
Так или иначе, для Baikal-M присвоенный статус в конце 2020 г. стал крайне актуальным в силу того, что наметилась тенденция к исключению из вышеупомянутого реестра Минпромторга той техники, которая в своей основе имеет зарубежные чипы.
Так, уже с 1 января 2021 г., чтобы считаться произведенной на территории России, на отечественных процессорах обязаны строиться все СХД. А в самом конце декабря 2020 г. правительство аналогичные законодательные нормы утвердило и для ряда других категорий оборудования: ноутбуков и планшетов, настольных ПК и моноблоков, твердотельных накопителей, материнских плат, сканеров, принтеров, МФУ и пр. Для различных категорий продукции вступление в силу законодательных изменений наступит в разное время — в интервале от 1 июля 2021 г. до 1 января 2022 г.
Новое финансирование, новые тиражи
В пользу того, что «Байкал Электроникс» сумеет удовлетворить наметившийся масштабный спрос на свои процессоры, говорит факт появления у компании нового инвестора и анонсированные сразу после этого планы по-настоящему массового выпуска чипов.
Ранее ключевыми акционерами «Байкал Электроникс» выступали компания «Т-Платформы» и Т-Нано (технологический центр «Роснано»). Разработки Baikal-M, равно как и Baikal-T, и Baikal-S, осуществлялись в основном на средства Т-Нано с привлечением финансирования со стороны Минпромторга.
Теперь все указывает на то, что контрольный пакет акций компании (то есть не менее 50%) окажется во владении группы «Вартон». О появлении этого инвестора стало известно в октябре 2020 г. Слово «группа» в отношении него можно использовать лишь условно. Как ранее отметил в разговоре с CNews представитель «Вартона», речь идет о некоем конгломерате юридически не объединенных очень разнонаправленных бизнесов (выпуск светодиодов, разработка софта и пр.).
Сделка с «Вартоном» пока не закрыта; возможно, все юридические вопросы будут закрыты в апреле 2021 г. Однако еще в октябре 2020 г., со слов гендиректора «Байкал Электроникс» Андрея Евдокимова, можно было заключить, что «Вартон» уже в тот момент начал принимать самое активное участие в развитии компании.
Тогда же было объявлено, что на тайваньской фабрике TSMC был размещен заказ на 13 тыс. Baikal-M, до конца 2020 г. там же будет заказана партия в 100 тыс. изделий, а в I квартале 2021 г. — еще не менее 100 тыс. штук. По текущей информации, с учетом крайнего дефицита мощностей у всех производителей полупроводников в мире, компания рассчитывает начать поставку чипов из первой партии в 130 тыс. штук в III квартале 2021 г. Следующие партии, большие по объему, ожидаются в 2022 г.
Тиражи подобного масштаба для «Байкал Электроникс» являются явным прорывом. Чипов Baikal-T за пять лет, прошедших с момента их разработки, было выпущено всего около 50 тыс. штук, а в отношении новых Baikal-M компания располагала лишь инженерными образцами из небольшой партии порядка 2 тыс. штук.
Более того, заказы сотен тысяч чипов можно считать и совершенно новым явлением для современной России. У главного конкурента «Байкалов» планы на выпуск его продукции, как выяснил CNews, в разы скромнее.
В 2021 г. «Эльбрусов» будет выпущено в 20 раз меньше, чем «Байкалов», но разработчики не считают это проигрышем
Разрабатывающая линейку отечественных процессоров «Эльбрус» компания МЦСТ собирается в 2021 г. заказать выпуск... // www.cnews.ruОтметим также, что публичные планы по разработке вышеупомянутых новых упрощенных чипов Baikal-M/2 и Baikal-M/2+ появились у «Байкал Электроникс» также после выхода на арену «Вартона». До этого анонсы своих новинок компания последний раз выпускала в январе 2016 г.
Бизнес-модель: равные условия для всех партнеров
Примечательно, что c появлением у «Байкал Электроникс» новых акционеров бизнес-модель производителя, по заверениям генерального директора Андрея Евдокимова, не претерпит серьезных изменений. Компания сохранит фокус на разработке чипов для вычислительной техники широкого спектра, а продуктовая линейка будет расширяться, ориентируясь на рыночный запрос. Он также отметил, что производством конечных устройств (компьютеров, моноблоков, ноутбуков и пр.) «Байкал Электроникс» заниматься не собирается.
«Перед командой сейчас стоит задача в короткий срок обеспечить совместимость процессоров Baikal со всеми основными элементами российского ИТ-ландшафта. Это подразумевает укрепление сотрудничества со всеми отечественными вендорами оборудования и ПО на равных условиях, развитие технологического партнерства в части интеграции продуктов и создания комплексных программно-аппаратных решений, в чем мы уже достигли немалых успехов», — подчеркнул Андрей Евдокимов.
Адаптация российских ОС
Доказательством справедливости приведенных выше слов Андрея Евдокимова могут служить комментарии конкурирующих друг с другом отечественных разработчиков ОС, которые активно ведут проекты по интеграции с Baikal-M.
В частности, в компании «Базальт СПО», разрабатывающей линейку ОС «Альт» в разговоре с CNews подчеркнули, что реализованная в Baikal-M ARM-платформа aarch64 — это одна из целевых архитектур для данной организации. Летом 2020 г. компания выпустила новый обобщенный ISO-образ операционной системы, который работает на Baikal-M, а осенью того же года вышел универсальный защищенный дистрибутив, недавно сертифицированный ФСТЭК.
В компании говорят, что плотно работают с «Байкал Электроникс» по формированию универсального ядра Linux, в котором реализована поддержка Baikal-M. «Байкал Электроникс» регулярно выпускает новые версии SDK (software development kit) — набор прошивок, обновляющих функциональность материнской платы; в этот набор включаются и обновления ядра Linux. Представители «Базальт СПО» заверяют, что на сегодняшний день ОС «Альт» работают на всех существующих платах с процессорами Baikal-M.
В этой связи в компании напоминают, что ее разработки, выполненные для поддержки aarch64, размещаются в открытом репозитории «Сизиф». Разработчики различных приложений могут использовать эти пакеты для создания своих продуктов, способных работать на устройствах с процессорами Baikal-M.
Представители «Ред Софт» — разработчика операционной системы «Ред ОС» на базе ПО с открытым кодом — заверили CNews, что считают Baikal-M с ОС этой компании на борту отличной базой для офисных машин начального уровня и информационных стендов. В «Ред Софт» отмечают, что с переходом «Ред ОС» на самое свежее ядро Linux 5.10 была актуализирована поддержка входящего в Baikal-M графического ускорителя Mali, что позволяет более комфортно работать с медиа-контентом, а также повысило отзывчивость графического интерфейса операционной системы. На данный момент под Baikal-M производится адаптация «Ред ОС» версии 7.3.
В дочерней компании «Ростелекома» — «Открытая мобильная платформа» (ОМП), которая занимается разработкой и внедрением первой российской мобильной ОС «Аврора», отметили в разговоре с CNews, что имеют опыт сотрудничества с «Байкал Электроникс» еще по линии Baikal-T — в рамках научно-исследовательской работы. Данное взаимодействие с появлением Baikal-M получило мощный импульс для дальнейшего развития, особенно с учетом опыта и экспертизы ОМП в поддержке ARM-архитектуры, наиболее распространенной на рынке мобильных устройств.
В ноябре 2019 г. было подписано соглашение о создании информационных киосков на базе отечественного производства, элементной базы и ОС «Аврора» между ОМП, «Байкал Электроникс» и научно-производственным предприятием «Итэлма». Такие киоски предназначены для использования в качестве инфоматов в МФЦ, префектурах, мэриях, в судебных учреждениях, в качестве инфоматов и терминалов саморегистрации в медицинских учреждениях, в качестве устройств для автоматической экзаменации в ГИБДД, а также в качестве терминалов самообслуживания в службах занятости.
В 2020 г. на индустриальных выставках были представлены первые результаты этого сотрудничества: инфокиоски на Baikal-M с защищенной ОС «Аврора» версии 3.2.1.
Что же касается Astra Linux, по словам генерального директора Ильи Сивцева, взаимодействие с «Байкал Электроникс» велось и ведется по двум направлениям: поддержка аппаратной платформы и развитие экосистемы ПО.
В части совместимости с аппаратной платформой обеспечена полноценная работа ОС Astra Linux на SOC Baikal-M, включая поддержку видеочипа Mali-T628, в том числе с использованием «свободных» видеодрайверов. В настоящее время основной задачей является обеспечение корректного функционирования Astra Linux на всех новых материнских платах российских производителей. В рамках проектных работ также решается вопрос оптимизации производительности и энергопотребления Astra Linux на отечественном вычислительном оборудовании.
В области развития экосистемы партнеры «Байкал Электроникс» успешно портировали на Astra Linux Special Edition, работающую на процессорах Baikal, офисный пакет «МойОфис», антивирус Dr.Web, «КриптоПро CSP», VipNet Client, VDI-клиент Termidesk, средство резервного копирования RuBackup, клиент видеоконференций TrueConf, платформу чат-ботов WorksPad и другие программные решения. Подтверждено стабильное и эффективное функционирование среды разработки и запуска Java — Liberica JDK, за счет чего многие российские компании смогут использовать свои приложения на java без внесения изменений в исходный код.
«В сотрудничестве с «Байкал Электроникс» мы провели комплексные исследования и смогли предоставить заказчикам на пилотные испытания готовые программно-аппаратные комплексы с процессором Baikal-M под управлением операционной системы Astra Linux в различных исполнениях: рабочая станция, терминальная станция и моноблок. Кроме того, нам удалось реализовать актуальные для потребителей практические сценарии применения ОС на российской вычислительной платформе. Мы всегда поддерживали отечественных разработчиков СВТ, но теперь это направление стало стратегическим, поэтому любое их изделие сразу же получает приоритет первого уровня на интеграцию со всем стеком продуктов ГК Astra Linux», — отмечает Илья Сивцев.
Базовое «железо»
Описание складывающейся вокруг Baikal-M хардверной инфраструктуры стоит начинать с материнских плат. В октябре 2020 г. Андрей Евдокимов из «Байкал Электроникс» отмечал, что на тот момент наибольшее распространение успели получить собственные платы компании в форм-факторе Mini-ITX, которые она производит по лицензии «Т-Платформ», а также изделия «Эдельвейс» и «Проект Лагранж».
Пионером на этом поле стал «Эдельвейс», презентовавший свою разработку в форм-факторе Mini-ITX в июле 2020 г. В компании указывают, что ее плата имеет компактный и унифицированный дизайн и может быть использована в составе любого десктопного решения совместимого с Mini-ITX.
В ходе подготовки данного обзора в «Эдельвейсе» отметили факт появления также и своей серверной платы E107, предназначенной для построения линейки серверов общего назначения начального уровня, платформ распределенных СХД в формате стоечных или блейд-серверов, а также продвинутых NAS-платформ.
«Проект Лагранж» выступает разработчиком процессорного модуля Lagrange Sarmah SoM в форм-факторе 70x70 мм с интегрированной оперативной памятью DDR4. Представители компании сообщили CNews, что в совокупности с ее интерфейсными платами (carrierboard) данное решение позволяет организации предложить покупателю целый модельный ряд материнских плат на Baikal-М: в формате Micro-ATX, Mini-ITX и Pico-ITX.
Серийные образцы как самих процессорных модулей «Лагранжа», так и материнских плат на их основе поступят в продажу в конце марта 2021 г. При этом компания бесплатно предоставляет инженерные образцы материнских плат с предустановленной ОС Альт Линукс во временное пользование для тестирования и оценки применимост
К настоящему моменту о разработках своих плат на Baikal-М CNews также рассказали в компаниях 3Logic Group, Aquarius и «Депо». В первой из них сообщили, что освоение серийного производства соответствующих изделий запланировано на лето 2021 г. А пока произведены инженерные образцы, которые представлены в демо-центре 3Logic.
В «Депо» отмечают, что этой компанией была разработана материнская плата для персональных устройств и однопроцессорная серверная материнская плата для серверов и СХД. При этом в компании заверили CNews, что ею уже разрабатывается двухпроцессорная серверная материнская плата для готовящегося к выходу Baikal-S. Она найдет применение в серверах и СХД «Депо», которые появятся в конце 2022 — начале 2023 гг.
Вычислительная техника
Пионером в производстве готовых технических решений на Baikal-М, возможно, также является «Эдельвейс». В конце августа 2020 г. компания сообщила о выпуске своего сенсорного моноблока на этом чипе под управлением ОС «Альт». Система поддерживает до 64 ГБ оперативной памяти типа DDR4.
Также в ассортименте «Эдельвейса» на Baikal-М представлены системный блок формата SFF, системный блок со встроенным источником бесперебойного питания и защитой от нарушений электроснабжения и линейка компьютеров в форм-факторе компактного десктопа для создания автоматизированных рабочих мест.
Моноблок «Эдельвейс» на процессоре Baikal-M
У «Проекта Лагранж» с использованием Baikal-М создан компактный неттоп размером чуть меньше жесткого диска 3,5 дюйма на основе материнской платы Lagrange Sarmah. Развитием данного изделия в компании называют блейд-сервер, позволяющий в одном серверном корпусе форм-фактора 3U разместить до 15 вычислительных машин на базе Baikal-M, а также сочетать их с компьютерами и ускорительным оборудованием на других архитектурах (x86/64 и FPGA) — для построения гетерогенного вычислителя. Кроме того, «Лагранжем» сейчас ведется разработка моноблока на базе Baikal-M и платы Lagrange Sarmah c диагональю экрана 27 дюймов.
У научно-технического центра 3Logic Group, который свое вычислительное оборудование выпускает под маркой «Гравитон», на Baikal-M помимо вышеупомянутых плат разработана линейка настольных моноблоков, двухконтурных моноблоков, настольных и малоформатных ПК. Серийное производство этого оборудования, как и плат, запланировано на лето 2021 г. Инженерные образцы техники также доступны в демо-центре 3Logic Group.
В «Депо» CNews рассказали, что компания на базе собственных плат уже разработала персональный компьютер в корпусе компактного настольного ПК, моноблочный компьютер и двухконтурный комплекс, объединяющий два физически изолированных ПК в одном корпусе моноблока. Образцы данных устройств станут доступны для заказа в рамках программы тестирования в июле-сентябре 2021 г.
На серверном направлении «Депо» на своих платах разработала универсальный сервер начального уровня с производительностью 100 ГФлопс, одноконтроллерные СХД на 8-12 накопителей и отказоустойчивую двухконтроллерную СХД на 24 накопителя. Образцы серверов уже доступны к заказу, образцы СХД появятся в июле 2021 г.
В серийное производство упомянутые данные модели будут запущены во II-III кварталах 2021 г. Сейчас «Депо» работает над получением заключений Минпромторга о подтверждении производства указанных моделей на территории России.
Примечательно, что «Депо» уже приступила к разработке линейки тонких клиентов и ноутбуков на базе разрабатываемых в данный момент «Байкал Электроникс» мобильных процессоров Baikal-М/2 и Baikal-М/2+.
В «Аквариус» сообщили CNews, что на 2021 г. в компании намечен выпуск на Baikal-М нескольких клиентских устройств и серверов. В 2022-2024 гг. компания планирует расширение ряда клиентских устройств (ПК, моноблоки, ноутбуки, тонкие клиенты), одно- и двухсокетных серверов и СХД — на базе как Baikal-М, так и Baikal-S.
Прикладное ПО
На четвертом, по определению самом обширном, уровне экосистемы Baikal-М «Байкал Электроникс», по заверению Андрея Евдокимова, взаимодействует с очень широким кругом отечественных разработчиков. В их числе «Лаборатория Касперского», «Доктор Веб», создатели продуктов «Мой офис» и «Р7-офис», TrueConf, Termidesk, «Тионикс» и др.
Причем количество и качество этих связей растет буквально на глазах. Например, сообщение разработчиков российского офисного пакета «Мой офис» о совместимости его настольных редакторов с аппаратной платформой Baikal-M было опубликовано буквально во время подготовки CNews данного обзора.
«Сейчас наши основные усилия сосредоточены именно на развитии экосистемы ПО вокруг процессоров «Байкал», что очень важно для удовлетворения потребностей конечных пользователей вычислительной техники. К счастью, мы делаем это далеко не в одиночестве, уже десятки российских компаний-разработчиков убедились в перспективности данного направления, поверили в него и выпустили релизы совместимости своих продуктов с «Байкалами». Все вместе мы делаем очень большую работу и до конца текущего года ожидаем дальнейшее серьезное расширение экосистемы Baikal, особенно в области прикладного ПО», — отмечает Андрей Евдокимов.
Прямая речь
В заключении этого обзора (на абсолютную полноту он не претендует; CNews удалось пообщаться далеко не со всеми представителями экосистемы Baikal-M) приведем высказывания топ-менеджеров опрошенных партнеров «Байкал Электроникс» относительно первого ARM-процессора этой компании.
«Baikal-M зарекомендовал себя как современное решение отечественной электроники, которое отвечает высочайшим мировым стандартам, при этом являясь одним из самых экономически привлекательных», — отмечает Алексей Коган, директор по стратегическому развитию компании «Открытая мобильная платформа».
«Baikal-M — это разработка достойного уровня, — говорит Сергей Белкин, вице-президент «Аквариус», руководитель технической дирекции. — «Байкал Электроникс» вносит значимый вклад в развитие отечественной микроэлектроники. Применение распространенных архитектур, таких как AArch64, имеющих обширную экосистему, позволяет упростить построение прикладных решений и миграцию; это преимущество. Недостатки тоже есть, но они по большей части временные и связаны с тиражностью и ценой».
«Мы рады, что нам одним из первых удалось реализовать потенциал процессора Baikal-M для создания функциональных и безопасных рабочих мест, — сказал Александр Грищенков, гендиректор «Эдельвейса». — Пилотные проекты продемонстрировали высокий уровень интереса к нашим решениям, и мы готовим к выпуску новую линейку устройств в ближайшее время».
«Возможности Baikal-M позволяют создавать конкурентоспособные отечественные вычислительные системы, которые будут востребованы государственными и корпоративными заказчиками», — поделился своим мнением Антон Лебединец, директор по продукции научно-технического центра 3Logic Group.
«Перспективы процессоров ARM на всем спектре оборудования сегодня не вызывают сомнений, — рассуждает Евгений Синельников, руководитель саратовского подразделения «Базальт СПО». — Главная проблема разработки ОС, особенно с современными требованиями к безопасности, — стандартизация, отход от стиля разработки для встроенных устройств, когда для каждого из них выпускаются свое ядро и привязанный к нему загрузчик. Только когда пользователь сможет использовать любую ОС для ARM64 для любого устройства на этой архитектуре, мы достигнем действительно ценного для наших клиентов результата. Замечу, что это не только российская, но и общая международная проблема. Надеюсь, что мы будем ее решать совместно с «Байкал Электроникс» и другими разработчиками и производителями аппаратных средств».
«Мы как разработчики отечественных материнских плат такой процессор ждали, — заверяет Александр Корнев, гендиректор «Проекта Лагранж». — Для нас значение имеет как быстродействие, позволяющее построить полноценный ПК, так и доступность документации, и техническая поддержка для обеспечения возможности спроектировать собственную материнскую плату. Все это мы получили в новом процессоре. Производительность Baikal-М даже превзошла наши ожидания. Мы развернули в лаборатории экспериментальное рабочее место разработчика прикладного ПО на компьютере с нашей материнской платой Lagrange Sarmah. Работа на нем оставляет приятное впечатление: полноценное разрешение экрана, быстрая компиляция приложений в среде QtCreator, хорошая скорость отклика в пакете офисных программ. Мы считаем, что Baikal-M имеет все шансы стать по-настоящему массовым и доступным для широкого круга потребителей».
«Важно, с нашей точки зрения, что производитель процессора развернут лицом к рынку и нацелен на массовость применения, а не замыкается на производстве собственных ПК, — добавляет Роман Жарких, технический директор «Проекта Лагранж». — Такой подход многих ведущих зарубежных производителей позволил им увеличить тиражи своих чипов до огромных масштабов. А где большие тиражи, там и качество выше, и цена ниже. При таком подходе производитель, однако, вынужден поддерживать разработчиков открытыми сопроводительными материалами: референс-дизайнами, открытыми дистрибутивами, форумами по обмену опытом — тем, что формирует инженерное сообщество. При такой поддержке решение разработчика о переходе на Baikal-М станет частым явлением, а скорость выхода новых разработок на рынок значительно увеличится».
«Мы крайне позитивно оцениваем появление еще одного отечественного чипа, который может применяться в тонких клиентах и рабочих станциях начального уровня, — говорит Петр Щеглов, заместитель директора по продуктам «Мой офис». — Процессор Baikal-M хорошо подходит для создания существенно более надежных с точки зрения информационной безопасности решений за счет особенностей дизайна чипа. «Мой офис» ожидает дальнейшего развития линейки продуктов «Байкал Электроникс» и появления более мощных чипов Baikal, которые позволят решать еще больше задач на этой платформе».
Татарин
yacc> Ужасного - ничего.
Тогда в чём проблема-то?
Татарин>> С того, что все эти платежи - в стоимости станции, которая сама себя окупает, как нормальный коммерческий проект.
yacc> А ничего что сроки несколько раз срывались и проект подорожал?
Ничего. Каждая станция сама по себе - коммерческий проект, окупающийся. А техннологии подсмотренные (или прямо переданные в процессе заказа у местных подрядчиков, Китай же очень жёстко везде ставил вопросы о субподряде) - это бесплатно. То есть, это всё как пример того, что китайцам в девяностые-нулевые было чему поучиться в ядерной области - да, прекрасно. Но оно же - пример того, как именно и насколько быстро китайцы учатся. То есть, если вернуться к чему начали, не в твою пользу пример-то, по сути.
yacc> У Китая просто "солянка" атомных технологий с разных мест которые как-то надо стыковать
Не надо.
"Солянка" появилась вполне сознательно: собрать весь опыт человечества на своей территории, чтобы посмотреть, куда двигаться. Собрали. Посмотрели. Сделали "Хуалонг-1".
yacc> Например "Росатом" технологий особо и не передает ( и это понятно почему )
К сожалению (или к счастью - как посмотреть на такие сделки), передаёт вовсю. И, в общем-то, всё реально интересное китайцам им уже передали, совсем вот недавно помогали с CEFR, передав хитрости изготовления ключевого элемента БН - натриевого теплообменника. Ессно, что там ещё масса грабель, на которые китайцы должны наступить самостоятельно (и они наступают), но, скажем, от помощи в пусконаладке CЕFR они отказались. То есть вот "Росатом" предлагал, а они отказались.
yacc> yacc>> Быстро будет когда введут первый энергоблок, а пока это только проект.
Татарин>> В среднем 5-6 лет на привязку к площадке и строительство. Ждать недолго.
yacc> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
yacc> Прикинь, а банковский процессинг даже у нас делают на IBM
Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
Татарин>> Процессор 10-летней давности замечательно работали на СУБД.
yacc> Гораздо меньшего объема. Если оценить что данные в 1.5 раза увеличиваются каждый год, то за 10 лет они увеличились почти в 60 раз.
(устало) Ну какая разница-то?
Банковские системы - вообще не самые нагруженные. Есть (и были) системы с нагрузкой в десятки-сотни, а то и тысячи (насчёт тысяч в России уже не уверен, но предполагаю) раз больше. В любой момент времени.
Татарин>> А при чём тут ассемблер-то?!
yacc> Он максимально позволяет тебе использовать ресурсы железа. Но можешь и на С в общем-то
Это было лет 15-20 назад, что ли...
На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек). И скорее всего, те, кто может написать лучше (если такие есть), выиграют копейки. Исключение - применение векторных операций в очень особых случаях (потому что на не особые есть библиотеки и даже инлайн-макросы).
Это не времена 8086.
Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять. Да, та (в теории! не на практике) ты можешь обложиться справочниками и выдать столь же хороший код, но у тебя уйдёт в миллиарды больше времени на получение того же результата, а в большинстве случаев ты чего-то не учтёшь и твой код будет тупо хуже.
Так даже и более того: когда мы гоняли внутрение тесты наших чисто вычислительных задач, выяснилось, что нативный С++ код даёт в среднем всего 15-20% (и только на отдельных задачах 25-30%) выигрыш по сравнению с манагед c#. Ну блин, ну и за что тут воевать-то, вот в принципе? А на реальных задачах тебя затыкает память, затыкает долговременная память без кешей (а хоть бы и с ними), затыкает тупо вот производительность сети. В результате вдвое быстрый процессор даёт выигрыш 5-10%.
Ещё раз: на дворе не 90-е, когда процессор реально определял производительность.
yacc> Наивно полагать что оптимизирующий компилятор делает это лучше человека - он разве что рутину снимает.
Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
yacc> И напомню, что современные языки со средой исполнения тратят лишнее время на эту среду исполнения - типа питона или JVM, хотя лет 15 назад тоже самое на С или С++ работало просто без лишних накладных расходов.
Да, тратят. И что?
yacc> Параллелизм в том же SQL ограничен или как это называют горизонтальное масштабирование. Это в NoSQL это легко, но там есть проблемы с целостностью.
Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
В конце-то концов, см. как банковские задачи решались, когда доступные вычмощности были в миллионы-миллиарды раз меньше. Собссно, они и сейчас так же примерно и решаются.
Татарин>> Или вот почему "65нм не уже катит"?
yacc> Потому что объем данных возрос на пару порядков. Я же не отрицаю, что с объемами 10 летней давности они бы справились ? Но тебе нужно обрабатывать именно современный объем.
Ставлю кластера, способные справиться с современным объёмом. Только и всего.
Татарин>> Серьёзные вещи вообще пишутся с изначальной возможностью масштабирования.
yacc> А кто тебе сказал что то, что уже понаписали, писали серьезно с возможностью горизонтального масштабирования а не на уровне индусов ?
Если это так, оно давно уже заткнулось, и это тем более неважно.
Скорость процессоров в последние 10 лет растёт гораздо медленнее, чем объёмы обработки.
Сравни Sandy Bridge (2011) c Tiger Lake (2021) - разница в производительности в 60 раз? Ты смеёшься?
Тогда в чём проблема-то?
Татарин>> С того, что все эти платежи - в стоимости станции, которая сама себя окупает, как нормальный коммерческий проект.
yacc> А ничего что сроки несколько раз срывались и проект подорожал?
Ничего. Каждая станция сама по себе - коммерческий проект, окупающийся. А техннологии подсмотренные (или прямо переданные в процессе заказа у местных подрядчиков, Китай же очень жёстко везде ставил вопросы о субподряде) - это бесплатно. То есть, это всё как пример того, что китайцам в девяностые-нулевые было чему поучиться в ядерной области - да, прекрасно. Но оно же - пример того, как именно и насколько быстро китайцы учатся. То есть, если вернуться к чему начали, не в твою пользу пример-то, по сути.
yacc> У Китая просто "солянка" атомных технологий с разных мест которые как-то надо стыковать
Не надо.
"Солянка" появилась вполне сознательно: собрать весь опыт человечества на своей территории, чтобы посмотреть, куда двигаться. Собрали. Посмотрели. Сделали "Хуалонг-1".yacc> Например "Росатом" технологий особо и не передает ( и это понятно почему )
К сожалению (или к счастью - как посмотреть на такие сделки), передаёт вовсю. И, в общем-то, всё реально интересное китайцам им уже передали, совсем вот недавно помогали с CEFR, передав хитрости изготовления ключевого элемента БН - натриевого теплообменника. Ессно, что там ещё масса грабель, на которые китайцы должны наступить самостоятельно (и они наступают), но, скажем, от помощи в пусконаладке CЕFR они отказались. То есть вот "Росатом" предлагал, а они отказались.
yacc> yacc>> Быстро будет когда введут первый энергоблок, а пока это только проект.
Татарин>> В среднем 5-6 лет на привязку к площадке и строительство. Ждать недолго.
yacc> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
yacc> Прикинь, а банковский процессинг даже у нас делают на IBM
Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
Татарин>> Процессор 10-летней давности замечательно работали на СУБД.
yacc> Гораздо меньшего объема. Если оценить что данные в 1.5 раза увеличиваются каждый год, то за 10 лет они увеличились почти в 60 раз.
(устало) Ну какая разница-то?
Банковские системы - вообще не самые нагруженные. Есть (и были) системы с нагрузкой в десятки-сотни, а то и тысячи (насчёт тысяч в России уже не уверен, но предполагаю) раз больше. В любой момент времени.
Татарин>> А при чём тут ассемблер-то?!
yacc> Он максимально позволяет тебе использовать ресурсы железа. Но можешь и на С в общем-то
Это было лет 15-20 назад, что ли...
На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек). И скорее всего, те, кто может написать лучше (если такие есть), выиграют копейки. Исключение - применение векторных операций в очень особых случаях (потому что на не особые есть библиотеки и даже инлайн-макросы).
Это не времена 8086.
Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять. Да, та (в теории! не на практике) ты можешь обложиться справочниками и выдать столь же хороший код, но у тебя уйдёт в миллиарды больше времени на получение того же результата, а в большинстве случаев ты чего-то не учтёшь и твой код будет тупо хуже.
Так даже и более того: когда мы гоняли внутрение тесты наших чисто вычислительных задач, выяснилось, что нативный С++ код даёт в среднем всего 15-20% (и только на отдельных задачах 25-30%) выигрыш по сравнению с манагед c#. Ну блин, ну и за что тут воевать-то, вот в принципе? А на реальных задачах тебя затыкает память, затыкает долговременная память без кешей (а хоть бы и с ними), затыкает тупо вот производительность сети. В результате вдвое быстрый процессор даёт выигрыш 5-10%.
Ещё раз: на дворе не 90-е, когда процессор реально определял производительность.
yacc> Наивно полагать что оптимизирующий компилятор делает это лучше человека - он разве что рутину снимает.
Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
yacc> И напомню, что современные языки со средой исполнения тратят лишнее время на эту среду исполнения - типа питона или JVM, хотя лет 15 назад тоже самое на С или С++ работало просто без лишних накладных расходов.
Да, тратят. И что?
yacc> Параллелизм в том же SQL ограничен или как это называют горизонтальное масштабирование. Это в NoSQL это легко, но там есть проблемы с целостностью.
Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
В конце-то концов, см. как банковские задачи решались, когда доступные вычмощности были в миллионы-миллиарды раз меньше. Собссно, они и сейчас так же примерно и решаются.
Татарин>> Или вот почему "65нм не уже катит"?
yacc> Потому что объем данных возрос на пару порядков. Я же не отрицаю, что с объемами 10 летней давности они бы справились ?
Но тебе нужно обрабатывать именно современный объем.Ставлю кластера, способные справиться с современным объёмом. Только и всего.
Татарин>> Серьёзные вещи вообще пишутся с изначальной возможностью масштабирования.
yacc> А кто тебе сказал что то, что уже понаписали, писали серьезно с возможностью горизонтального масштабирования а не на уровне индусов ?
Если это так, оно давно уже заткнулось, и это тем более неважно.
Скорость процессоров в последние 10 лет растёт гораздо медленнее, чем объёмы обработки.
Сравни Sandy Bridge (2011) c Tiger Lake (2021) - разница в производительности в 60 раз? Ты смеёшься?
yacc>> Ужасного - ничего.
Татарин> Тогда в чём проблема-то?
Ты не поверишь, но скажем на Украине тоже не ужасно. Хуже, но не ужасно.
Татарин> Ничего. Каждая станция сама по себе - коммерческий проект, окупающийся. А техннологии подсмотренные (или прямо переданные в процессе заказа у местных подрядчиков, Китай же очень жёстко везде ставил вопросы о субподряде) - это бесплатно.
Ты точно статью читал ? Там про корпус из Южной Кореи, про ГЦН...
Татарин> Не надо. "Солянка" появилась вполне сознательно: собрать весь опыт человечества на своей территории, чтобы посмотреть, куда двигаться.
Солянка собралась по принципу "кто что может дать и кто на это согласится" .
Татарин> К сожалению (или к счастью - как посмотреть на такие сделки), передаёт вовсю. И, в общем-то, всё реально интересное китайцам им уже передали, совсем вот недавно помогали с CEFR, передав хитрости изготовления ключевого элемента БН - натриевого теплообменника.
Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
yacc>> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Татарин> Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
Т.е. считай что и полгода нет
Татарин> Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
Это типа такого ?
Татарин> Банковские системы - вообще не самые нагруженные.
За банками сейчас и ФНС приглядывает в РФ. Плюс банки разные сервисы вводят.
Татарин> На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек).
Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Татарин> Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять.
Не будет у тебя интеловского компилятора.
Татарин> Так даже и более того: когда мы гоняли внутрение тесты наших чисто вычислительных задач, выяснилось, что нативный С++ код даёт в среднем всего 15-20% (и только на отдельных задачах 25-30%) выигрыш по сравнению с манагед c#.
Не будет у тебя C# - будет Java на Линуксе.
Татарин> Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
Сейчас просто берут Apache Kafka если надо перетащить данные. А это Java. Плюс ее еще и в докере запускают. Правильный код на С будет явно быстрее, если чистая Java на двоичных деревьях раза в три проигрывает gcc
yacc>> Параллелизм в том же SQL ограничен или как это называют горизонтальное масштабирование. Это в NoSQL это легко, но там есть проблемы с целостностью.
Татарин> Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
А если у тебя несколько баз - у тебя нет целостности. И да - к базе ты можешь ходить сотней нитей ( те же микросервисы ) даже через кэши коннекций. Кстати у Постргре для энтерпрайза тоже тут зытык - на коннекцию она процесс создает, а не нить.
Татарин> Ставлю кластера, способные справиться с современным объёмом. Только и всего.
См. выше.
Татарин> Скорость процессоров в последние 10 лет растёт гораздо медленнее, чем объёмы обработки.
Татарин> Сравни Sandy Bridge (2011) c Tiger Lake (2021) - разница в производительности в 60 раз? Ты смеёшься?
Не не не - ты бери Cedar Mill ( 65 нм ) и сравни его хотя бы с haswell ( 22 нм )
Немного добавлю
Смотрим на бенчмарки Java.
Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Поэтому неудивительно что ПФР уже пять лет его внедряет...
Кажется ты говорил что можно жить и на 65нм ?
Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
13 процессоров ставить будешь и гемороиться с синхронизацией ?
Татарин> Тогда в чём проблема-то?
Ты не поверишь, но скажем на Украине тоже не ужасно. Хуже, но не ужасно.
Татарин> Ничего. Каждая станция сама по себе - коммерческий проект, окупающийся. А техннологии подсмотренные (или прямо переданные в процессе заказа у местных подрядчиков, Китай же очень жёстко везде ставил вопросы о субподряде) - это бесплатно.
Ты точно статью читал ? Там про корпус из Южной Кореи, про ГЦН...
Татарин> Не надо.
"Солянка" появилась вполне сознательно: собрать весь опыт человечества на своей территории, чтобы посмотреть, куда двигаться.Солянка собралась по принципу "кто что может дать и кто на это согласится" .
Татарин> К сожалению (или к счастью - как посмотреть на такие сделки), передаёт вовсю. И, в общем-то, всё реально интересное китайцам им уже передали, совсем вот недавно помогали с CEFR, передав хитрости изготовления ключевого элемента БН - натриевого теплообменника.
Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
yacc>> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Татарин> Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
Т.е. считай что и полгода нет
Татарин> Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
Это типа такого ?
Пенсионный фонд продолжает миграцию на процессоры «Эльбрус». Работы идут четыре года
С 2016 года Пенсионный фонд РФ пытается перенести программное обеспечение с серверов IBM iSeries под управлением СУБД IBM DB2 на ОС «Эльбрус», СУБД PostgreSQL с... // habr.comТатарин> Банковские системы - вообще не самые нагруженные.
За банками сейчас и ФНС приглядывает в РФ. Плюс банки разные сервисы вводят.
Татарин> На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек).
Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Татарин> Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять.
Не будет у тебя интеловского компилятора.
Татарин> Так даже и более того: когда мы гоняли внутрение тесты наших чисто вычислительных задач, выяснилось, что нативный С++ код даёт в среднем всего 15-20% (и только на отдельных задачах 25-30%) выигрыш по сравнению с манагед c#.
Не будет у тебя C# - будет Java на Линуксе.
Татарин> Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
Сейчас просто берут Apache Kafka если надо перетащить данные. А это Java. Плюс ее еще и в докере запускают. Правильный код на С будет явно быстрее, если чистая Java на двоичных деревьях раза в три проигрывает gcc
yacc>> Параллелизм в том же SQL ограничен или как это называют горизонтальное масштабирование. Это в NoSQL это легко, но там есть проблемы с целостностью.
Татарин> Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
А если у тебя несколько баз - у тебя нет целостности. И да - к базе ты можешь ходить сотней нитей ( те же микросервисы ) даже через кэши коннекций. Кстати у Постргре для энтерпрайза тоже тут зытык - на коннекцию она процесс создает, а не нить.
Татарин> Ставлю кластера, способные справиться с современным объёмом. Только и всего.
См. выше.
Татарин> Скорость процессоров в последние 10 лет растёт гораздо медленнее, чем объёмы обработки.
Татарин> Сравни Sandy Bridge (2011) c Tiger Lake (2021) - разница в производительности в 60 раз? Ты смеёшься?
Не не не - ты бери Cedar Mill ( 65 нм ) и сравни его хотя бы с haswell ( 22 нм )
Немного добавлю
Новогодние бенчмарки компьютеров Эльбрус
Новогодние бенчмарки компьютеров Эльбрус Продолжение статьи Большое тестирование процессоров различных архитектур. В этот раз я решил измерить производительност... // habr.comСмотрим на бенчмарки Java.
Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Поэтому неудивительно что ПФР уже пять лет его внедряет...
Кажется ты говорил что можно жить и на 65нм ?
Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
13 процессоров ставить будешь и гемороиться с синхронизацией ?
Это сообщение редактировалось 29.04.2021 в 21:54
U235>> Ну тогда ты точно упадешь со стула узнав что значительная часть современных сервисов на процессорах 10 летней давности крутится. Сервера - штука дорогая и их так часто не меняют.
yacc> Это если это IBM
Воу воу, полехче
У клиентов до сих пор SUN сервера пашут (дада, ещё не Оракл), и супердома рисковые...
А по производительности, ну вот банальный саповский бенчмарк:
IBM p780 - 64 ядра, 512 (!) ГБ оперативы - на ядро - 22995 SAPS (2013 год,есичо)
Гугловая железяка с 16 интелами (448 ядер, 25(!!!)ТБ оперативы - на ядро - 1991 SAPS (2021 год)
И, кстати, тот же оракл вполне себе с поверов и тп на интелы переносят.
yacc> Это если это IBM
Воу воу, полехче
У клиентов до сих пор SUN сервера пашут (дада, ещё не Оракл), и супердома рисковые...
А по производительности, ну вот банальный саповский бенчмарк:
IBM p780 - 64 ядра, 512 (!) ГБ оперативы - на ядро - 22995 SAPS (2013 год,есичо)
Гугловая железяка с 16 интелами (448 ядер, 25(!!!)ТБ оперативы - на ядро - 1991 SAPS (2021 год)
И, кстати, тот же оракл вполне себе с поверов и тп на интелы переносят.
U235>>> Ну тогда ты точно упадешь со стула узнав что значительная часть современных сервисов на процессорах 10 летней давности крутится. Сервера - штука дорогая и их так часто не меняют.
ну всё таки стандартный срок жизни сервера - 5 лет. понятно конечно что заказчик старается закупать знакомую модель пока она выпускается...но в какой-то момент вендор начинает говорить "вы знаете, это ваше староег..номузейное железо...у нас уже совсем нет на него запчастей , ни за какие деньги ...ВСЁ закопайте".
допустим купили 5 лет назад старую проверенную модель в конце выпуска с проверенным уже заслуженным железом - вот ~10 лет и получится от выхода железа.
yacc>> Это если это IBM
downpour> Воу воу, полехче
downpour> У клиентов до сих пор SUN сервера пашут (дада, ещё не Оракл), и супердома рисковые...
downpour> А по производительности, ну вот банальный саповский бенчмарк:
downpour> IBM p780 - 64 ядра, 512 (!) ГБ оперативы - на ядро - 22995 SAPS (2013 год,есичо)
downpour> Гугловая железяка с 16 интелами (448 ядер, 25(!!!)ТБ оперативы - на ядро - 1991 SAPS (2021 год)
downpour> И, кстати, тот же оракл вполне себе с поверов и тп на интелы переносят.
ну да, для меня было сюрпризом что после переезда хранилищ оракловых с HP-UX (но на пожилых уже конечно на тот момент) на шапку на пролианте с ораклом опять же..насколько оно стало быстрее работать при том что железо ну сильно дешевле и в закупке и саппорте.
ну всё таки стандартный срок жизни сервера - 5 лет. понятно конечно что заказчик старается закупать знакомую модель пока она выпускается...но в какой-то момент вендор начинает говорить "вы знаете, это ваше старое
допустим купили 5 лет назад старую проверенную модель в конце выпуска с проверенным уже заслуженным железом - вот ~10 лет и получится от выхода железа.
yacc>> Это если это IBM
downpour> Воу воу, полехче
downpour> У клиентов до сих пор SUN сервера пашут (дада, ещё не Оракл), и супердома рисковые...
downpour> А по производительности, ну вот банальный саповский бенчмарк:
downpour> IBM p780 - 64 ядра, 512 (!) ГБ оперативы - на ядро - 22995 SAPS (2013 год,есичо)
downpour> Гугловая железяка с 16 интелами (448 ядер, 25(!!!)ТБ оперативы - на ядро - 1991 SAPS (2021 год)
downpour> И, кстати, тот же оракл вполне себе с поверов и тп на интелы переносят.
ну да, для меня было сюрпризом что после переезда хранилищ оракловых с HP-UX (но на пожилых уже конечно на тот момент) на шапку на пролианте с ораклом опять же..насколько оно стало быстрее работать при том что железо ну сильно дешевле и в закупке и саппорте.
yacc> Смотрим на бенчмарки Java.
yacc> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
yacc> Поэтому неудивительно что ПФР уже пять лет его внедряет...
интересная тема. может кто в курсе что там в этом ПФР происходит и какой там уровень квалификации специалистов .
уж за 5 лет можно было выполнить проект если железо норм и команда грамотная.
yacc> Кажется ты говорил что можно жить и на 65нм ?
yacc> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
yacc> 13 процессоров ставить будешь и гемороиться с синхронизацией ?
задача ускорить работу на порядок она в лоб сложно решатся. нужно переходить на загрузку миробатчами, инкрментальный расчёт, замораживать основной массив данных снижая глубину пересчёта, денормализовывать модель данных, какой-то предрасчёт на стороне источника делать, инстанциировать...в общем начинать серёзно подходить к хранилищу.
опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
yacc> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
yacc> Поэтому неудивительно что ПФР уже пять лет его внедряет...
интересная тема. может кто в курсе что там в этом ПФР происходит и какой там уровень квалификации специалистов .
уж за 5 лет можно было выполнить проект если железо норм и команда грамотная.
yacc> Кажется ты говорил что можно жить и на 65нм ?
yacc> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
yacc> 13 процессоров ставить будешь и гемороиться с синхронизацией ?
задача ускорить работу на порядок она в лоб сложно решатся. нужно переходить на загрузку миробатчами, инкрментальный расчёт, замораживать основной массив данных снижая глубину пересчёта, денормализовывать модель данных, какой-то предрасчёт на стороне источника делать, инстанциировать...в общем начинать серёзно подходить к хранилищу.
опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
с.т.> уж за 5 лет можно было выполнить проект если железо норм и команда грамотная.
Так железо же даунгрейженое
Там в ссылке есть ссылка на старую статью, когда народ сделал пилот на Эльбрусе и получил от 2 до 70 раз медленнее..
с.т.> опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
Т.е. считай тебе надо менять архитектуру которая работает да еще с регресс тестированием
Это как бы не быстро.
Посему обычный вопрос в таком деле - мы будем ее херачить или тупо закупим более быстрое железо
Так железо же даунгрейженое
Там в ссылке есть ссылка на старую статью, когда народ сделал пилот на Эльбрусе и получил от 2 до 70 раз медленнее..
с.т.> опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
Т.е. считай тебе надо менять архитектуру которая работает да еще с регресс тестированием
Это как бы не быстро.
Посему обычный вопрос в таком деле - мы будем ее херачить или тупо закупим более быстрое железо
с.т.>> уж за 5 лет можно было выполнить проект если железо норм и команда грамотная.
yacc> Так железо же даунгрейженое
yacc> Там в ссылке есть ссылка на старую статью, когда народ сделал пилот на Эльбрусе и получил от 2 до 70 раз медленнее..
а какое у них сейчас железо, топовое?
откуда у ПФР громадные объёмы данных?
там ~140 млн пенсионных счетов на которых раз ну в месяц что-то происходит.
с.т.>> опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
yacc> Т.е. считай тебе надо менять архитектуру которая работает да еще с регресс тестированием
само собой.
я уж молчу что регресс тестирование должно так и так хотя бы раз в месяц выполняться на UAT среде.
( а лучше раз в две недели на выходных согласно релизного цикла, если спринты двухнедельные)
yacc> Это как бы не быстро.
yacc> Посему обычный вопрос в таком деле - мы будем ее херачить или тупо закупим более быстрое железо
это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
yacc> Так железо же даунгрейженое
yacc> Там в ссылке есть ссылка на старую статью, когда народ сделал пилот на Эльбрусе и получил от 2 до 70 раз медленнее..
а какое у них сейчас железо, топовое?
откуда у ПФР громадные объёмы данных?
там ~140 млн пенсионных счетов на которых раз ну в месяц что-то происходит.
с.т.>> опять же погружаться в глубины глубин алгоритмов и ресурсоёмких процедур расчёта, смотреть что самое жирное и что можно распараллелить.
yacc> Т.е. считай тебе надо менять архитектуру которая работает да еще с регресс тестированием
само собой.
я уж молчу что регресс тестирование должно так и так хотя бы раз в месяц выполняться на UAT среде.
( а лучше раз в две недели на выходных согласно релизного цикла, если спринты двухнедельные)
yacc> Это как бы не быстро.
yacc> Посему обычный вопрос в таком деле - мы будем ее херачить или тупо закупим более быстрое железо
это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
Татарин
yacc>>> Ужасного - ничего.
Татарин>> Тогда в чём проблема-то?
yacc> Ты не поверишь, но скажем на Украине тоже не ужасно. Хуже, но не ужасно.
Ессно, не поверю. Украина не может развиваться, а страна с процессорами на 40нм - вот запросто.
yacc> Солянка собралась по принципу "кто что может дать и кто на это согласится" .
Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
yacc> Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
У тебя мысль... При чём тут тот факт, что и "Росатом", и другие конторы считают за счастье продавать Китаю технологии? И продавали. И продают - только Китаю брать больше нечего.
Даже БН-800 - вполне рентабельный и окупается. То, что он по экономике хуже, чем ВВЭР - вполне ожидаемо (на бумажном этапе было прописано), сейчас есть проект БН-1200, который по экономике лучше ВВЭР. Всё развивается, и китайцам тоже нужно с чего-то начинать.
yacc> yacc>> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Татарин>> Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
yacc> Т.е. считай что и полгода нет
Полгода нет чего?
Посмотри, когда был пущен последний АР-1000, посмотри, когда их начинали строить (и когда китайцы собрали достаточно знаний для запуска своего "лицензионно чистого" (угу) проекта). И сравни с датой начала строительства и запуска "Хуалонга".
Татарин>> Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
yacc> Это типа такого ?
Ну да, в том числе. И?
И, кстати, ты статейки-то с "хабра" дели где-то на 50.
Татарин>> Банковские системы - вообще не самые нагруженные.
yacc> За банками сейчас и ФНС приглядывает в РФ. Плюс банки разные сервисы вводят.
Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
Татарин>> На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек).
yacc> Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Во-первых, опять прыжок мысли с тезиса "на ассемблере быстрее" (а если компьютер с принтером - то ещё быстрее!) на непонятно куда.
Во-вторых, блин. Блин.
Ну нифига не понимаешь ты о чём говоришь. Ну вот нифига.
"Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
Татарин>> Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять.
yacc> Не будет у тебя интеловского компилятора.
Так а нафига он? не под интеловский проц-то?
yacc> Не будет у тебя C# - будет Java на Линуксе.
1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима, а про разницу С с ассемблером я уже сказал, там она может быть запросто и в обратную сторону.
Ну не пробовали мы Яву и никогда её не рассматривали. Только поэтому сравнил с С#, были бы данные по Яве - привёл бы их. Впрочем, чужие тесты говорят, что там того же порядка числа.
Татарин>> Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
yacc> Сейчас просто берут Apache Kafka если надо перетащить данные. А это Java. Плюс ее еще и в докере запускают. Правильный код на С будет явно быстрее, если чистая Java на двоичных деревьях раза в три проигрывает gcc
Во-первых, Вы её просто готовить не умеете (да, внезапно, над енвироментом для Явы тоже нужно посидеть; например, для того же докера маскимальный хип сайз оставляют на дефолте, а это сразу ява-машине как серпом по яйцам). Во-вторых, ты, кажется, не понимаешь, что ты только что сказал.
А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
Татарин>> Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
yacc> А если у тебя несколько баз - у тебя нет целостности.
Есть, всё есть. Ещё раз: на это есть архитектурные решения, на уровне бизнес-логики даже.
Ну вот когда и кем по-твоему придуманы клиринговые операции?
Вот с тех самых пор, когда процессинг операций производился тётками с ручками и бумажками (и лишь иногда с арифмометрами) со средней скоростью процессинга примерно 1 операция в минуту, эти проблемы параллелизации транзакций и сверки данных были решены.
И да, сейчас они тоже решены.
И да, если где-то в этой сфере они НЕ решены - то это не проблема "недостаточно быстрых процессоров", а слишком тупых программистов, и только.
Ещё раз: весь мир работал с банками, когда производительность "процессоров" была меньше где-то в триллион раз. Триллион. Не 10. И транзакций тогда (ещё в 50-60-е годы) проходило всего в тысячи-миллионы раз меньше, чем сегодня.
Реально есть процессы, которые можно выполнять только последовательно (вычислять число "пи", к примеру), и там критически важна производительность отдельного процессора. Но я не знаю бизнес-задач из реального мира, которые имели бы подобные критичные проблемы.
Татарин>> Ставлю кластера, способные справиться с современным объёмом. Только и всего.
yacc> См. выше.
И?
yacc> Не не не - ты бери Cedar Mill ( 65 нм ) и сравни его хотя бы с haswell ( 22 нм )
И что будет?
yacc> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Потому что запустили тесты не НЕ родной (не в нейтив-коде) Ява-машине (она сделана относительно недавно), в режиме эмуляции. И это старый "Эльбрус-4С", 4-го поколения, который архитектурно (архитектурно, не по процессу) проигрывает 6-му поколению где-то в 2.5 раза. Плюс 10-50% даёт новый компилятор.
В целом же на тестах (архиваторы, к примеру - сложный тест) новые "Эльбрусы" идёт вровень с процами (с равным количеством ядер) 3-4 летней давности.
yacc> Кажется ты говорил что можно жить и на 65нм ?
Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
yacc> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
Условный ETL даже на процессоре в 12.5 раза медленнее будет медленнее раза в 2. Ты, видимо, просто с практикой этого дела не имел и производительность никогда сам не сравнивал. Это не квантовая химия, где вся матрица может полностью в кеше помещаться, тут всё ограничено памятью, хардами, сетью.
Собссно, почему на высоконагруженные кластера и не ставят самые новейшие процы. Потому что они дорогие, и те, кто считают расходы на решение задачи знают, что выгоднее добавить хостов (покуда это возможно). Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
Это же шаг назад, в прошлое? число транзакций растёт, что же будет? мы все умрём?
Нет, это работает несколько иначе. А там, где всё зависит от производительности одиночного проца в одном потоке, там всё умерло уже давно, и то, что мертво, - умереть не может.
Татарин>> Тогда в чём проблема-то?
yacc> Ты не поверишь, но скажем на Украине тоже не ужасно. Хуже, но не ужасно.
Ессно, не поверю. Украина не может развиваться, а страна с процессорами на 40нм - вот запросто.
yacc> Солянка собралась по принципу "кто что может дать и кто на это согласится" .
Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
yacc> Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
У тебя мысль... При чём тут тот факт, что и "Росатом", и другие конторы считают за счастье продавать Китаю технологии? И продавали. И продают - только Китаю брать больше нечего.
Даже БН-800 - вполне рентабельный и окупается. То, что он по экономике хуже, чем ВВЭР - вполне ожидаемо (на бумажном этапе было прописано), сейчас есть проект БН-1200, который по экономике лучше ВВЭР. Всё развивается, и китайцам тоже нужно с чего-то начинать.
yacc> yacc>> Нет референтного блока - речь о том что усвоили технологии пока не идет.
Татарин>> Первый "Хуалонг-1" был пущен 31.10.20, подключен к сети 27.11.20.
yacc> Т.е. считай что и полгода нет
Полгода нет чего?
Посмотри, когда был пущен последний АР-1000, посмотри, когда их начинали строить (и когда китайцы собрали достаточно знаний для запуска своего "лицензионно чистого" (угу) проекта). И сравни с датой начала строительства и запуска "Хуалонга".
Татарин>> Кто-то делал на ИБМ. Кто-то сейчас делает на "Эльбрусе".
yacc> Это типа такого ?
Ну да, в том числе. И?
И, кстати, ты статейки-то с "хабра" дели где-то на 50.
Татарин>> Банковские системы - вообще не самые нагруженные.
yacc> За банками сейчас и ФНС приглядывает в РФ. Плюс банки разные сервисы вводят.
Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
Татарин>> На x64 ты 100% не напишешь код лучше современного оптимизирующего компилятора (не случайно взятого, а нормального, с настройками которого поигрался знающий человек).
yacc> Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Во-первых, опять прыжок мысли с тезиса "на ассемблере быстрее" (а если компьютер с принтером - то ещё быстрее!) на непонятно куда.
Во-вторых, блин. Блин.
Ну нифига не понимаешь ты о чём говоришь. Ну вот нифига.
"Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
Татарин>> Тот же интеловский компилятор знает об особенностях интеловских процов всё - включая размеры кешей, особенности выравнивания, распределения микрокода по юнитам... и не просто помнит, а ещё и не забывает применять.
yacc> Не будет у тебя интеловского компилятора.
Так а нафига он? не под интеловский проц-то?
yacc> Не будет у тебя C# - будет Java на Линуксе.
1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима, а про разницу С с ассемблером я уже сказал, там она может быть запросто и в обратную сторону.
Ну не пробовали мы Яву и никогда её не рассматривали. Только поэтому сравнил с С#, были бы данные по Яве - привёл бы их. Впрочем, чужие тесты говорят, что там того же порядка числа.
Татарин>> Ну, пусть наивно. Какая разница, если сейчас в большинстве случаев это реально так?
yacc> Сейчас просто берут Apache Kafka если надо перетащить данные. А это Java. Плюс ее еще и в докере запускают. Правильный код на С будет явно быстрее, если чистая Java на двоичных деревьях раза в три проигрывает gcc
Во-первых, Вы её просто готовить не умеете (да, внезапно, над енвироментом для Явы тоже нужно посидеть; например, для того же докера маскимальный хип сайз оставляют на дефолте, а это сразу ява-машине как серпом по яйцам). Во-вторых, ты, кажется, не понимаешь, что ты только что сказал.
А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
Татарин>> Если ты параллелишь на уровне сиквела, у тебя уже есть проблемы с архитектурой.
yacc> А если у тебя несколько баз - у тебя нет целостности.
Есть, всё есть. Ещё раз: на это есть архитектурные решения, на уровне бизнес-логики даже.
Ну вот когда и кем по-твоему придуманы клиринговые операции?
Вот с тех самых пор, когда процессинг операций производился тётками с ручками и бумажками (и лишь иногда с арифмометрами) со средней скоростью процессинга примерно 1 операция в минуту, эти проблемы параллелизации транзакций и сверки данных были решены.
И да, сейчас они тоже решены.
И да, если где-то в этой сфере они НЕ решены - то это не проблема "недостаточно быстрых процессоров", а слишком тупых программистов, и только.
Ещё раз: весь мир работал с банками, когда производительность "процессоров" была меньше где-то в триллион раз. Триллион. Не 10. И транзакций тогда (ещё в 50-60-е годы) проходило всего в тысячи-миллионы раз меньше, чем сегодня.
Реально есть процессы, которые можно выполнять только последовательно (вычислять число "пи", к примеру), и там критически важна производительность отдельного процессора. Но я не знаю бизнес-задач из реального мира, которые имели бы подобные критичные проблемы.
Татарин>> Ставлю кластера, способные справиться с современным объёмом. Только и всего.
yacc> См. выше.
И?
yacc> Не не не - ты бери Cedar Mill ( 65 нм ) и сравни его хотя бы с haswell ( 22 нм )
И что будет?
yacc> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Потому что запустили тесты не НЕ родной (не в нейтив-коде) Ява-машине (она сделана относительно недавно), в режиме эмуляции. И это старый "Эльбрус-4С", 4-го поколения, который архитектурно (архитектурно, не по процессу) проигрывает 6-му поколению где-то в 2.5 раза. Плюс 10-50% даёт новый компилятор.
В целом же на тестах (архиваторы, к примеру - сложный тест) новые "Эльбрусы" идёт вровень с процами (с равным количеством ядер) 3-4 летней давности.
yacc> Кажется ты говорил что можно жить и на 65нм ?
Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
yacc> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
Условный ETL даже на процессоре в 12.5 раза медленнее будет медленнее раза в 2. Ты, видимо, просто с практикой этого дела не имел и производительность никогда сам не сравнивал.
Это не квантовая химия, где вся матрица может полностью в кеше помещаться, тут всё ограничено памятью, хардами, сетью.Собссно, почему на высоконагруженные кластера и не ставят самые новейшие процы. Потому что они дорогие, и те, кто считают расходы на решение задачи знают, что выгоднее добавить хостов (покуда это возможно). Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
Это же шаг назад, в прошлое? число транзакций растёт, что же будет? мы все умрём?
Нет, это работает несколько иначе. А там, где всё зависит от производительности одиночного проца в одном потоке, там всё умерло уже давно, и то, что мертво, - умереть не может.
yacc>> Посему обычный вопрос в таком деле - мы будем ее херачить или тупо закупим более быстрое железо
с.т.> это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
А железо, кстати, по всему миру уже заканчивается.
Если посмотреть на увеличение чистой на ядро производительности процов последние лет 10, то от поколения к поколению чистая и полная разница производительности 5-20%, то есть, накопленная за 10 лет - несколько раз.
Сейчас выгоднее тупо набивать чипы ядрами и тратить транзисторы на них (что и показывают нынешние рекордсмены по производительности). То есть, параллелизации во всех видах просто нет альтернативы, вот в принципе нет. А раз так, то разница между процессорами из качественной становится чисто количественной: процессоры А занимают n кубов пространства и жрут мощность W1, а процессоры Б занимают m кубов и жрут мощность W2.
Времена поменялись.
с.т.> это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
А железо, кстати, по всему миру уже заканчивается.
Если посмотреть на увеличение чистой на ядро производительности процов последние лет 10, то от поколения к поколению чистая и полная разница производительности 5-20%, то есть, накопленная за 10 лет - несколько раз.
Сейчас выгоднее тупо набивать чипы ядрами и тратить транзисторы на них (что и показывают нынешние рекордсмены по производительности). То есть, параллелизации во всех видах просто нет альтернативы, вот в принципе нет. А раз так, то разница между процессорами из качественной становится чисто количественной: процессоры А занимают n кубов пространства и жрут мощность W1, а процессоры Б занимают m кубов и жрут мощность W2.
Времена поменялись.
с.т.> откуда у ПФР громадные объёмы данных?
с.т.> там ~140 млн пенсионных счетов на которых раз ну в месяц что-то происходит.
Так он же по своим коэффициентам по побочным данным рассчитывает а не только приход-уход
с.т.> это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
Только вот в чем проблема - система которым по 10-15 лет и которые сейчас работают разрабатывались именно в такой парадигме - а давайте проще железо докупим
с.т.> там ~140 млн пенсионных счетов на которых раз ну в месяц что-то происходит.
Так он же по своим коэффициентам по побочным данным рассчитывает а не только приход-уход
с.т.> это пока железо есть...пока регулярно подносят более быстрое железо за теже бабки...сами понимаешь что можно на более горящих вопросах фокусироваться чем оптимизация ради оптимизации...
Только вот в чем проблема - система которым по 10-15 лет и которые сейчас работают разрабатывались именно в такой парадигме - а давайте проще железо докупим
yacc> Только вот в чем проблема - система которым по 10-15 лет и которые сейчас работают разрабатывались именно в такой парадигме - а давайте проще железо докупим
значит у них есть потенциал по оптимизации. это не только проблема но реальный кейс на котором кто-то деньги зарабатывает и зарплату окупает свою (NDA, NDA...)
значит у них есть потенциал по оптимизации. это не только проблема но реальный кейс на котором кто-то деньги зарабатывает и зарплату окупает свою (NDA, NDA...)
Татарин> Времена поменялись.
отлично. покупайте наши тру-mpp системы (кроме шуток). они именно про вот это вот всё...
отлично. покупайте наши тру-mpp системы (кроме шуток). они именно про вот это вот всё...
Татарин> Ессно, не поверю. Украина не может развиваться, а страна с процессорами на 40нм - вот запросто.
Ты не определился с трактовкой слова "ужасно" а уже не веришь.
Хотя люди живут, хуже, но не ужасно - это так.
Татарин> Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
Не смеши.
Ты точно читал статью ?
В свое время на рынок РИ тоже иностранцы ломились - на тот же авиационный. Но по факту сделать локализованный двигатель РИ не могла - этого ей не передавали.
Точно также Китай проглотил сорванный план пятелитки с Вестингхауз и умолял ее побыстрее.
yacc>> Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
Татарин> У тебя мысль... При чём тут тот факт, что и "Росатом", и другие конторы считают за счастье продавать Китаю технологии? И продавали.
Еще раз - технологии - они разные бывают. Есть которые завязаны на разработчиков и секретами делиться они не спешат
Татарин> Даже БН-800 - вполне рентабельный и окупается.
Только вот у Росатома нет планов их массовой постройки для нужд энергетики.
Татарин> Полгода нет чего?
Эксплуатации.
Татарин> Посмотри, когда был пущен последний АР-1000, посмотри, когда их начинали строить (и когда китайцы собрали достаточно знаний для запуска своего "лицензионно чистого" (угу) проекта).
А скажи мне - почему там детекторы нейтронов и датчики давления от Роллс Ройс ?
"Хуалонг" локализован где-то на 88% - хвосты все равно есть.
Татарин> И, кстати, ты статейки-то с "хабра" дели где-то на 50.
А ты сначала их читай внимательно - уже ниже видно
Татарин> Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
Банки сейчас это не только операции со счетами.
yacc>> Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Татарин> Во-первых, опять прыжок мысли с тезиса "на ассемблере быстрее" (а если компьютер с принтером - то ещё быстрее!) на непонятно куда.
Татарин> Во-вторых, блин. Блин.
Татарин> Ну нифига не понимаешь ты о чём говоришь. Ну вот нифига.
Татарин> "Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
А ты точно gcc знаешь ? Ты портировал программы на другие процессоры и смотрел ассемблерный код, что получается ? gcc - это набор-конструктор - он генерит ассемблерный код, который потом скармливает ассемблеру. Ты хоть представляешь вообще как оптимизатор работает ?
Непосредственно с VLIW я не сталкивался, а вот код, который генерит gcc для RISC SH4 вполне смотрел ( там штук 16 РОН ), чтобы прикинуть как лучше написать. С оптимизаций под VLIW гемора еще больше - там регистров под две сотни.
Татарин> И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
В соврменном мире подкручивают gcc под архитектуру. Компилятор с нуля писать нет никакой надобности.
yacc>> Не будет у тебя C# - будет Java на Линуксе.
Татарин> 1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
Но в энтерпрайзе толком не используется. Да и нафига миксовать это с апачевскими продуктами где джава.
Татарин> 2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима
Э... смотря как ты напишешь на С++
Татарин> Ну не пробовали мы Яву и никогда её не рассматривали. Только поэтому сравнил с С#, были бы данные по Яве - привёл бы их. Впрочем, чужие тесты говорят, что там того же порядка числа.
Тесты говорят что раза в три медленнее построение тех же двоичных деревьев.
gcc и Java. На линуксе.
Татарин> А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
И поэтому у тебя будет легаси код, написанный по такому принципу. И откровенно хреновый для реализации на VILW
Татарин> Есть, всё есть. Ещё раз: на это есть архитектурные решения, на уровне бизнес-логики даже.
Да нихрена. Шардинг боком к бизнес логике.
Татарин> И да, если где-то в этой сфере они НЕ решены - то это не проблема "недостаточно быстрых процессоров", а слишком тупых программистов, и только.
Знаешь, я не раз видел, когда приходит новый горячий программист на легаси проект. Потом заявляет "да у вас тут архитектура кривая и неправильная". Достаточно ему сказать - "ок. вот тебе и карты в руки - напиши как правильно вместе с миграцией" - обычно человек через неделю уходит
Татарин> Реально есть процессы, которые можно выполнять только последовательно (вычислять число "пи", к примеру), и там критически важна производительность отдельного процессора. Но я не знаю бизнес-задач из реального мира, которые имели бы подобные критичные проблемы.
Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Татарин> И что будет?
Ну сравни ту же архивацию к примеру. Это - реальная задача в энтерпрайзе - скажем архивация бэкапов.
А делать это надо постоянно.
yacc>> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Татарин> Потому что запустили тесты не НЕ родной (не в нейтив-коде) Ява-машине (она сделана относительно недавно)
Ты статью точно читал ?
Это именно портированная джава-машина, а не эмуляция x86
Татарин> В целом же на тестах (архиваторы, к примеру - сложный тест) новые "Эльбрусы" идёт вровень с процами (с равным количеством ядер) 3-4 летней давности.
Техпроцесса под Эльбрус-8 в РФ нет.
yacc>> Кажется ты говорил что можно жить и на 65нм ?
Татарин> Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
См. выше про Эльбрус-4С, внимательно.
В РФ есть только 65 нм и то только на Микроне и то по нему процессоры и не делают - только ОЗУ.
yacc>> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
Татарин> Условный ETL даже на процессоре в 12.5 раза медленнее будет медленнее раза в 2. Ты, видимо, просто с практикой этого дела не имел и производительность никогда сам не сравнивал.
Ты, видать, пропускаешь букву T в слове ETL. Hash match это внезапно - ОЗУ и процессор. При простеньком ветвлении на те же целевые таблицы в стейджинге ты во всей красе VILW не задействуешь, а куча ветвлений для него - просадка с неиспользованием ресурсов. И да - то же чтение файлов - это опять строкообработка, которая опять CPU и опять хренова для VILW.
Татарин> Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
ARM дешевле по энергопотреблению и часть можно на него и перенести. И это не 65 нм ARM.
Ты не определился с трактовкой слова "ужасно" а уже не веришь.
Хотя люди живут, хуже, но не ужасно - это так.
Татарин> Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
Не смеши.
Ты точно читал статью ?
В свое время на рынок РИ тоже иностранцы ломились - на тот же авиационный. Но по факту сделать локализованный двигатель РИ не могла - этого ей не передавали.
Точно также Китай проглотил сорванный план пятелитки с Вестингхауз и умолял ее побыстрее.
yacc>> Видишь ли - БН хоть и действует но откровенно сейчас нерентабельный.
Татарин> У тебя мысль... При чём тут тот факт, что и "Росатом", и другие конторы считают за счастье продавать Китаю технологии? И продавали.
Еще раз - технологии - они разные бывают. Есть которые завязаны на разработчиков и секретами делиться они не спешат
Татарин> Даже БН-800 - вполне рентабельный и окупается.
Только вот у Росатома нет планов их массовой постройки для нужд энергетики.
Татарин> Полгода нет чего?
Эксплуатации.
Татарин> Посмотри, когда был пущен последний АР-1000, посмотри, когда их начинали строить (и когда китайцы собрали достаточно знаний для запуска своего "лицензионно чистого" (угу) проекта).
А скажи мне - почему там детекторы нейтронов и датчики давления от Роллс Ройс ?
"Хуалонг" локализован где-то на 88% - хвосты все равно есть.
Татарин> И, кстати, ты статейки-то с "хабра" дели где-то на 50.
А ты сначала их читай внимательно - уже ниже видно
Татарин> Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
Банки сейчас это не только операции со счетами.
yacc>> Компилятор у тебя будет gcc - на Эльбрусе. И у китайцев тоже.
Татарин> Во-первых, опять прыжок мысли с тезиса "на ассемблере быстрее" (а если компьютер с принтером - то ещё быстрее!) на непонятно куда.
Татарин> Во-вторых, блин. Блин.
Татарин> Ну нифига не понимаешь ты о чём говоришь. Ну вот нифига.
Татарин> "Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
А ты точно gcc знаешь ? Ты портировал программы на другие процессоры и смотрел ассемблерный код, что получается ? gcc - это набор-конструктор - он генерит ассемблерный код, который потом скармливает ассемблеру. Ты хоть представляешь вообще как оптимизатор работает ?
Непосредственно с VLIW я не сталкивался, а вот код, который генерит gcc для RISC SH4 вполне смотрел ( там штук 16 РОН ), чтобы прикинуть как лучше написать. С оптимизаций под VLIW гемора еще больше - там регистров под две сотни.
Татарин> И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
В соврменном мире подкручивают gcc под архитектуру. Компилятор с нуля писать нет никакой надобности.
yacc>> Не будет у тебя C# - будет Java на Линуксе.
Татарин> 1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
Но в энтерпрайзе толком не используется. Да и нафига миксовать это с апачевскими продуктами где джава.
Татарин> 2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима
Э... смотря как ты напишешь на С++
Татарин> Ну не пробовали мы Яву и никогда её не рассматривали. Только поэтому сравнил с С#, были бы данные по Яве - привёл бы их. Впрочем, чужие тесты говорят, что там того же порядка числа.
Тесты говорят что раза в три медленнее построение тех же двоичных деревьев.
gcc и Java. На линуксе.
Татарин> А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
И поэтому у тебя будет легаси код, написанный по такому принципу. И откровенно хреновый для реализации на VILW
Татарин> Есть, всё есть. Ещё раз: на это есть архитектурные решения, на уровне бизнес-логики даже.
Да нихрена. Шардинг боком к бизнес логике.
Татарин> И да, если где-то в этой сфере они НЕ решены - то это не проблема "недостаточно быстрых процессоров", а слишком тупых программистов, и только.
Знаешь, я не раз видел, когда приходит новый горячий программист на легаси проект. Потом заявляет "да у вас тут архитектура кривая и неправильная". Достаточно ему сказать - "ок. вот тебе и карты в руки - напиши как правильно вместе с миграцией" - обычно человек через неделю уходит
Татарин> Реально есть процессы, которые можно выполнять только последовательно (вычислять число "пи", к примеру), и там критически важна производительность отдельного процессора. Но я не знаю бизнес-задач из реального мира, которые имели бы подобные критичные проблемы.
Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Татарин> И что будет?
Ну сравни ту же архивацию к примеру. Это - реальная задача в энтерпрайзе - скажем архивация бэкапов.
А делать это надо постоянно.
yacc>> Эльбрус 4С проигрывает в 12,5 раз всего-то Sandy Bridge ( снят с производства )
Татарин> Потому что запустили тесты не НЕ родной (не в нейтив-коде) Ява-машине (она сделана относительно недавно)
Ты статью точно читал ?
Это именно портированная джава-машина, а не эмуляция x86
Татарин> В целом же на тестах (архиваторы, к примеру - сложный тест) новые "Эльбрусы" идёт вровень с процами (с равным количеством ядер) 3-4 летней давности.
Техпроцесса под Эльбрус-8 в РФ нет.
yacc>> Кажется ты говорил что можно жить и на 65нм ?
Татарин> Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
См. выше про Эльбрус-4С, внимательно.
В РФ есть только 65 нм и то только на Микроне и то по нему процессоры и не делают - только ОЗУ.
yacc>> Вот прикинь что условный ETL у тебя работает не час, а 12.5 часов.
Татарин> Условный ETL даже на процессоре в 12.5 раза медленнее будет медленнее раза в 2. Ты, видимо, просто с практикой этого дела не имел и производительность никогда сам не сравнивал.
Ты, видать, пропускаешь букву T в слове ETL. Hash match это внезапно - ОЗУ и процессор. При простеньком ветвлении на те же целевые таблицы в стейджинге ты во всей красе VILW не задействуешь, а куча ветвлений для него - просадка с неиспользованием ресурсов. И да - то же чтение файлов - это опять строкообработка, которая опять CPU и опять хренова для VILW.
Татарин> Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
ARM дешевле по энергопотреблению и часть можно на него и перенести. И это не 65 нм ARM.
с.т.> значит у них есть потенциал по оптимизации.
Более чем есть.
Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора.
Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
Более чем есть.
Пенсионный фонд вложил 20 миллионов в развитие ПО для своих «Эльбрусов»
Пенсионный фонд продолжает адаптировать элементы своей АИС под серверы на российских процессорах «Эльбрус».... // www.cnews.ruВ ходе доработки ПО подрядчику предстоит создать индексы базы данных, которые обеспечат повышение производительности используемых запросов SQL, а также оптимизировать работу СУБД и дисковое пространство для хранения данных. «Необходимо выполнить сборку версии СУБД PostgreSQL с учетом особенностей оптимизации для компиляторов, используемых на серверах “Эльбрус”», — говорится в техзадании.
Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора.
Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
Кстати о Loongson 3A3000
Просто с комментов к посту, что я уже приводил
И
Просто с комментов к посту, что я уже приводил
Пенсионный фонд продолжает миграцию на процессоры «Эльбрус». Работы идут четыре года
С 2016 года Пенсионный фонд РФ пытается перенести программное обеспечение с серверов IBM iSeries под управлением СУБД IBM DB2 на ОС «Эльбрус», СУБД PostgreSQL с... // habr.comНу по теоретическим гигафлопсам сравнивать камни сильно разной архитектуры вообще не очень корректно — слишком уж сильно отличается эффективность («КПД») использования этих гигафлопсов. Особенно в таких простых архитектурах как МИПС. Так же нужно внимательно следить, чтобы гигафлопы одинарной точности не выдавали за флопы двойной точности, что китайцы любят делать (как и одно время баловались эльбрусовцы). Разница как минимум в 2 раза.
Лучше на каких-то практических тестах посмотреть. Вот например сами же китайцы протестировали одну из последних моделей в SPEC CPU 2006: 龙芯3A3000处理器芯片流片成功_龙芯官方网站-[龙芯官方网站]
SPEC CPU 2006 fixed-point and floating-point single-core scores compiled by GCC exceeded 11 and 10 points
Т.е. 10/11 очков в целочисленных и с плавающей точкой операциях на 1 поток и 33 очка в многопоточном режиме.
Для сравнения можно взять например 4я ядерный AMD Atlon II X4 вышедший еще аж в 2009 году как упрощенная (удешевленная) версия Феном 2:
spec.org/cpu2006/results/res2011q3/cpu2006-20110801-18097.html — 25 fp очков на 1 ядре
spec.org/cpu2006/results/res2011q3/cpu2006-20110801-18124.html — 68 int очков на всех ядрах
spec.org/cpu2006/results/res2011q3/cpu2006-20110801-18098.html — 57 fp очков на всех ядрах
Т.е. китайский процессор вышедший в 2016м году и прозводящийся до сих пор все еще довольно (больше чем в 2 раза) отстает по скорости работы от эконом-серии AMD вышедшей в 2009 году (вот обзорчик на него как раз в тему — можно освежить память: немного компьютерного ретро из нулевых).
По энергоэффективности (скорость/Вт) он немного обходит вариант от АМД, но тут неудивительно — камень вышел на 7 лет позже и производится на 28нм технологии, когда Атлоны производились на 45нм + низкая частота работы (1.5 ГГц против 2.8 ГГц). От современников он и по энергоэффективности довольно сильно отстает.
Хотя даже по теоретическим Гигафлопам непотнятно откуда все эти цифры в вики. Сами производитель для него заявляет всего 24 ГФплопс, надеюсь двойной точности (龙芯3A3000/3B3000_龙芯官方网站-[龙芯官方网站])
При потребляемой мощности в 30 Вт это даже теоретической пиковой производительности дает меньше 1 ГФлопс/Вт, на практике конечно еще меньше. А не > 3 ГФплопс/Вт которые кто-то вписал в Вики. Пора этот раздел переписывать и чистить от ложных утверждений.
И
Русская вики заканчивалась на более новом(но при этом более слабом) 3A2000, а не 3B1500. А теперь там все реально существующие или существовавшие процессоры этой серии есть.
Я обычно вообще с первоисточниками работаю. А вики неплохое место чтобы с него начать и набрать ссылок на первоисточники или ключевых фраз для гуглежа.
И сравнивал с атлонами я не 3B1500 и даже не вышедший после него 3A2000, а с Loongson 3A3000 — именно эти процессоры начиная с 2017 года массово в Китае производятся и используются в их компах по программам «импортозамещения» наряду с более старыми 3A200. Так вот эти процессоры что они сейчас делают и используют у себя почти в 2.5 раза слабее чем Atlon II X4 из 2009 года, пруфы на это выше.
Сейчас у них только-только вышел Loongson 3A4000 / 3B4000 — разработка только закончилась, буквально в конце декабря была его официальная презентация. Можно с гуглопереводчиком почитать: 龙芯重磅发布新一代处理器，全力打造IT产业新生态_龙芯官方网站-[龙芯官方网站]
Этот процессор еще только должен будет заменить 3A3000. В этом году начинается серийное производство.
По данным самих китайцев(по той же ссылке) 3A4000 / 3B4000 на реальных задачах примерно в 2 раза мощнее чем 3A3000 — около 20 очков по тому же самому пакету тестов SPEC CPU 2006.
В относительном отношении это неплохой прогресс — рост реальной скорости в 2 раза за 3 года (от модели 2016/2017 годов к модели 2019/2020 годов).
Но по абсолютному уровню до сих пор немного не догнали тот же самый Atlon II X4.
Т.е. китайская модель 2020 года все еще немного слабее модели от AMD из 2009 года. Хотя уже почти догнали (и в некоторых задачах он уже быстрее), осталось чуть-чуть, в следующем поколении обязательно перегонят.
3А5000 / 3С5000? сравнивать несущесвующий еще процессор, который в лучшем случае только через пару лет появится и спецификации которого еще не раз до этого поменяются, как они менялись в процессе разработки у всех предыдущих(обычно в худшую сторону)?
Нет, спасибо. «бумажные анонсы» не интересны. Вот когда реально они появятся (года через 2-3), тогда и сравним что реально получится на выходе.
Атлоны и феномы они в 2021 или 2022 году с это моделью наконец-то уверенно обгонят, но вот хотя бы до Zen-1 или haswell/broadwell от Intel еще врядли дотянутся. Но отставание вероятно с ~10 лет сейчас может сократиться до 5-7 лет.
- yacc [01.05.2021 00:28]: Перенос сообщений из Россия. 2021. Итоги.
yacc> Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора.
Ты реально настолько ничего не понимаешь или тупишь?
Постгресс нужно перекомпилять в нейтив "Эльбруса".
Сам "Эльбрус" исполняет х64 в режиме псевдоэмуляции ("двоичной трансляции", как они это называют, но по сути своей - JIT, как на "Трансмете", только получше).
х64 код не "проседает" на VLIW, он попросту несовместим, он совершенно другой. А эмуляция, ессно проседает.
yacc> Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
Не надо так "переводить". Это бред какой-то.
Код Постгресса ничего не знает о регистрах, он на языке высокого уровня написан. Нужно перекомпилять продукт на компиляторе "Эльбруса" и дать бинарники под "Эльбрус".
Ты реально настолько ничего не понимаешь или тупишь?
Постгресс нужно перекомпилять в нейтив "Эльбруса".
Сам "Эльбрус" исполняет х64 в режиме псевдоэмуляции ("двоичной трансляции", как они это называют, но по сути своей - JIT, как на "Трансмете", только получше).
х64 код не "проседает" на VLIW, он попросту несовместим, он совершенно другой. А эмуляция, ессно проседает.
yacc> Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
Не надо так "переводить". Это бред какой-то.
Код Постгресса ничего не знает о регистрах, он на языке высокого уровня написан. Нужно перекомпилять продукт на компиляторе "Эльбруса" и дать бинарники под "Эльбрус".
Татарин>> Ессно, не поверю. Украина не может развиваться, а страна с процессорами на 40нм - вот запросто.
yacc> Ты не определился с трактовкой слова "ужасно" а уже не веришь.
Ты тоже. Так почему бы мне верить-то?
Татарин>> Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
yacc> Не смеши.
Ну, что я могу сделать, если тебя смешит всё подряд-то?
yacc> Точно также Китай проглотил сорванный план пятелитки с Вестингхауз и умолял ее побыстрее.
Ну да, профукали американцы свою поставку. Это не китайцев проблема - неустойки в контрактах прописаны. Китайцы их не рекламируют, чтобы не пугать никого, а американцы этим, понятно, не хвалятся... Но суммы там впечатляющие. Как и по ремонту/замене лопнувшего насоса... не надо думать, что это удовольствие китайцы оплачивали.
yacc> Еще раз - технологии - они разные бывают. Есть которые завязаны на разработчиков и секретами делиться они не спешат
Конечно. Но вот китайский подход - взять образец и по образцу техники уже сделать своё. А потом - ещё своее, и ещё. Это общий подход такой. Судя по общему развитию Китая - более чем результативный, пока, ессно, есть у кого брать образцы. Но пока образцы есть, с китайской точки зрения глупо не пользоваться ими.
Татарин>> Даже БН-800 - вполне рентабельный и окупается.
yacc> Только вот у Росатома нет планов их массовой постройки для нужд энергетики.
Есть планы на БН-1200М, который со всех сторон лучше и суть следующий шаг.
Татарин>> Полгода нет чего?
yacc> Эксплуатации.
А именно полгода эксплуатации нужно, чтобы убедиться, что "Хуалонг" - реальный, работающий реактор?
А через год не будет и двух лет эксплуатации? а через 5 лет - не будет и шести?
yacc> А скажи мне - почему там детекторы нейтронов и датчики давления от Роллс Ройс ?
yacc> "Хуалонг" локализован где-то на 88% - хвосты все равно есть.
Так почему бы нет-то, на первом изделии? Изделия специфичные, малосерийные и наукоёмкие. На передрать их нужно время. Но передерут, ессно. Знаешь, как едят слона? Слона едят по частям.
Татарин>> И, кстати, ты статейки-то с "хабра" дели где-то на 50.
yacc> А ты сначала их читай внимательно - уже ниже видно
Иногда читаю. Именно из таких случаев вывел правило: делать скидку на специфику аффтаров там.
Татарин>> Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
yacc> Банки сейчас это не только операции со счетами.
А как это соотносится с моими словами вообще?
Я вижу уже чётко тенденцию говорить нечто никак не связанное с тезисом оппонента. Зачем ты это делаешь?
Ты хочешь доказать, что банки сейчас требуют самых совершенных вычислителей потому, что они сейчас занимаются не только операциями со счетами? Тогда где это доказательство. Или к чему это вообще было?
Ты заявил, что сейчас так много транзакций, что процессоры 10-летней давности не справятся. Этот сам по себе абсурдный тезис легко опровергается множеством способов: 10 лет назад были банки, у которых транзакций было в десятки раз больше, чем у русских банков сейчас, сталыть, как-нибудь уж справиться можно, очевидно. Хорошо, банки - это не только счета, а ещё и красивые операционистки. Дальше - что?
Татарин>> "Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
yacc> А ты точно gcc знаешь ? Ты портировал программы на другие процессоры и смотрел ассемблерный код, что получается ?
Да, я точно знаю gcc. И даже что такое llvm знаю. И знаю, почему gcc-тулчейн, к сожалению, нельзя переделать, чтобы он выдавал код для VLIW напрямую.
И нет, я опять не знаю, почему ты об этом вдруг заговорил.
У "Эльбруса" свой (полностью gcc-совместимый по коду) компилятор. Который - очень сложная вещь, и бОльшая часть разработки.
Татарин>> И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
yacc> В соврменном мире подкручивают gcc под архитектуру. Компилятор с нуля писать нет никакой надобности.
Ну, это тебе так кажется. Если бы ты реально смотрел то, что выдаёт gcc на выходе и на каком этапе реально появляется код, ты бы понял, какую фигню несёшь.
Можешь посмотреть на модель IR llvm (гугл поможет). Ну или просто поверить, что VLIW "Эльбруса" (и не только; вообще любая сильно отличная от классической архитектура) в неё не вписывается. Для VLIW нет средств, чтобы вписать сложное слово с флагами.
yacc> yacc>> Не будет у тебя C# - будет Java на Линуксе.
Татарин>> 1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
yacc> Но в энтерпрайзе толком не используется. Да и нафига миксовать это с апачевскими продуктами где джава.
Эээ... опять? Так "не будет" или "нафига"? Тезис был "не будет". Очевидно, что при необходимости - будет. А Ява, ну что Ява... перекомпиляли вот VM, будет она теперь нормальной Явой.
Татарин>> 2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима
yacc> Э... смотря как ты напишешь на С++
Да, тут должен согласиться, что всегда можно сделать хуже.
Татарин>> А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
yacc> И поэтому у тебя будет легаси код, написанный по такому принципу. И откровенно хреновый для реализации на VILW
Ну будет легаси. Ну, какая-то часть будет неудобной для VLIW. Какая-то выиграет. И что?
yacc> Знаешь, я не раз видел, когда приходит новый горячий программист на легаси проект. Потом заявляет "да у вас тут архитектура кривая и неправильная". Достаточно ему сказать - "ок. вот тебе и карты в руки - напиши как правильно вместе с миграцией" - обычно человек через неделю уходит
Да, но у тебя обратный случай: тут-то легаси вполне годное, ты предлагаешь сделать (иначе откуда оно возьмётся?!) что-то, что критично завязано на скорость отдельного проца (видимо, скорость отдельного потока).
Так уже очень давно не пишут большие системы.
yacc> Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да? И засунуть их балками в SQL? И?
Что именно рассказать? как именно я сделаю 100 CSV поменьше?
Татарин>> И что будет?
yacc> Ну сравни ту же архивацию к примеру. Это - реальная задача в энтерпрайзе - скажем архивация бэкапов.
Ну? Так что будет-то?!
В три раза медленнее? ну, и?
yacc> А делать это надо постоянно.
И ладно.
yacc> yacc>> Кажется ты говорил что можно жить и на 65нм ?
Татарин>> Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
yacc> См. выше про Эльбрус-4С, внимательно.
yacc> В РФ есть только 65 нм и то только на Микроне и то по нему процессоры и не делают - только ОЗУ.
Да, я знаю.
Эльбрус-4С уже старый именно в архитектурном смысле.
yacc> Ты, видать, пропускаешь букву T в слове ETL. Hash match это внезапно - ОЗУ и процессор. При простеньком ветвлении на те же целевые таблицы в стейджинге ты во всей красе VILW не задействуешь, а куча ветвлений для него - просадка с неиспользованием ресурсов. И да - то же чтение файлов - это опять строкообработка, которая опять CPU и опять хренова для VILW.
Почему же пропускаю? Просто напоминаю, что работает не только процессор, и типично как раз в этих задачах процессор не самое узкое горлышко и не самое слабое звено.
Татарин>> Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
yacc> ARM дешевле по энергопотреблению и часть можно на него и перенести. И это не 65 нм ARM.
Да, именно так. Несмотря на то, что нужно больше хостов, это выгоднее в итоге. И никого увеличение холстов и снижение производительности отдельного юнита не смущает.
Если же нет выбора - смущать тем более не будет: запустят всё на куче "Эльбрусов", и всё поедет.
yacc> Ты не определился с трактовкой слова "ужасно" а уже не веришь.
Ты тоже. Так почему бы мне верить-то?
Татарин>> Блин, ты не представляешь, что за чушь ты несёшь. Да все быками ломились на китайский рынок, застолбить кусочек. Китай выбирал (и условия ставил очень жёсткие, и всё более жёсткие раз от разу) - и взял всего понемногу.
yacc> Не смеши.
Ну, что я могу сделать, если тебя смешит всё подряд-то?
yacc> Точно также Китай проглотил сорванный план пятелитки с Вестингхауз и умолял ее побыстрее.
Ну да, профукали американцы свою поставку. Это не китайцев проблема - неустойки в контрактах прописаны. Китайцы их не рекламируют, чтобы не пугать никого, а американцы этим, понятно, не хвалятся... Но суммы там впечатляющие. Как и по ремонту/замене лопнувшего насоса... не надо думать, что это удовольствие китайцы оплачивали.
yacc> Еще раз - технологии - они разные бывают. Есть которые завязаны на разработчиков и секретами делиться они не спешат
Конечно. Но вот китайский подход - взять образец и по образцу техники уже сделать своё. А потом - ещё своее, и ещё. Это общий подход такой. Судя по общему развитию Китая - более чем результативный, пока, ессно, есть у кого брать образцы. Но пока образцы есть, с китайской точки зрения глупо не пользоваться ими.
Татарин>> Даже БН-800 - вполне рентабельный и окупается.
yacc> Только вот у Росатома нет планов их массовой постройки для нужд энергетики.
Есть планы на БН-1200М, который со всех сторон лучше и суть следующий шаг.
Татарин>> Полгода нет чего?
yacc> Эксплуатации.
А именно полгода эксплуатации нужно, чтобы убедиться, что "Хуалонг" - реальный, работающий реактор?
А через год не будет и двух лет эксплуатации? а через 5 лет - не будет и шести?
yacc> А скажи мне - почему там детекторы нейтронов и датчики давления от Роллс Ройс ?
yacc> "Хуалонг" локализован где-то на 88% - хвосты все равно есть.
Так почему бы нет-то, на первом изделии? Изделия специфичные, малосерийные и наукоёмкие. На передрать их нужно время. Но передерут, ессно. Знаешь, как едят слона? Слона едят по частям.
Татарин>> И, кстати, ты статейки-то с "хабра" дели где-то на 50.
yacc> А ты сначала их читай внимательно - уже ниже видно
Иногда читаю. Именно из таких случаев вывел правило: делать скидку на специфику аффтаров там.
Татарин>> Это отменяет тот факт, что банки - не самые нагруженные системы и никогда ими не были?
yacc> Банки сейчас это не только операции со счетами.
А как это соотносится с моими словами вообще?
Я вижу уже чётко тенденцию говорить нечто никак не связанное с тезисом оппонента. Зачем ты это делаешь?
Ты хочешь доказать, что банки сейчас требуют самых совершенных вычислителей потому, что они сейчас занимаются не только операциями со счетами? Тогда где это доказательство. Или к чему это вообще было?
Ты заявил, что сейчас так много транзакций, что процессоры 10-летней давности не справятся. Этот сам по себе абсурдный тезис легко опровергается множеством способов: 10 лет назад были банки, у которых транзакций было в десятки раз больше, чем у русских банков сейчас, сталыть, как-нибудь уж справиться можно, очевидно. Хорошо, банки - это не только счета, а ещё и красивые операционистки. Дальше - что?
Татарин>> "Эльбрус" - это VLIW. Там вся почти разработка процессора, собссно, - в комипиляторе, а не в железе.
yacc> А ты точно gcc знаешь ? Ты портировал программы на другие процессоры и смотрел ассемблерный код, что получается ?
Да, я точно знаю gcc. И даже что такое llvm знаю. И знаю, почему gcc-тулчейн, к сожалению, нельзя переделать, чтобы он выдавал код для VLIW напрямую.
И нет, я опять не знаю, почему ты об этом вдруг заговорил.
У "Эльбруса" свой (полностью gcc-совместимый по коду) компилятор. Который - очень сложная вещь, и бОльшая часть разработки.
Татарин>> И у "Эльбруса" - единственная (кроме, может, "Трансметы", которую давно опередили) успешная попытка реализовать толковый компилятор.
yacc> В соврменном мире подкручивают gcc под архитектуру. Компилятор с нуля писать нет никакой надобности.
Ну, это тебе так кажется.
Если бы ты реально смотрел то, что выдаёт gcc на выходе и на каком этапе реально появляется код, ты бы понял, какую фигню несёшь. Можешь посмотреть на модель IR llvm (гугл поможет). Ну или просто поверить, что VLIW "Эльбруса" (и не только; вообще любая сильно отличная от классической архитектура) в неё не вписывается. Для VLIW нет средств, чтобы вписать сложное слово с флагами.
yacc> yacc>> Не будет у тебя C# - будет Java на Линуксе.
Татарин>> 1. Почему не будет? С# - это CLR. Писать можно на чём угодно, лишь бы на целевой архитектуре имелась CLR-машина. Под Линукс она есть.
yacc> Но в энтерпрайзе толком не используется. Да и нафига миксовать это с апачевскими продуктами где джава.
Эээ... опять? Так "не будет" или "нафига"? Тезис был "не будет". Очевидно, что при необходимости - будет. А Ява, ну что Ява... перекомпиляли вот VM, будет она теперь нормальной Явой.
Татарин>> 2. Во-вторых - какая разница? Я просто привел пример того, какой реальный оверхед приносит даже манагед код в современном мире. Разница между С и С++ - незначима
yacc> Э... смотря как ты напишешь на С++
Да, тут должен согласиться, что всегда можно сделать хуже.
Татарин>> А если ты подумаешь над своими словами, ты сказал буквально следующее: "в современном мире сплошь и рядом людям посрать на производительность. Компы достаточно быстры, настолько быстры, что решения часто оптимизируются по количеству часов работы людей, а не машин". И это было так и 10 лет назад.
yacc> И поэтому у тебя будет легаси код, написанный по такому принципу. И откровенно хреновый для реализации на VILW
Ну будет легаси. Ну, какая-то часть будет неудобной для VLIW. Какая-то выиграет. И что?
yacc> Знаешь, я не раз видел, когда приходит новый горячий программист на легаси проект. Потом заявляет "да у вас тут архитектура кривая и неправильная". Достаточно ему сказать - "ок. вот тебе и карты в руки - напиши как правильно вместе с миграцией" - обычно человек через неделю уходит
Да, но у тебя обратный случай: тут-то легаси вполне годное, ты предлагаешь сделать (иначе откуда оно возьмётся?!) что-то, что критично завязано на скорость отдельного проца (видимо, скорость отдельного потока).
Так уже очень давно не пишут большие системы.
yacc> Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да?
И засунуть их балками в SQL? И?Что именно рассказать? как именно я сделаю 100 CSV поменьше?
Татарин>> И что будет?
yacc> Ну сравни ту же архивацию к примеру. Это - реальная задача в энтерпрайзе - скажем архивация бэкапов.
Ну? Так что будет-то?!
В три раза медленнее? ну, и?
yacc> А делать это надо постоянно.
И ладно.
yacc> yacc>> Кажется ты говорил что можно жить и на 65нм ?
Татарин>> Я говорил про 40нм, но разница - несущественна. Да, можно, и жить можно прекрасно.
yacc> См. выше про Эльбрус-4С, внимательно.
yacc> В РФ есть только 65 нм и то только на Микроне и то по нему процессоры и не делают - только ОЗУ.
Да, я знаю.
Эльбрус-4С уже старый именно в архитектурном смысле.
yacc> Ты, видать, пропускаешь букву T в слове ETL. Hash match это внезапно - ОЗУ и процессор. При простеньком ветвлении на те же целевые таблицы в стейджинге ты во всей красе VILW не задействуешь, а куча ветвлений для него - просадка с неиспользованием ресурсов. И да - то же чтение файлов - это опять строкообработка, которая опять CPU и опять хренова для VILW.
Почему же пропускаю? Просто напоминаю, что работает не только процессор, и типично как раз в этих задачах процессор не самое узкое горлышко и не самое слабое звено.
Татарин>> Вот как ты думаешь, как так вышло, что мир переходит на ARM, которые по абсолютной производительности на проц всё ещё уступают тем же интеловским поделкам?
yacc> ARM дешевле по энергопотреблению и часть можно на него и перенести. И это не 65 нм ARM.
Да, именно так. Несмотря на то, что нужно больше хостов, это выгоднее в итоге. И никого увеличение холстов и снижение производительности отдельного юнита не смущает.
Если же нет выбора - смущать тем более не будет: запустят всё на куче "Эльбрусов", и всё поедет.
Насчёт Явы: скорее всего, исполнение любого байт-кода или интерпретируемого языка будет на VLIW плозим всегда. Врождённое свойство архитектуры: если компилятор не "знает" на этапе компиляции, как будет вести себя код (а с интерпретатором его поведение задаётся интерпретируемым языком или кодом), то преимущества VLIW теряются; куча болезненных внезапных переходов и т.п.
Лечиться должно массовым применением JIT (нейтивного, ессно, JIT). То есть, вот тут богатое поле для работы МЦСТшных программистов.
Но с другой стороны, "Эльбрусы" от компиляции CLR и даже байт-кода в нейтив получат гораздо больший выигрыш, чем х86 или даже х64; в смысле, не относительный, а абсолютный: "Эльбрусовский" код будет быстрее интеловского. Тупо из-за разницы размера регистрового пула, как минимум.
Ну а как максимум - на развёрнутом коде теряет свои сравнительные преимущества intel, а вот VLIW может проявить себя вовсю.
Лечиться должно массовым применением JIT (нейтивного, ессно, JIT). То есть, вот тут богатое поле для работы МЦСТшных программистов.
Но с другой стороны, "Эльбрусы" от компиляции CLR и даже байт-кода в нейтив получат гораздо больший выигрыш, чем х86 или даже х64; в смысле, не относительный, а абсолютный: "Эльбрусовский" код будет быстрее интеловского. Тупо из-за разницы размера регистрового пула, как минимум.
Ну а как максимум - на развёрнутом коде теряет свои сравнительные преимущества intel, а вот VLIW может проявить себя вовсю.
Татарин> Ты реально настолько ничего не понимаешь или тупишь?
Татарин> Постгресс нужно перекомпилять в нейтив "Эльбруса".
Ты тупишь или реально думаешь что взяли двоичный дистрибутив Постгресс и тупо запустили на эмуляторе ?
Татарин> Не надо так "переводить". Это бред какой-то.
Надо переводить.
Татарин> Код Постгресса ничего не знает о регистрах, он на языке высокого уровня написан. Нужно перекомпилять продукт на компиляторе "Эльбруса" и дать бинарники под "Эльбрус".
Этого МАЛО!
Возьми руководство по эльбрусу и прочитай
Дословно оттуда
Постгресс в исходниках - это легаси код.
Татарин> Постгресс нужно перекомпилять в нейтив "Эльбруса".
Ты тупишь или реально думаешь что взяли двоичный дистрибутив Постгресс и тупо запустили на эмуляторе ?
Татарин> Не надо так "переводить". Это бред какой-то.
Надо переводить.
Татарин> Код Постгресса ничего не знает о регистрах, он на языке высокого уровня написан. Нужно перекомпилять продукт на компиляторе "Эльбруса" и дать бинарники под "Эльбрус".
Этого МАЛО!
Возьми руководство по эльбрусу и прочитай
Дословно оттуда
VLIW:
+больше открытых возможностей для выражения параллелизма инструкций;
+лучшая энергоэффективность при схожей производительности;
-возможные ухудшения производительности при исполнении legacy-кодов;
-более сложный код для отладки и анализа;
-более сложный компилятор.
OOOSS:
+эффективное исполнение legacy-кодов;
+дополнительная информация о параллельности операций, доступная в динамике исполнения;
-расход энергии на многократное планирование одних и тех же операций;
-ограниченность аппаратурой окна исполняемых операций для переупорядочивания
Постгресс в исходниках - это легаси код.
Это сообщение редактировалось 01.05.2021 в 08:54
yacc>> Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Татарин> Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да? И засунуть их балками в SQL? И?
Это я вытащу в отдельную ветку ибо ты ляпнул и не подумал.
Чтобы прочитать CSV файл надо его распарсить. Более того - в каждый кусок вставить заголовок, который идет первой строчкой. И после разбития на файлы тебя ждет ... повторный парсинг ( уже каждого куска ) !
Более того - для каждой строчки сделать валидацию на предмет того, что преобразование в целевой тип возможно и не нарушает его: скажем целевая строчка VARCHAR(200) а у тебя есть строка длиной 300, которую невозможно вставить без обрезания. Потом тебе результаты обработки ... мержить
Далее, тебе потребуется не 1 а 10 или 100 коннекций к базе, причем по сети польется уже 10-100 кратный поток данных через сетевой интерфейс, что забьет остальную работу.
Далее, целевая таблица как правило одна - т.е. сразу будут локи, если в нее запихивают данные 10-100 процессов одновременно, а если ты на каждый процесс создашь отдельную, то все равно потом мержить в одну.
Поздравляю - ты создал больше гемора чем ускорил
Татарин> Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да?
И засунуть их балками в SQL? И?Это я вытащу в отдельную ветку ибо ты ляпнул и не подумал.
Чтобы прочитать CSV файл надо его распарсить. Более того - в каждый кусок вставить заголовок, который идет первой строчкой. И после разбития на файлы тебя ждет ... повторный парсинг ( уже каждого куска ) !
Более того - для каждой строчки сделать валидацию на предмет того, что преобразование в целевой тип возможно и не нарушает его: скажем целевая строчка VARCHAR(200) а у тебя есть строка длиной 300, которую невозможно вставить без обрезания. Потом тебе результаты обработки ... мержить
Далее, тебе потребуется не 1 а 10 или 100 коннекций к базе, причем по сети польется уже 10-100 кратный поток данных через сетевой интерфейс, что забьет остальную работу.
Далее, целевая таблица как правило одна - т.е. сразу будут локи, если в нее запихивают данные 10-100 процессов одновременно, а если ты на каждый процесс создашь отдельную, то все равно потом мержить в одну.
Поздравляю - ты создал больше гемора чем ускорил
Это сообщение редактировалось 01.05.2021 в 09:41
с.т.>> значит у них есть потенциал по оптимизации.
yacc> Более чем есть.
yacc> Пенсионный фонд вложил 20 миллионов в развитие ПО для своих «Эльбрусов» - CNews
yacc> Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора.
yacc> Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
ага.
йопта они поняли что физмодель нужно дорабатывать, джонни_индексофф звать и всё такое...
yacc> Более чем есть.
yacc> Пенсионный фонд вложил 20 миллионов в развитие ПО для своих «Эльбрусов» - CNews
yacc> Через неделю соколиный глаз допер, что код, который хорошо работает на x64, проседает на VILW так как сильно не использует возможности процессора.
yacc> Или переведем с русского на русский - чтобы оптимизатор компилятора ( а он не всесильный ) задействовал возможности кучи регистров, код PostgreSQL ... надо править!
ага.
подрядчику предстоит создать индексы базы данных, которые обеспечат повышение производительности используемых запросов SQL,
йопта они поняли что физмодель нужно дорабатывать, джонни_индексофф звать и всё такое...
с.т.> йопта они поняли что физмодель нужно дорабатывать, джонни_индексофф звать и всё такое...
Так движки баз данных отличаются - что хорошо для DB2 ( в ядре System i ) то для постгре -смерть не очень.
Кстати подряд достался "Лантана текнолоджи" ... несколько странной фирме из Обнинска с "очень информативным" сайтом Лантана Текнолоджи
Так движки баз данных отличаются - что хорошо для DB2 ( в ядре System i ) то для постгре -
Кстати подряд достался "Лантана текнолоджи" ... несколько странной фирме из Обнинска с "очень информативным" сайтом Лантана Текнолоджи
Copyright © Balancer 1997..2024
Создано 03.05.2018
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 03.05.2018
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
