Сразу видно человека, который никакого отношения к менеджменту не имеет.
Рогозин - это ТОП-менеджмент нашей космонавтики. Не его задача искать кривые болты и разрабатывать чертежи ракет. Это совершенно другие отделы и люди. Фразу "разберитесь с аварийностью" ракет, уверяю, мог отдать (и отдал бы) абсолютно любой менеджер. Скажу больше, даже если бы его не было, как у нас заведено в стране, это сделал бы президент, и все порешалось точно также - какой-то инженер/отдел на месте разобрался бы в проблеме.
Задача Рогозина - строить процессы, направлять стратегию развития Роскосмоса, следить за выполнением стратегических направлений и т.д. И вот как раз все эти заявления и показывают стратегию развития, а, вернее, закапывания нашей космонавтики. Вот, в общем-то, и вся хурма.
Или есть яркие примеры, когда что-то было сделано от А до Я (ну хотя бы до Н) при нем?
А подскажите, какой сейчас практический смысл в использовании WebMoney? У меня остались воспоминания 20-летней давности, когда это было чуть ли не единственным электронным кошельком. Сейчас уже у каждого банка хоть какая-нибудь более-менее приличная среда для работы есть, тогда зачем все эти приседания с вебманями?
Ваши примеры выглядят как "систематическая ошибка выжившего". На C/C++ написано 98% всего критичного в мире разработки софта, логично, что в нем находят ошибки. Так-то можно сказать, что в этом году критический уязвимостей на языках Pascal и Пролог не найдено, значит, с ними все ок.
Go вон тоже был весь из себя такой безопасный, но как докер начали использовать везде, так и уязвимости поперли.
Да, в некоторых языках сложнее делать ошибки, в некоторых проще. В rust действительно делать ошибки сложнее, чем в плюсах. Но в мире плюсов для этого есть тесты, санитайзеры, ворнинги как ошибки, статичекие анализаторы, код-ревью и т.д. Если процессы в компании выстроены нормально, то и языковых ошибок почти нет.
Во-первых, лично вы при этом не пишете на C++, существенно сокращая поверхность кода, которому нельзя доверять.
Rust хороший язык, но в вашей фразе есть какая-то доля самообмана. Что значит нельзя доверять? Linux, Windows, Mac, PostgreSQL / MariaDB / sqlite / mongodb, nginx, haproxy, LLVM, Unreal Engine / Unity, TensorFlow и миллион другого супер важного софта написаны на C/C++. Это же не мифические гномы в вакууме пишут, вполне себе обычные разработчики, и как-то же они это пишут так, что я без головной боли все это использую.
Ну будем честные, код со всеми этими оптимизациями стал не слишком читаемым и поддерживаемым. Все-таки обычно мы бизнес-код пишем, а не олимпиадные задачи решаем и очки в бенчмарках набираем.
Потом, не только лишь все могут взять и проделать то, что проделывает автор. На рынке не то, чтобы очень много сеньоров, которые хотят в ассемблерном коде ковыряться фулл-тайм.
Насчет серверов. Если уж совсем быть честным, то на сервере мы можем поставить не десктопный корэ-ай-семь, а парочку AMD EPYC по 64 ядра каждый, и тут я даже не знаю, какие силы надо с Эльбрусом выставлять? Сразу ЦОД строить, чтобы сопостовимо было? Про цены этого сопоставления я вообще молчу.
Но даже если предположить, что мы тут хотя бы десктопных проц трехлетней давности пытаемся догнать, то чтобы результаты из статьи как-то заработали, надо еще nginx переписать под это дело, или TensorFlow, или v8, или какой-то еще софт. Будет Сысоев, интересно, nginx переписывать, чтобы на Эльбрусах все быстро было? Вопрос, конечно, риторический.
То есть да, какую-то работу они показывают. Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов, установить их и даже получить какие-то положительные результаты (вопросы о производстве пока отбросим). Но это ваще не конкуренция. Это вещь в себе, которая нужна на каком-то локальном рынке решать какие-то локальные проблемы без претензии на технологичность. Это как Москвич в автомобилестроении, жил, пока ничего другого не было, и сразу умер, как появилось. Мы опять идем по этому пути и опять придем к таким же результатам.
Перед тем, как начать разработку ПО обычно выбирают архитектуру.
Ой ли! Современный мир таков, что мы пишем продукт, а потом нам приходит осознание, что какая-то крупная компания выпустила, скажем, M1, и теперь наш продукт нужно собирать на ARM. И хочется, чтобы все проблемы ограничились настройкой тулчейна под целевую платформу. И это, кстати, отличный пример, как новый проц довольно быстро оброс софтом и большей произвоидельностью без таких уж сильных приседаний.
Ну и будем честны, вряд ли в общим случае какой-то разрабочик/компания скажут: "штош, начну-ка я пилить свой новый проект чисто под Эльбрус". Как я уже писал выше, кроме оборонки и некоторой госухи я больше никого не вижу.
А вот труд разработчиков ПО сильно подорожал.
Поэтому Эльбрус сделал платформу, в которой мы должны тратить время разработчика на оптимизации из приведенной Вами статьи? :)
Ну вы только в кучу всех не мешайте, пожалуйста. Хейтили Маска те, кто сейчас Эльбрус восхваляет. А те, кто говорил, что Маск вполне понятно и результативно развивается (что и было), говорят, что Эльбрус непонятно и нерезультативно развивается. SpaceX с 2002 года начала свой путь, и уже по запускам Россию обогнала, а МЦСТ свой путь начал в 1992, но догнать мы не можем даже десктопный процесс десятилетней давности (а уж про массовость и остальное я вообще молчу).
Конечно, делать выводы по нативному исполнению и эмуляции некорреткно, это понятно. Но эмуляция x86 для Эльбруса стратегически правильное решение, потому что есть куча софта, которые портировать не получится, а запускать надо.
Но основное сравнение: это все-таки нативный код для e2k и нативный код для x86.
Свидетели Отечественных Процессоров на Хабр ботов завезли, что ли?
Какой софт каким конкурентам будет проигрывать? Речь у нас про то, что софт под Эльбрус проигрывает по скорости конкурентам Intel, AMD и далее по списку. Рынок не у Эльбруса, чтобы он задавал тренды, если что :)
Под привычную нам архитектуру x86 большинство оптимизации делает компилятор, не разработчик. Эльбрусовский же компилятор за вас не делает ту работу, которая нужна дла VLIW процов. Есть даже инструкция, как с этим жить.
А то, что вы тут пишите про какие-то коллекции и поиски элементов за линию, говорит лишь о том, что вы вообще не понимаете, о чем тут речь и к чему все претензии. Алгоритмы и структуры данных работают одинаково на всех существующих платформах, потому что это математика.
Потому что можно использовать свежие SSE и прочие AVX-512, которые дают сильный буст на математике.
А использование всего оптимизационного добра на e2k хоть и дают сильный буст, но только в рамках их архитектуры - остальным они все равно сильно проигрывают. Поэтому ребята из magma и всех других расчетных софтов вряд ли будут пилить какую-то серьезную поддержку нашей архитектуры, потому что зачем? И отдел стратегического планирования МЦСТ должен это понимать: никакой массовости не будет, никто специально поддержку пилить не будет, значит, большинство кода на платформе будет использоваться as is.
Не очень понял, о чем Вы. Да, Эльбрус имеет бинарный транслятор, но это все-таки дополнительный бонус для историй, когда код под платформы по каким-то причинам пересобрать нельзя. Наверное, разработчиков в первую очередь интересует история, когда код собрать можно.
Ключи оптимизации являются инструментом компилятора, они, естественно, должны быть выбраны максимально эффективно для целевой платформы, но я говорю не про них.
В моем понимании "оптимизация" - это затачивание тестов под конкретную платформу. e2k архитектура подразумевает, что вы знаете о широкой команде, и стараетесь писать код так, чтобы эту широкую команду максимально заполнить для параллельной обработки. Если вы делаете так, вы действительно получаете сильный буст, но проблема в том, что 99.999% кода написано без оглядки на такие архитектуры, а, следовательно, никаких преимуществ вы тут не получите.
Поэтому интересны такие тестовые кейсы:
1) Мы берем любой стандартный бенчмарк и компилим код as is под x86 и e2k и смотрим, какая разница в попугаях. В подавляюшем большинстве это то, на что нужно смотреть, потому что вряд ли люди будут переписывать openssl или какой-нибудь jsoncpp.
2) Пишем максимально эффективный код для x86 и e2k и смотрим, насколько архитектура реально эффективно тащит задачу. Этот кейс ок, когда вы самые ресурсоемкие части своего продукта сразу пишите с оглядкой на платформу e2k. Не представляю, кому это, кроме МО РФ и некоторой госухе, надо.
И я на всякий случай напомню, что VLIW в Intel умер. Да и не только в Intel, были разные идеи сделать что-то похожее, потому как сама идея выглядит вполне себе ок, но на практике оказалось, что писать эффективный компилятор под этой дело крайне сложно, а заставить всех разработчиков быть умными и сразу писать эффектиный код под архитектуру не получилось.
Пацаны, я маслину поймал!Чики-брики, и в дамки!Ну, показывай, чем Зона наградила!Проходи, не задерживайся.Захреначу все синей изолентой.Мэн, убрал бы ты свои аргументы подальше.и т.д.
Жаль, вторая часть нас оставит без прекрасной озвучки фраз, которые разлетелись далеко за пределы Зоны.
Сразу видно человека, который никакого отношения к менеджменту не имеет.
Рогозин - это ТОП-менеджмент нашей космонавтики. Не его задача искать кривые болты и разрабатывать чертежи ракет. Это совершенно другие отделы и люди. Фразу "разберитесь с аварийностью" ракет, уверяю, мог отдать (и отдал бы) абсолютно любой менеджер. Скажу больше, даже если бы его не было, как у нас заведено в стране, это сделал бы президент, и все порешалось точно также - какой-то инженер/отдел на месте разобрался бы в проблеме.
Задача Рогозина - строить процессы, направлять стратегию развития Роскосмоса, следить за выполнением стратегических направлений и т.д. И вот как раз все эти заявления и показывают стратегию развития, а, вернее, закапывания нашей космонавтики. Вот, в общем-то, и вся хурма.
Или есть яркие примеры, когда что-то было сделано от А до Я (ну хотя бы до Н) при нем?
Еще интересно, сколько респондентов на hh.ru готовы получать аналоговые доллары вместо цифровых рублях.
Чтобы к 2025 нарастить темп по 75 самолетов А320 в месяц, им пришлось его сделать в 1987.
Все критичные модули же на LGPL, главное статически с ними не линковаться и все будет хорошо.
За 2021 год - 25 запусков.
В 2022 уже и непонятно, нужны ли нам хоть какие-то запуски.
В статьи описана уязвимость, после которой рука сама потянулась повышать карму автору :)
Ох, они еще живые.
А подскажите, какой сейчас практический смысл в использовании WebMoney? У меня остались воспоминания 20-летней давности, когда это было чуть ли не единственным электронным кошельком. Сейчас уже у каждого банка хоть какая-нибудь более-менее приличная среда для работы есть, тогда зачем все эти приседания с вебманями?
И винду и маком туда же, потому что они тоже C/C++. Чудом выживаем, можно сказать.
Ваши примеры выглядят как "систематическая ошибка выжившего". На C/C++ написано 98% всего критичного в мире разработки софта, логично, что в нем находят ошибки. Так-то можно сказать, что в этом году критический уязвимостей на языках Pascal и Пролог не найдено, значит, с ними все ок.
Go вон тоже был весь из себя такой безопасный, но как докер начали использовать везде, так и уязвимости поперли.
Да, в некоторых языках сложнее делать ошибки, в некоторых проще. В rust действительно делать ошибки сложнее, чем в плюсах. Но в мире плюсов для этого есть тесты, санитайзеры, ворнинги как ошибки, статичекие анализаторы, код-ревью и т.д. Если процессы в компании выстроены нормально, то и языковых ошибок почти нет.
Rust хороший язык, но в вашей фразе есть какая-то доля самообмана. Что значит нельзя доверять? Linux, Windows, Mac, PostgreSQL / MariaDB / sqlite / mongodb, nginx, haproxy, LLVM, Unreal Engine / Unity, TensorFlow и миллион другого супер важного софта написаны на C/C++. Это же не мифические гномы в вакууме пишут, вполне себе обычные разработчики, и как-то же они это пишут так, что я без головной боли все это использую.
Который использует бэкенд LLVM, который написан на C++. Огонь.
Ну будем честные, код со всеми этими оптимизациями стал не слишком читаемым и поддерживаемым. Все-таки обычно мы бизнес-код пишем, а не олимпиадные задачи решаем и очки в бенчмарках набираем.
Потом, не только лишь все могут взять и проделать то, что проделывает автор. На рынке не то, чтобы очень много сеньоров, которые хотят в ассемблерном коде ковыряться фулл-тайм.
Насчет серверов. Если уж совсем быть честным, то на сервере мы можем поставить не десктопный корэ-ай-семь, а парочку AMD EPYC по 64 ядра каждый, и тут я даже не знаю, какие силы надо с Эльбрусом выставлять? Сразу ЦОД строить, чтобы сопостовимо было? Про цены этого сопоставления я вообще молчу.
Но даже если предположить, что мы тут хотя бы десктопных проц трехлетней давности пытаемся догнать, то чтобы результаты из статьи как-то заработали, надо еще nginx переписать под это дело, или TensorFlow, или v8, или какой-то еще софт. Будет Сысоев, интересно, nginx переписывать, чтобы на Эльбрусах все быстро было? Вопрос, конечно, риторический.
То есть да, какую-то работу они показывают. Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов, установить их и даже получить какие-то положительные результаты (вопросы о производстве пока отбросим). Но это ваще не конкуренция. Это вещь в себе, которая нужна на каком-то локальном рынке решать какие-то локальные проблемы без претензии на технологичность. Это как Москвич в автомобилестроении, жил, пока ничего другого не было, и сразу умер, как появилось. Мы опять идем по этому пути и опять придем к таким же результатам.
Ой ли! Современный мир таков, что мы пишем продукт, а потом нам приходит осознание, что какая-то крупная компания выпустила, скажем, M1, и теперь наш продукт нужно собирать на ARM. И хочется, чтобы все проблемы ограничились настройкой тулчейна под целевую платформу. И это, кстати, отличный пример, как новый проц довольно быстро оброс софтом и большей произвоидельностью без таких уж сильных приседаний.
Ну и будем честны, вряд ли в общим случае какой-то разрабочик/компания скажут: "штош, начну-ка я пилить свой новый проект чисто под Эльбрус". Как я уже писал выше, кроме оборонки и некоторой госухи я больше никого не вижу.
Поэтому Эльбрус сделал платформу, в которой мы должны тратить время разработчика на оптимизации из приведенной Вами статьи? :)
Ну вы только в кучу всех не мешайте, пожалуйста. Хейтили Маска те, кто сейчас Эльбрус восхваляет. А те, кто говорил, что Маск вполне понятно и результативно развивается (что и было), говорят, что Эльбрус непонятно и нерезультативно развивается. SpaceX с 2002 года начала свой путь, и уже по запускам Россию обогнала, а МЦСТ свой путь начал в 1992, но догнать мы не можем даже десктопный процесс десятилетней давности (а уж про массовость и остальное я вообще молчу).
У автора статьи тесты собраны как нативно под платформу, так и с бинарной трансляцией. Тут можно поискать со словом RTC: https://github.com/EntityFX/anybench/tree/master/results
Конечно, делать выводы по нативному исполнению и эмуляции некорреткно, это понятно. Но эмуляция x86 для Эльбруса стратегически правильное решение, потому что есть куча софта, которые портировать не получится, а запускать надо.
Но основное сравнение: это все-таки нативный код для e2k и нативный код для x86.
Свидетели Отечественных Процессоров на Хабр ботов завезли, что ли?
Какой софт каким конкурентам будет проигрывать? Речь у нас про то, что софт под Эльбрус проигрывает по скорости конкурентам Intel, AMD и далее по списку. Рынок не у Эльбруса, чтобы он задавал тренды, если что :)
Под привычную нам архитектуру x86 большинство оптимизации делает компилятор, не разработчик. Эльбрусовский же компилятор за вас не делает ту работу, которая нужна дла VLIW процов. Есть даже инструкция, как с этим жить.
А то, что вы тут пишите про какие-то коллекции и поиски элементов за линию, говорит лишь о том, что вы вообще не понимаете, о чем тут речь и к чему все претензии. Алгоритмы и структуры данных работают одинаково на всех существующих платформах, потому что это математика.
Потому что можно использовать свежие SSE и прочие AVX-512, которые дают сильный буст на математике.
А использование всего оптимизационного добра на e2k хоть и дают сильный буст, но только в рамках их архитектуры - остальным они все равно сильно проигрывают. Поэтому ребята из magma и всех других расчетных софтов вряд ли будут пилить какую-то серьезную поддержку нашей архитектуры, потому что зачем? И отдел стратегического планирования МЦСТ должен это понимать: никакой массовости не будет, никто специально поддержку пилить не будет, значит, большинство кода на платформе будет использоваться as is.
Не очень понял, о чем Вы. Да, Эльбрус имеет бинарный транслятор, но это все-таки дополнительный бонус для историй, когда код под платформы по каким-то причинам пересобрать нельзя. Наверное, разработчиков в первую очередь интересует история, когда код собрать можно.
Или о чем был комментарий?
Ключи оптимизации являются инструментом компилятора, они, естественно, должны быть выбраны максимально эффективно для целевой платформы, но я говорю не про них.
В моем понимании "оптимизация" - это затачивание тестов под конкретную платформу. e2k архитектура подразумевает, что вы знаете о широкой команде, и стараетесь писать код так, чтобы эту широкую команду максимально заполнить для параллельной обработки. Если вы делаете так, вы действительно получаете сильный буст, но проблема в том, что 99.999% кода написано без оглядки на такие архитектуры, а, следовательно, никаких преимуществ вы тут не получите.
Поэтому интересны такие тестовые кейсы:
1) Мы берем любой стандартный бенчмарк и компилим код as is под x86 и e2k и смотрим, какая разница в попугаях. В подавляюшем большинстве это то, на что нужно смотреть, потому что вряд ли люди будут переписывать openssl или какой-нибудь jsoncpp.
2) Пишем максимально эффективный код для x86 и e2k и смотрим, насколько архитектура реально эффективно тащит задачу. Этот кейс ок, когда вы самые ресурсоемкие части своего продукта сразу пишите с оглядкой на платформу e2k. Не представляю, кому это, кроме МО РФ и некоторой госухе, надо.
И я на всякий случай напомню, что VLIW в Intel умер. Да и не только в Intel, были разные идеи сделать что-то похожее, потому как сама идея выглядит вполне себе ок, но на практике оказалось, что писать эффективный компилятор под этой дело крайне сложно, а заставить всех разработчиков быть умными и сразу писать эффектиный код под архитектуру не получилось.