В ИСС испытывают новую БЦВМ

[SGS_67]

TAU пишет:

SGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

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

Приведите пример такого непотребства.
Именно ваш Леон как раз под него подходит, но это стрела, летящая в вашу же сторону.
Поскольку он поддерживается Гайслером, и более никем, по причине более чем ограниченной востребованности.
Но даже для него gcc и набор драйверов для бесплатных IP корок существует.
А вот хотя бы компилятор Модула-2 - увы.    
Придётся ипатиться, как бы снова не через "ANSI C", то бишь, через корму.

 А в космосе, ежели чего - "у каждой ошибки есть имя и фамилия" - с кого спрашивать?
Не годится, в общем, по большому счету использовать инструменты без конкретной поддерживающей "конторы".

Да я как раз не против этого, а за.
Но только позу рак при этом принимать не обязательно.
Ни вам, ни поддержке.

ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Даже в Вашем или моём планшете или смартфоне напихано технологий столько, что ИСС и не снилось. 
И это всё как-то работает

Во-первых, мне снилось. Во-вторых, вот именно что как-то .

Я с ходу могу назвать пару, которая не снилась ни ИСС, ни даже Вам.

А как работает... вот у меня смартфон тайваньской HTC более, чем 5-летней давности.
Сбоя, зависания, или ещё какого-нибудь глюка не было ни разу, при весьма интенсивном использовании не только в качестве телефона.
При том, что сложность ПО там никак не меньше сложности ПО ИСС.

[Echidna]

SOE пишет:

Echidna пишет:
Даже при использовании процессоров 10-15 летней давности работа всего БПО наверняка занимает не больше 3-4 процентов процессорного времени

15-30%, на тех 6 разных весьма аппаратах, с которыми работал последние годы.
Что не мешает "вылезать" за пределы реального времени изредка, в ситуациях не протестированных в реалистичных условиях. Но это проблема разработки конкретного ПО, более-менее реальные проблемы по ресурсам вылезают редко (могу припомнить только ATV и Bepi) и они все же решаемы тоже.

30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%. :-) На тех трех аппаратах для которых я делал ПО, мы не вылазили за 10% в самых нагруженных режимах. Но тут, конечно, все от задач зависит, которые возложены на БЦВМ.

[Not]

SGS_67 пишет:

TAU пишет:

SGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

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

Приведите пример такого непотребства.

OpenSSH Heart Bleed.

SGS_67 пишет:
ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Можно, только что вы будете делать с этими миллионами строк кода?

SGS_67 пишет:
А как работает... вот у меня смартфон тайваньской HTC более, чем 5-летней давности.

Еще один мечтатель со смартфоном.

Смартфоны и бортовое ПО - это разные непересекающиеся области. В бортовом ПО главное - надежность и предсказуемость, причем не только в нормальных условиях, но и в проблемных.

[dmitryskey]

Добавлю свои пять копеек, почему подход ИСС по крайней мере разумен. При наличии в конторе сложившейся методологии разработки и тестирования (в данном случае на Модула-2) гораздо проще, надежнее и дешевле при переходе на новую аппаратную базу перерабатывать toolchain и адаптировать его к новым платформам, чем переписывать код. Тут ещё вот какой момент - если твои миллионы (как указано выше) строк кода покрыты программными (понятно, что в случае ИСС еще на платформе гоняют) тестами - то и критерий успешности перехода очень простой - проходят ли эти тесты или нет (при смене языка нужно и тесты скорее всего перерабатывать - и нет гарантии, что тут не наложатся ошибки), в общем случае другие ошибки в том же компиляторе уже не критичны. Приведу пару примеров из похожих ситуаций

