Тренер альпинструкторов объяснил ошибки гидов в трагедии на Эльбрусе
Тренер Центральной школы инструкторов альпинизма, инструктор по альпинизму второй категории Денис Кисилев оценил действия гидов во время восхождения на Эльбрус, где группа туристов оказалась в ловушке в плохую погоду и не смогла самостоятельно спуститься с горы после полученной травмы у одной из туристок.
«Я считаю, что действия уже в ходе восхождения, наверное, и правильные были. А вот мотивация выхода в таких условиях, вызывает вопрос. Если группа знала о прогнозе погоды, то я так скажу: многие группы отказались бы от восхождения. Это факт. Думаю, что прогноз у них был, это логика восхождения, тем более в межсезонье«, – заметил руководитель альпклуба в беседе с РЕН ТВ.
Решение штурмовать Эльбрус в тех погодных условиях, что установились на горе в день трагедии, Кисилев назвал «однозначным риском».
«То, что участнице стало плохо настолько высоко, это, на мой взгляд, был однозначно упущенный момент. Очень мало времени прошло с того момента, когда с этой туристкой решили спускаться, до ее гибели. Это горы, конечно, там все обостряется быстро, но все же должны были бы быть предпосылки. Видимо, им не предали внимания. Какие-то тоже были моменты явно, по которым можно было следить за погодой и свернуть вниз раньше. Это вопросы к ребятам, что вели группу, почему они этого не сделали», – заметил Кисилев.
По словам тренера инструкторов альпинизма, решение руководителя спускать туристку, которой стало плохо, абсолютно верное, однако, вероятно, следовало было также задуматься о том, чтобы спускать вниз всю группу.
«Обычно сигнал бедствия получают, когда погода уже испортилась. Тут вопрос не стоит уже о выживании. В этих условиях мы все чаще всего умные задним умом. Там люди боролись за свою жизнь и, думаю, участники сделали все, что могли в тех условиях. Но по факту бороться за жизнь участников надо до того, как такое происходит. Это вопрос профессионализма людей, какого-то чутья», – рассказал руководитель альпинистского клуба из Петербурга.
Источник
Процессор Эльбрус — почему статья о тупике несостоятельна
На протяжении почти двух десятилетий рунет пестрит различными негативными статьями об Эльбрусах. В течение последних десяти лет я наблюдал развитие риторики с «существует только в виде .jpeg» до «дорогой и медленный». В основном вся эта риторика исходит от людей, которые машину в глаза не видели, и тратить время на ответы таким людям смысла не имеет. Но недавно на Хабре вышла довольно резонансная статья про тупиковость развития Эльбруса. В целом она не отличается от общей массы таких статей (состоит из манипуляций и ошибок), но кое-что в ней заставило меня написать ответ.
Сейчас в России наблюдается чёткое движение в сторону импортозамещения, что, безусловно, не может не радовать. А последние несколько лет мы можем отметить реальные результаты в виде потери крупными иностранными игроками больших долей на российском рынке. Разумеется, такие успехи нравятся не всем, и лоббисты стремятся переписать правила игры прямо на ходу. И вот, в это непростое время @Armmaster, бывший сотрудник МЦСТ, ныне сотрудник одного из страдающих крупных иностранных игроков публикует статью в лучших антиэльбрусовских традициях. С учётом личности автора моё чувство справедливости настолько ущемилось, что я решил разобрать статью бывшего коллеги.
Собственная архитектура
Парадокс в том, что это большой недостаток. Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям.
На текущий момент наиболее распространённой архитектурой процессоров общего назначения является x86_64. Существует ещё несколько популярных архитектур, но пока что никто из них не вышел в нишу настольных компьютеров, а в серверном сегменте сдвиги только начинаются. В момент продвижения архитектуры ARM все дружно двинулись переносить своё ПО на него, никто не говорил, что собственная архитектура — это плохо. Сейчас в Европе активно продвигается RISC-V, но никто не плачет о новой несовместимой архитектуре — все дружно берут и переносят своё ПО. Но почему-то как только речь заходит про архитектуру Эльбрус, сразу начинаются стоны о том что своё — это плохо и сложно. Тут, как вы поняли, эталонное «это другое».
А теперь посмотрим на факты. Сейчас для Эльбруса существует несколько дистрибутивов GNU/Linux, для примера рассмотрим АльтЛинукс. На текущий момент в нём портировано более 14500 пакетов. При этом исправлений, по заявлению разработчиков, потребовало около 1% пакетов от общего количества. Это не считая многочисленных статей даже на хабре о переносе проектов под Эльбрус (легко ищется прямо на сайте). По отзывам в случаях отсутствия архитектурно-зависимого (т. е. ассемблерного) кода, перенос на платформу совершается гладко благодаря хорошей совместимости эльбрусовского компилятора с gcc. Таким образом, заявление об излишней (!) сложности выглядят сомнительно при взгляде на цифры.
А теперь вспомним что существует ПО без исходного кода, которое способно запускаться только на x86 машинах. Процессоры Эльбрус такое ПО запускать умеют. Могут ли другие не-x86 процессоры похвастаться этим же? Просто удивительно как автор смог преподнести настолько уникальную возможность (над которой он сам работал) как недостаток. Аплодирую стоя.
VLIW-архитектура
Сначала приведу разбор узких технических моментов, потом пройдёмся по более общим высказываниям.
Пришедший указатель или сложная работа с памятью — и вы не можете спланировать Load выше операции Store (и наоборот).
В области разработки компиляторов существует целое направление, занимающееся решением именно этой проблемы — анализ указателей (на самом деле это два направления, но не будем лезть в подробности), которое «разрывает зависимости» между операциями. Наличие операций Load/Store — не приговор, необходимо анализировать код. Всегда ли возможно разорвать зависимость? Конечно же нет, более того это довольно сложно. Получается ли разрывать зависимости на практике? Да, получается, много где. Более того, в Эльбрусе разрыв зависимостей возможен не только во время компиляции, но и во время исполнения. Одним из таких механизмов является DAM, позволяющий аппаратно разрывать зависимости, которые не смог порвать компилятор.
Если в горячем цикле есть вызов функции — его надо обязательно заинлайнить, иначе мимо него нельзя будет ничего поднять вверх и тем более применить критически важную оптимизацию конвейеризации цикла. Но при компиляции без профиля установить какие циклы горячие невозможно
И снова неверное утверждение. Точнее, верное только отчасти. Подстановка вызовов (inline) действительно является одной из важнейших оптимизаций, и не только для VLIW архитектур, а вообще для всех. Только вот компилятор вполне способен определить горячие участки с неплохой вероятностью, и в дальнейшем их оптимизировать. Такой механизм называется «предсказание профиля», он работает на основе анализа кода и определённого количества эвристик. Этот механизм есть и в других компиляторах, но полагаю что в компиляторе Эльбруса он развит лучше ввиду его необходимости. Кстати, даже если процедуру не удалось подставить, не обязательно что её нельзя «поднять вверх». В компиляторе существует оптимизация выявления функций без побочных эффектов, которая даёт определённую свободу действий.
Но это стоит транзисторов, перформанса и всё равно имеет много ограничений для применения в реальности. … И хотя это стоит определённых транзисторов и мощности, на выходе такой подход оказывается более эффективным
Там транзисторы — плохо, тут хорошо. Ну вы поняли.
Кстати, про профиль следует понимать ещё одну любопытную вещь. Последние лет пять (даже больше) в основных компиляторах (gcc, llvm) очень активно ведётся разработка использования профиля для улучшения оптимизаций — PGO (Profile Guided Optimizations). И это делается именно для RISC/CISC + OoO + Branch Prediction процессоров. Т.е. почему-то разработчики считают что «их замечательные транзисторы» недостаточно замечательные, и им нужна помощь в виде поддержки компилятора, двухпроходной компиляции и всех прочих прелестей этого замечательного режима. Так что возможно заявления о том, что всё решается транзисторами не такие уж и верные.
Архитектура Эльбрус крайне плохо исполняет код, если в нём появляются не заинлайненные вызовы функций. В таком случае производительность может падать на порядок
Это действительно так. Только вот автор приводит полностью синтетический пример, который в реальности попросту не встречается. На практике проблемы с подстановкой функций будут встречаться, если вызываемая в горячем коде функция располагается в другом модуле, и компилятор не видит её тело. Что ж, я за такой код бил бы линейкой по пальцам независимо от целевой платформы.
Ну и снова стоит напомнить, что эта проблема свойственна не только для VLIW архитектур (хотя в этом случае плохой код даёт бОльшие штрафы), но и вообще всем. Поэтому в компиляторах активно разрабатывается технология межмодульных оптимизаций LTO (Link Time Optimization), направленная на решение именно этой проблемы. Кстати, по умолчанию Rust компилируется как раз с включённым lto.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать
1 такт, не отличаясь принципиально от случая, если инлайн сработал
Тут снова фактическая ошибка, на которую автору указали в комментариях. Более того он сам сказал что не получал такого результата, и это его предположение. Т.е. приводя сравнение, автор просто взял цифру с потолка. Кстати, эти три такта, которые он получил тоже будут только в хороших случаях, в общем случае нам понадобится не менее 4 тактов.
Но минимальное усложнение кода, например, путем добавления бОльшего числа команд в функцию, легко сломает логику работы инлайна в реальной жизни
Даже не знаю что тут сказать. Очень хотелось бы таких примеров из реальной жизни, а не из синтетического примера (хотя и тут не представляю, что для этого нужно сделать). Могу только сказать, что подстановка функций — одна из самых важных и сложных оптимизаций в компиляторе. Она постоянно дорабатывается, в ней исправляются ошибки, улучшаются эвристики. Я даже знаю как сделать «плохие» примеры для конкретной версии компилятора, только вот в реальной жизни как раз всё обычно весьма неплохо.
Как видно, VLIW-процессоры на тех же нанометрах, имеют меньшие тактовые частоты, при этом имеют более высокое тепловыделение и больше транзисторов
Не знаю на кого рассчитана эта фраза с учётом, того что в той таблице нет других процессоров с теми же нанометрами (только Эльбрус другой линейки). И нет, из этой таблицы нельзя сделать вообще никаких выводов — чистая манипуляция.
В итоге VLIW процессоры проигрывают не только по микроархитектурной скорости в пересчёте на Герцы .
Добрый день, а это то откуда следует? Ни одной цифры для подобных выводов вообще не приведено в статье.
Кстати, напомню, что статья была посвящена отечественным процессорам. А теперь попробуйте найти хоть одно сравнение с ними. Т.е. автор заявляет одну тему статьи, в теле приводятся несравнимые, местами неверные и выдуманные данные, делаются далекоидущие выводы. Ладно, от мелких узкотехнических ошибок пойдём к более глобальным и весёлым.
Потому что если на небольших бенчмарках или тем более Spec2006/2017 (которые вылизывали 20+ лет) компилятор худо-бедно справляется и может сгенерировать близкий к оптимальному код, то на реальных проектах он уже не справляется, а т.к. аппаратура тут подстраховать не может, то производительность падает в разы
Ну что ж, давайте посмотрим реальные проекты. Вот из свеженького: «По результатам тестов можно сделать вывод о том, что процессор «Эльбрус-8СВ» успешно решает задачу построения системы хранения данных и позволяет получать достойные результаты на HDD». Или даже на хабре: «Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86-64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86-64 с AVX2 — в 1.3 раза (для 5 поколения)», «В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза», и ещё несколько интересных сравнений прямо в статье. Можно приводить примеры и дальше, но в целом это высказывание выглядит особенно забавно на фоне оттачиваемого десятилетиями ПО под x86.
Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением
Вообще, когда говорят о производительности ВК (вычислительных комплексов), существуют общепризнанные тесты, на результаты которых принято ссылаться. Например, ни один профессионал не сошлётся на результаты теста drystone или whetstone — его просто на смех поднимут. Если мы говорим про производительность на широком круге задач, то не существует набора тестов лучше чем SPEC CPU2017 или его более старой версии 2006 года. Эти тесты представляют из себя подборку популярных приложений, например bzip2, perl, blender и т. п.
Т.к. мы говорим про отечественное процессоростроение, то сейчас единственным сумевшим приблизиться к Эльбрусам процессором является Байкал M1000. С ним и будем сравнивать.
Все сравниваемые процессоры имеют по 8 ядер, выполнены по топологии 28 нм. Запуск производился на одном процессоре в режиме 8 потоков (т.е. измеряется скорость работы 8 параллельно запущенных задач). Результат измеряется в спековских «попугаях», чем выше значение — тем выше производительность.
Источник
Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU
Последние месяцы ознаменовались бурными баталиями в отечественной индустрии разработки микроэлектроники и причастных. Государство, наконец-то пристально обратив своё око на данную, мягко скажем крайне проблемную отрасль, посулило крупные инвестиции на её развитие, в первую очередь на разработку мозга любой вычислительной техники — процессора. Прения по поводу того, как правильно потратить выделенные средства, из тишины министерских кабинетов выплеснулись наружу и дошли до прессы. Не вдаваясь в политические моменты, всегда присущие такого рода дебатам, хотелось бы сконцентрироваться на технической стороне вопроса и обрисовать позицию, почему ставка на легендарный микропроцессор Эльбрус — это тупик для развития отечественного процессоростроения.
Российское процессоростроение, в силу понятной специфики зарождения и функционирования последних лет в основном на военных и окологосударственных заказах, критически страдает от отсутствия сколь либо открытой и доступной общественности, и при этом профессиональной дискуссии. Безусловным прорывом в данном вопросе можно считать проведение Elbrus Tech Day:
Жаль, что это происходит с примерно 15-ти летним опозданием, но лучше поздно, чем никогда. Результатом такой закрытости является нагромождение мифов вокруг Эльбруса, где антагонисты утверждают, что Эльбрус это просто старые процессоры Итаниум с переклеенными шильдиками, а сторонники рассказывают о супер архитектуре и гениальных компиляторщиках, которых не смог переманить Интел, благодаря чему Эльбрус имеет ни с чем не сравнимую производительность. Правда лежит в параллельной реальности, поэтому сначала несколько тезисов в качестве ликбеза для широкой публики, не столь глубоко знакомой с темой процессоров.
Микропроцессоры архитектуры Эльбрус (e2k) — это абсолютно аутентичная разработка компании МЦСТ, основанная на предыдущем опыте создания линейки Эльбрусов 1/2/3 ещё в СССР.
Компания МЦСТ также разрабатывает линейку процессоров с архитектурой Sparc V9. В названии данные процессоры также имеют слово Эльбрус, что часто вызывает путаницу. Все дальнейшие рассуждения относятся именно к VLIW-архитектуре Эльбрус (e2k), а не к Sparc V9.
Самые популярные в мире процессоры на данный момент от Intel и Arm — это представители CISC и RISC архитектуры.
Создание процессора можно в первом приближении разделить на разработку процессора и производство. Компания, которая только разрабатывает процессор, но для производства использует чужие мощности, называется «фаблесс». МЦСТ — это фаблесс разработчик процессоров. Как и абсолютное большинство дизайн-центров в мире, включая Apple, Qualcomm, Nvidia, HiSilicon и т.д. и т.п.
В России на данный момент нет заводов по производству процессоров, которые пригодны для производства сколь-либо современных процессоров топ-уровня. Кому интересно актуальное состояние данной отрасли, можно почитать здесь. Дальше все претензии и обсуждения на тему «а производят-то на Тайване!» здесь не принимаются. Статья касается только вопроса разработки процессоров.
Сама по себе разработка высокопроизводительного процессора любой архитектуры — крайне сложная инженерная задача
При обсуждении микропроцессоров крайне важно понимать различие между Архитектурой и Микроархитектурой. Говоря простыми словами, Архитектура процессора — это набор команд, который предоставляет аппаратура для использования софтом, иначе говоря интерфейс между миром ПО и миром железа. Микроархитектура — это то, как процессор устроен внутри, т.е. каким образом он реализует предоставленные Архитектурой интерфейсы. В современных процессорах именно микроархитектура является ключевым фактором достижения производительности. Именно из-за неё разные процессоры линейки x86 или Arm, реализующие одинаковую архитектуру, при схожих параметрах тактовой частоты могут в разы отличаться по производительности.
Так в чём же проблема Эльбруса? Если не углубляться в кучу технических и не очень нюансов, их две основных:
Собственная архитектура
Интересно, что руководство МЦСТ всячески пиарит данный пункт, выставляя его в качестве преимущества. Парадокс в том, что это большой недостаток. Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям. А это колоссальные затраты, тем более для VLIW-архитектуры (об этом ниже). В МЦСТ это прекрасно понимают (несмотря на публичные заявления о собственной архитектуре как о достоинстве) и именно поэтому в Эльбрусе на аппаратном уровне сделана поддержка бинарной трансляции из x86, что означает потенциальную возможность запускать привычные пользователю программы без какого-либо портирования. Но это стоит транзисторов, перформанса и всё равно имеет много ограничений для применения в реальности. В итоге можно сказать, что создание процессора с собственной архитектурой должно иметь крайне веские обоснования, иначе это получение колоссального геморроя на ровном месте. Да, к сожалению мы не можем делать аналог x86. Да, с лицензированием Arm есть потенциальные угрозы. Но любая лицензионно чистая открытая RISC/CISC архитектура здесь будет лучше, потому что увеличивает коммьюнити, занимающееся портированием софта.
VLIW-архитектура
Главная техническая проблема. Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением.
Тут требуется немного технического погружения. Основная идея VLIW заключается в том, что компилятор должен создать максимально оптимальный код, который железо просто исполнит, неукоснительно следуя тому, как компилятор создал широкие команды. Широкими команды как раз называются потому, что компилятор помечает операции, которые можно исполнить независимо, и планирует их в одну команду, которую процессор может исполнить за такт. Например, вот так:
В то же время процессоры RISC/CISC архитектуры логически получают инструкции как бы по одной, но само железо может в процессе исполнения проанализировать поток инструкций и перемешать их, если это возможно.
Идея VLIW на первый взгляд выглядит красиво, но она разбивается о реальность. В реальной жизни невозможно статически проанализировать код настолько, чтобы максимально плотно упаковать широкие команды. Пришедший указатель или сложная работа с памятью — и вы не можете спланировать Load выше операции Store (и наоборот). Если в горячем цикле есть вызов функции — его надо обязательно заинлайнить, иначе мимо него нельзя будет ничего поднять вверх и тем более применить критически важную оптимизацию конвейеризации цикла. Но при компиляции без профиля установить какие циклы горячие невозможно. Да и наличие профиля плохо помогает в случае динамической линковки, динамических вызовов, отсутствия ярко выраженного горячего кода. Опять-таки, сколь-либо сложное управление в цикле препятствует его накрутке.
В то же время классические RISC/CISC архитектуры с OoO автоматически оптимизируют и конвейеризируют любой исполняемый код. И хотя это стоит определённых транзисторов и мощности, на выходе такой подход оказывается более эффективным.
Например, чтобы получить некоторую интуицию проблемы с инлайном, не погружаясь сильно глубоко в сложные технические детали, давайте рассмотрим простейший синтетический код:
Архитектура Эльбрус крайне плохо исполняет код, если в нём появляются не заинлайненные вызовы функций. В таком случае производительность может падать на порядок.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать
1 такт(P.S. после публикации статьи проверка на реальном коде показала 3 такта), не отличаясь принципиально от случая, если инлайн сработал.
Чтобы хоть как-то решать возникающие проблемы в VLIW архитектуру приходится добавлять различные, иногда достаточно нетривиальные архитектурные фичи. Нужно иметь много архитектурных регистров, т.к. требуется хранить большое количество промежуточных результатов вычислений. Как следствие, аппаратура получается сложной (а от этого как раз хотели уйти) и в итоге падают частоты, на которых VLIW-процессор может работатать. Вот сравнение самых топовых решений процессоров на базе VLIW-архитектур от Intel и МЦСТ с их RISC/CISC аналогами:
Источник