• Математические расчеты. Большая часть кода в библиотеках (а он по прежнему тут вне конкуренции) написан на древнем как дерьмо мамонта Фортране IV/66. Если кто не в теме - это когда текст набивался на перфокартах шириной то ли в 40, то ли в 80 символов, комментарий начинался с буковки С, а о процедурном программировании мало кто слышал. Поддерживать такой код по нынешним временам невозможно - только его авторы могли разобраться в этих "макаронинах", но многие из них уже попросту умерли. Было несколько попыток автоматического трасформирования в тот же С - и все без толку. В моем понимании - garbage in - garbage out, если код на фортране нечитаем, то и полученный код на С (да и хоть на Java) таким же и останется. Но это не является проблемой - все нынешние компиляторы Фортрана без проблем поддерживают древние стандарты, с оптимизацией кода едва ли затруднения есть - для парсера нет разницы, удобен ли исходный текст для человека, все-равно все преобразуется в промежуточный формат AST. Сколько раз компиляторщики переходили (точнее, делали кодогенераторы) на новые платформы - страшно и подумать. И я так понимаю, каждый раз они просто прогоняли тесты на регрессии, и это вполне работало.
• Когда Facebook только начинался, писали его по быстрому на PHP. Опять-таки - если кто не в теме - язык ну ни разу не предназначенный для высоконагруженных систем. И они не стали переписывать все с нуля - а наняли очень толковых компиляторщиков (с их деньгами это было сделать легко), которые сделали им вначале HipHop-транслятор PHP->C++, а потом  и полноценный HipHop JIT компилятор. И тут они не сильно заморачивались общей поддержкой PHP, было достаточно, что работает на их собственной кодовой базе.
• Исторически JavaScript был простым скриптовым языком, созданным на заре интернета Netscape буквально на коленке, и не счесть попыток замены его на что-то более приличное. Но в итоге в 2008 году Google сделал JIT компилятор V8, быстро после этого подтянулись Mozilla, Microsoft и Apple. То бишь снова оказалось проще toolchain улучшить.
  

Собственно, ровно то же самое сделал ИСС в 2000-2003 году (как уже Not упоминал в рамках договора  №109, (кросс-система программирования на языке Модула-2 для OBC-1750 (с участием ООО "Эксельсиор" )) , да и где гарантия, что они потом просто не прикрутили к GCC кодогенератор для OBC-1750 и перешли на GNU Modula-2? Кстати в этом случае спор совсем становится схоластическим, это просто дискуссия gcc vs GCC.

И еще замечание про кросс-компиляцию. Если транслятор Modula-2->Ansi C дает код, что удовлетворяет требованиям на скорость исполнения в Real-Time - то ИСС можно было дальше и не улучшать ничего. Опять-таки, такие трансляции не так уж и безнадежны, транслятор С->Asm.js по оценкам Мозиллы работает всего в два раза медленнее родного кода - а тут ведь пусть и подмножество, но все-равно JavaScript.

[Павел Фишер]

Not пишет:
OpenSSH Heart Bleed.

Очень хороший пример того, какие баги могут всплыть в НЕПОДДЕРЖИВАЕМОМ проекте. Ну и OpenSSL, а не OpenSSH...  На момент появления бага в кодовой базе, в проекте было всего 2 человека на полной занятости, да и то, они занимались не развитием кода, а зарабатыванием денег на поддержание инфраструктуры. Ревью пулреквестов не делалось, и банальная непроверка входных параметров, пропущенная студентом (без шуток, код был написан студентом), привела к компрометированию многих серверов.

[Павел Фишер]

Не соглашусь с теми, кто говорит, что ИСС поступает верно, оставаясь на модуле. Я не в курсе полной ситуации на рынке ПО для спутников, но то, что я видел/слышал/щупал/писал - это С. Если ИСС останется единственным, кто будет использовать Модулу и ее инфраструктуру, то они рискую вляпаться в неприятные ситуации. Например когда все знающие уйдут, а новые, посмотрев на код, не захотят работать. Или когда ошибки будут возникать из ниоткуда (просто когда никому в голову не приходит, что что-то может пойти по-другому). Еще и скорость разработки и качество машинного кода будут падать по сравнению с конкурентами. Ведь мир С не стоит на месте, а вот ИСС замерло.
Теперь к примерам от dmitryskey. Тут не совсем верна интерпретация.
Про мат либы. Тут самая обычная проблема легаси кода. Есть много библиотек, много людей, которые с ними работали. Чтобы переписать это все на С, нужно очень много времени, потом нужно избавиться от детских болезней, заняться оптимизацией алгоритмов, написать кучу документации, переобучить народ. Поэтому это все идет, но очень медленно. Опять же тут играет роль еще и фактор смены вычислительной платформы (ГПУ и ускорители типа Xeon Phi). Так что со временем все либы на фортране вымрут.
Про фейсбук. Ситуация была такой. Сайт "выстрелил". В этот момент нужно иметь возможность очень быстро скалировать производительной горизонтально (больше серверов). Если в этот момент начать все переписывать - то проще закрыть проект сразу. Поэтому написание HipHop в данных условия выглядит абсолютно разумно. Ну и пхп не стоит на месте. В 7ой версии он уже не вызывает рвотных рефлексов.
Про JavaScript. Тут в корне не верно толкование. Изначально язык создался за несколько часов (кроме шуток, на самом деле), чтобы не допустить внедрения VisualBasic в качестве стандартного языка для скриптов на страницах. Много позже, когда страницы уже не были статическим текстом, возникла потребность заменить интерпретируемые скрипты на что-нить более быстрое. Это можно было сделать через внешнюю зависимость (Java Applets) или внутреннюю, когда скрипты компилировались браузером (V    , тогда привычный язык программирования можно не заменять. Второй вариант вышел победителем.

[dmitryskey]

Я полагаю, что обе точки зрения, в общем-то, правы, речь идет только о горизонте планирования. Если брать ближне-среднюю перспективу - то подход ИСС лучше, на дальнюю - желательнее, конечно же, на более стандартную ветвь развития уходить. Только едва ли в ИСС (как и вообще в российской космонавтике) так уж далеко планируют. В этом смысле я все-таки стою на том - если оно работает - лучше не ломать, другие проблемы явно у них сейчас в приоритете.

По поводу умирания Фортрана забавная история есть. У бывшей начальницы в LA муж Фред работал программистом предпенсионного возраста на Фортране в HP. Лет десять назад им сказали примерно так - давайте мы вас уволим с золотым парашютом. Тут дело в том, что просто просидев в конторе много лет, деды эти охрененно большую зарплату получали просто за счет выслуги лет. Фред подумал и согласился - а где-то через полгода ему позвонили и предложили тем же самым снова заниматься - но по контракту. А Фреду что за беда - мед.страховка у жены его покрывала, да и дело шло к пенсии и Medicaid, ипотека выплачена - т.е. ему от преимуществ постоянного трудоустройства ни холодно, ни жарко, а золотой парашют остался.

С Фортраном вот еще что нужно иметь в виду. CUDA/OpenCL/Phi требуют высокой параллельности алгоритмов, коих не так много, и явно соответствующие вещи были давно уже были переписаны с древнего Фортрана еще на многопотоковые библиотеки типа MPI для запуска на тех же суперкомпьютерах. Не параллелизуемые вещи так себе и сидят в старом коде - и я не представляю себе, кто и зачем будет это переписывать.

[Not]

Rubbiroid пишет:

Про мат либы. Тут самая обычная проблема легаси кода. Есть много библиотек, много людей, которые с ними работали. Чтобы переписать это все на С, нужно очень много времени, потом нужно избавиться от детских болезней, заняться оптимизацией алгоритмов, написать кучу документации, переобучить народ. Поэтому это все идет, но очень медленно. Опять же тут играет роль еще и фактор смены вычислительной платформы (ГПУ и ускорители типа Xeon Phi). Так что со временем все либы на фортране вымрут.

Вы про Фортран-2015 слышали?

Далее, никто не будет переписывать готовый работающий код, достаточно скомпилировать его из исходных текстов на новую платформу. Фортран распараллеливается значительно лучше чем С, благодаря специально продуманным языковым ограничениям, соответственно быстрее и его исполняемый код.

[dmitryskey]

Фортранщики могут поправить, но насколько я знаю, строго говоря для Фортрана гораздо лучше работает автовекторизация - на чем в свое время и взлетел Cray-1, они выдали векторную машину с очень приличной обычной производительностью и Cray Fortran, что делал эффективную автовекторизацию. Т.е. всякие ядерщики просто перекомпилировали свои библиотеки и немедленно получали прирост производительности. Для распараллеливания вроде бы MPI так и используется (понятно, что в более или менее современных диалектах).

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

По поводу С - по крайнем мере мой опыт с AVX не позволяет полагаться на автовекторизацию, приходится ручками пользоваться векторными расширениями gcc/clang. Удовольствия в этом, прям скажем, мало.

[TAU]

Rubbiroid пишет:
Не соглашусь с теми, кто говорит, что ИСС поступает верно, оставаясь на модуле. Я не в курсе полной ситуации на рынке ПО для спутников, но то, что я видел/слышал/щупал/писал - это С. Если ИСС останется единственным, кто будет использовать Модулу и ее инфраструктуру, то они рискую вляпаться в неприятные ситуации. Например когда все знающие уйдут, а новые, посмотрев на код, не захотят работать. Или когда ошибки будут возникать из ниоткуда (просто когда никому в голову не приходит, что что-то может пойти по-другому). Еще и скорость разработки и качество машинного кода будут падать по сравнению с конкурентами. Ведь мир С не стоит на месте, а вот ИСС замерло.

1. Иногда бывает, что один прав, а большинство - заблуждается. По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений. Весь мир "не стоит на месте", возможно, по пути к пропасти? ) 

2. "Все знающие уйдут" и подобные рассуждения от SGS. Все же Вы не в темевполне осознаете специфику. Технология создания бортового программного обеспечения - предмет, далеко не сводящийся к используемому языку программирования. В том же ИСС используется огромное число специфических инструментов для поддержки различных сторон их технологии. То есть приходящему на работу (кстати, не следует также забывать, что Железногорск - ЗАТО, и вопросы трудоустройства/переездов носят специфический характер) в любом случае приходится очень много чего нового изучать.

3. Повторю. Ничего, повторение - мать учения. Особенности разработанной и тщательно выверенной технологии создания БПО позволили ИСС повысить скорость разработки. А качество БПО такого, что ни разу ни на одном из десятков аппаратов не было критического отказа по причине БПО. Более того - особенности организации БПО позволяли неоднократно компенсировать иные виды отказов и сохранять работоспособность дорогостоящих и важных для обороноспособности страны изделий.

Да, и кстати. Я лично в ИСС не работаю 

[sychbird]

На днях с одним приятелем пересеклись. Вернулся на днях из Нью-Йорка. Рассказал интересную историю

В городе существует небольшая компьютерная фирма, специализация которой заключается в установке,  адаптации и поддержке Виндов НР на суперсовременные компы и сервера.
Заказчики из банковской и биржевой среды. Для них тоже крайне важна надежность ПО. Программы под НР за десятилетия отлажены и  работают и никто их не собирается переписывать.

Так что идеология ИСС в области автономности ПО от мейнстрима процветает и на Западе

[Not]

sychbird пишет:
Так что идеология ИСС в области автономности ПО от мейнстрима процветает и на Западе  

Еще как процветает. Кобол времен динозавров исключительно востребован. Более того, старые отлаженные пакеты весьма ценятся по одной простой причине - переписать с той же функциональностью в США обойдется очень дорого, в Индии получится не слишком надежно. Если учесть, что вышеупомянутые приложения работают на мейнфреймах, в которых в отличие от писюков обеспечивается обратная совместимость на десятки лет назад (собственно одна из причин почему они настолько живучи), то никому и в голову не приходит их переделывать. Сопровождать (править ошибки, дорабатывать) - безусловно. 

[dmitryskey]

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

Могу про нашу контору рассказать. Самое первое клиент-серверное приложение в 90-их вначале писалось на FoxPro, потом в GUI на Дельфи - т.е. пусть на бестолковом, но вполне себе кузене Модулы-2. Потихоньку приложение поддерживается, пару лет назад был большой в плане тестирования проект по переходу с BDE на FireDAC для поддержки современных баз данных. Так тестировщикам он больше текущей версии понравилось, работает быстро, функционала даже больше.

Так вот, недавно с изумлением узнал, что Гугл (наш давний клиент) именно это версию используют. HR народ консервативный, я так думаю, им просто сделали виртуальную машину, они и работают как им удобно.

Кстати, SpaceX тоже наш клиент, но, само собой, на платформе SaaS, они просто позже Гугла возникли

[Павел Фишер]

Not пишет:
Фортран распараллеливается значительно лучше чем С

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

TAU пишет:
По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений.

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

По пункту 2. Каким образом закрытость города, особенность технологий и прочие факты способствуют притоку свежих кадров? А если нет притока/приемствеености кадров - то рано или поздно проект погибнет.

TAU пишет:
А качество БПО такого, что ни разу ни на одном из десятков аппаратов не было критического отказа по причине БПО. Более того - особенности организации БПО позволяли неоднократно компенсировать иные виды отказов и сохранять работоспособность дорогостоящих и важных для обороноспособности страны изделий.

Ни разу не было != гарантированно не будет. Я вот тоже ни разу не попадал под машину, когда переходил дорогу. Ведь я смотрю по сторонам. Вот только никто не говорит, что со мной такого никогда не случится. И в моем понимании "закрытость" технологии только способствует такому. Ну и общий вопрос. Каким образом "качество ПО" может повлиять на возможность парирования ошибок других систем? Я вот думаю, что хорошие и гибкие алгоритмы могут. А на каком языке они записаны - так это не играет никакой роли.

sychbird пишет:
Заказчики из банковской и биржевой среды. Для них тоже крайне важна надежность ПО. Программы под НР за десятилетия отлажены иработают и никто их не собирается переписывать.

Банковская система США в данном случаи очень плохой пример, ибо она технологически отсталая в сравнении в российской или европейской. Когда не нужно ничего менять, то дешевле поддерживать старое, чем переписывать на что-то новое.

[Павел Фишер]

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

[dmitryskey]

На самом деле, в мало-мальски разумной конторе всегда играются с технологиями, у нас, к примеру, и на Go активно пишут, и микросервисы на NodeJS, и MongoDB крутится наравне с основной реляционной базой данных. И я охотно верю, что какой-нибудь UI для наземных испытаний на том же NodeJS может быть написан, Модула-2 едва ли хорошие библиотеки для современного GUI и веба имеет. Нужно просто различать mission-critical components и всякие побочные вещи.

Как пример. Исторически были у нас некие скрипты выкладки и обновления, написанные на Batch+VBS. Надоело до смерти - поддерживать тяжело очень, полгода назад плюнули и переписали на Python (ну и где очень специфические вещи типа установки сертификатов под Windows - на PowerShell). В итоге расшили узкое место - теперь читаются и правятся легко скрипты всеми членами команды. Но есть два момента - админы и люди, отвечающие за билды, кричали, что им это и даром не нать - пришлось ткнуть в корпоративную Policy по переходу на OSS. Второе - это не само приложение, с ним никто бы не позволил технологию менять.

По поводу новых вещей типа Rust, Go да и Swift (он теперь не только на iOS доступен). Нужно задаться вопросом - если есть универсальные комбайны С++, Java да и C# с новой политикой MS - для чего Mozilla изобрела Rust, Google Go и Apple Swift. И как ни странно - это еще один аргумент в копилку ИСС с его Modula-2. Все это внутренние средства разработки компаний, выпущенные в OpenSource и заточенные под внутренние цели. Вся разница, что ИСС не стала придумывать новый язык. Про Go скажу вполне уверенно - его ниша - это сетевые утилиты и микросервисы, как универсальному языку ему не хватает библиотек. Гугл делает в первую очередь то, что ему нужно, а брать левые библиотеки с непонятным качеством и поддержкой для production ну никак не стоит.

[TAU]

Rubbiroid пишет:  Ну и общий вопрос. Каким образом "качество ПО" может повлиять на возможность парирования ошибок других систем? Я вот думаю, что хорошие и гибкие алгоритмы могут. А на каком языке они записаны - так это не играет никакой роли

Когда я говорю о "качестве БПО", я имею в виду в целом, как оно спроектировано (тщательно и специально с учетом возможности при необходимости парирования отказов аппаратуры), и, естественно, программно-алгоритмическое обеспечение. И еще раз - технология разработки БПО в ИСС - отнюдь не одна отдельно взятая Модула.

Вообще, в космической области есть некоторая тенденция отделения алгоритмов от текстов программ. Сами алгоритмы при этом можно описывать, например, графическим языком. Можно посмотреть те же технологии ГРАФИТ-ФЛОКС, SCADE, TASTE, Grafet или МОКБ "Марс"...

[dmitryskey]

Кстати, подумалось. Вот делают ИСС спутники, используя русский язык, Thales - явно французский, про китайцев и подумать страшно со всеми их диалектами, друг-другу то непонятными :-). Явно языки не mainstream - ибо не английский. И что - качество работы этим определяется?

Все языки, что мы упоминали - полные по Тьюрингу и эквивалентные Тьюринговой машине :-)

[SGS_67]

Echidna пишет:
30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%.

Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.
МСМ, 70-80%, загрузки - вполне нормальный показатель, при условии достаточной квалификации создателей ПО под ОСРВ.
Другое дело, что при его достижении вполне стоит подумать о разработке железа с бОльшими ресурсами по части быстродействия.

[Not]

Rubbiroid пишет:

Not пишет:
Фортран распараллеливается значительно лучше чем С

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

Видите ли Юра...(с) Проблема тут математическая, и касается она вычислительной сложности алгоритма глобального анализа. Анализировать фортрановскую программу значительно проще, вследствии отсутствия прямого доступа в память, адресной арифметики и прочих ловких уловок, делающих глобальный анализ С-программы практически невозможным.