Проще? Дешевле? Приведу реальный пример: на закате СССР разрабатывался мобильный вычислительный комплекс «реального времени» «РВ» для военного применения (без подробностей!) Причем, оборудование и периферия «как всегда» были нестандартными, плюс всё было секретно, и по допускам, и по ..., и по…. Стояла задача написания канальной программы управления нестандартным устройством IO (более того, оборудование спроектировано и произведено в Болгарии). Данная задача, в переводе на «современный язык» для талантливой поросли: — состояла в необходимости написания драйвера нестандартного HDD для спецОС. Так вот, по идее — все просто: — укради и воплоти архитектуру компьютера и периферии «битик в битик». Однако если сил на повторение архитектуры хватило, то «стибрить» и воплотить периферию оказалось делом малопродуктивным и неподъемным. Проблемы коммуникации с периферией планировали решать путем разработки своих драйверов ввода-вывда для устройств. Ага, хорошо было в теории, — ничего не получалось на практике, т.к. помимо команд драйвера, необходимо было знать протокол работы самого устройства, а его не было, потому что всё секретно, потому что — Болгария… и т.д. Перед возникшей проблемой спасовал даже минский НИИЭВМ, который был непреклонной истиной в последней инстанции во времена СССР…. Конечно, стоящую задачу удалось решить; путем метода «проб и ошибок» были перебраны все проприетарные драйвера, конфигурации которых вписывались в показатели существующего HDD. В итоге, был найден драйвер «древнего барабана» формат которого, наиболее подходил к формату болгарского чуда. В итоге, применив этот драйвер — около 20% дискового пространства стало недоступным для ОС, и это в те времена. когда емкость диска была около 49 Мгб., а рекордным в СССР диском был диск 200 Мгб.
" И проще и дешевле это ПО копировать готовым." — угу, скопировали, — и смех и грех!
Индусы (, в том числе, и по заказу IBM) занимаются ОС's, языковыми инструментами, системами ИИ и т.п.). Китайцы разрабатывают очередные клоны Windows, гипервизоры, системы ИИ, САПРы для CALS, а «по-мелочи» — не пересчесть. Успешно трудятся на ниве Интерпрайз-ПО: Германия, Япония, обе Кореи, Франция, Канада, Бразилия и т.п. Зачем они это делают? Деньги зарабатывают, обеспечивают безопасность своей страны от возможных санкций, экономически развивают свои страны, думают о собственном МО и т.д.. Я думаю, Вам трудно будет это понять в парадигме: «Бабки-прибыль превыше всего» (лозунг, дикого, доисторического капитализма). САПРов у нас нет, иногда на горизонте появляются «саприки», причем, почти всегда, без четкой перспективы. А если вдруг и появляется отечественное технологическое ПО, пусть куцое и недоделанное, часто, без глубоких идей, то, даже, на Хабре/Гике (элита ИТ?) оно вызывает неприязнь или смех (Как минимум, один относительно недавний пример наблюдал воочию на Хабре/Гике). Если я неправ — просветите меня, откройте мне глаза на серьезный отечественный САПР ПО? Надеяться купить его у Intel или IBM — по меньшей мере, идиотизм, не за какие многие миллиарды долларов, они не продадут свои САПРы,… хотя о чем я пишу...? Нам же это ненужно.
Наши школьники, ранее, часто блистали на олимпиадах, однако, в последние времена Китай выигрывает сильно чаще…. Про положение в отраслевых ВУЗах (кроме МГУ (?), возможно, МФТИ (??) и чуть-чуть в детище РЖД) писать не буду — боюсь получить несварение желудка перед обедом. «Нет, конечно не всё гладко...» — в части разработки индустриального и системного ПО: совсем всё негладко.
Материал статьи — хороший, но видна спешка и огрехи при его публикации. Понравилось, что статья пытается дать понять читателям, что было время, когда БЭСМ (а затем БЭСМ-6), был быстрее любой американской вычислительной машины. Технари у нас были суперкласс, да и, в общем, такими остаются и сейчас, чего нельзя сказать про программистов. Большое отставание в навыках написания Операционных Систем (ОС) было заложено именно в то время — 10 лет писали ОС для БЭСМ, а если уложились бы в 2-5 лет, может и не случилось бы в СССР «массового перехода на систему ЕС», который, фактически, похоронил в СССР класс собственных разработчиков ОС (, а также, компиляторов, интерпретаторов, САПР ПО), оставив им удел локализации системного ПО. От этого удара мы не можем отойти до сих пор, и самое главное, ИТ-тусовка РФ, в основном, не понимает насущности решения вопросов создания собственного системного ПО. Стыдно, но Индия, КНР, (не говоря про англосаксов) — могут, а в России усилием воли могут создать только очередной клон свободного программного обеспечения…
Кстати, похоже, только в России, уместно теоретизировать о необходимости высшего образования для программистов. А почему встает вопрос недоверия ВУЗам? Потому-что ВУЗы не дают опорного образования в области программирования. Уровень преподавания в них: 1972-1977 год мирового уровня по ряду важных дисциплин.
СССР имел небольшое кол-во резервных спутников на случай войны, установленных на ракетах шахтного базирования и готовые к запуску. Однако их было немного (в США в середине 80-х было выделено более 50 РН с установленными спутниками), плюс сроки хранения спутников были невелики и требовали постоянного к себе внимания.
Если спросить студента — какие знания он хотел бы получить в институте, то его ответ свёлся бы к монументальному «чтоб взяли в хорошую компанию на хорошую зп, дабы заниматься интересным делом». Такой ответ ничего не прибавляет к пониманию проблемы образования ИТ-наук в вузе. Рискую предположить, что обучение конкретным языкам программирования (кроме системных) — недальновидная трата времени. Так а что надо изучать в вузе? Примерный ответ таков: 1-курс >> теория: — Алгоритмы, структуры данных, языки, CУБД, ассемблер, компилятор, интерпретатор, ОС, аппаратура, ЭВМ, криптошифрование, Защита информации и т.д.; 2-ой курс >> создание учебного интерпретатора и компилятора; 3-й курс >> создание учебной ОС или ОС РВ; 4-ый курс >> Технологии создания индустриального ПО; 5-ый курс >> практическая стажировка в гос или коммерческом секторе, «специальные темы» ( разработка высокопроизводительных систем/систем РВ, подробно Архитектура ЭВМ, Перспективные ЭВМ, ИИ ), знакомство с устаревающими темами (типа реляционные СУБД, ООП, и т.д.) По ряду специальностей можно добавить темы: программируемые матрицы, Аналоговое программирование, Сети, Управление проектами ПО. Как-то так… Главное, чего никогда не было ни в СССР, не в «демократии» — это подготовленных кадров для ВУЗов. Причем эти кадры есть! Может ввести налоговые послабления для фирм, специалисты которых смогут читать лекции в ВУЗах?
1.1 Дело в том, что Протон на заре своего рождения «очень плохо летал», аварийность (если не изменяет мне память, составляла 1/3), но это не значит, что у оставшихся двух запусков не было проблем при старте (особенно «отличалась» вторая ступень!). Иногда выручала СУ. Отказ одного двигателя при старте — обыденное дело, не всегда ведущее к аварии. И сразу вопрос, почему аналоговые «решатели» не умели корректировать траекторию? В СССР были отличные математики. Диффуравнения и создавать и решать прекрасно умели. Более того, был крен в пользу всеобщей автоматизации в те времена. (Известный пример — разработка Союза и Л1/Л3). Перед отстрелом ступени вся итоговая информация передавалась на следующую ступень, при помощи которой СУ корректировала полет и, соответственно, требуемая информация передавалась по телеметрии.
1.2 Извините, но Вы сами понимаете, что написали? Н-1 имеет на первой ступени 36 двигателей, на второй ступени — не помню, лень смотреть, но тоже, далеко не один двигатель и т.д. Поддержания мощности, тяги, баланса, скорости, угловых значений и т.д. — задача не сравнимая с СУ Р-7. Отказы двигателей в пакете случаются со второй половины 60-х годов, как у нас, так и у «них», и Пилюгин знал об этом, тем более, что на последнем пуске Н-1 — стояла новая СУ, призванная не допустить «не ошибок», а настоящих, мягко говоря, непрофессиональных проколов работы СУ предыдущих запусков Н-1.
2. Я не в чем не собираюсь Вас убеждать. Не верите — Ваше дело. Просто в наше время принято говорить об «убогости» технических решений 60х-80х годов, дабы подчеркнуть собственные достижения, которых по сути нет (пример Линн Индастр, падающие Протоны, которые опять «разучились летать», «невзлетающие Прогрессы» и т.п.), а тогда на каркуляторной мощности и аналоге запускали аппараты к другим планетам. Да, некоторые решения были примитивны, но они работали тогда, поставленная задача выполнялась. Абсолютно все космические решения сегодняшнего дня (кроме одного пуска Ангары) — из СССР. Пилотируемый «Союз» — 1963 года рождения.
3.1 Есть такое понятие — профессионализм. Пироги не должен печь сапожник, и не ключница должна делать водку (с). В СССР была гонка в космосе. Если бы конструкторы создавали и согласовывали все до мельчайших подробностей, то Р-7 до сих пор бы не взлетела. Такой подход означает риск, и как следствие — аварии, порой весьма тяжелые. В такие времена выручает профессионализм и ответственность Конструктора. Странно, что для одних РН А-1001(Пилюгин) создавал нормальные СУ, а в другом случае получалось то, что… получалось, и об этом я пишу как человек который своими глазами видел эту «кухню». Я не обвиняю Пилюгина во вредительстве, он был, как и все остальные Конструкторы — членом «своей» команды. Кстати, и другие конструкторы саботировали данный проект. Вспомните, кто сделал двигатели, а кто должен был их сделать и т.д.
3.2 Лирическое отступление: попробую сыграть в предсказателя-Вы человек, который работает/тал в «околокосмической» теме, Ваш возраст — до 40 лет, поэтому и возник вопрос 3.2. 3.1… Теперь к делу: все четыре старта Н-1 были завершены по команде СУ, на этапе работы первой ступени командой подрыв/ликвидация РН.
1. ДА (Благодаря подобным алгоритмам ранее был спасен не один запуск Протона)
2. Пилюгин был в «другом» лагере. А почему не реализовал подобную автоматику — уже никто не узнает. Техническая возможность была.
3. Конечно должен. А то, что относился «абы-как» к проекту СУ Н-1 доказывает факт взрыва над стартовым столом, в результате которого обе стартовых площадки оказались практически разрушены. Давать команду на ликвидацию надо тоже «вовремя»!
Точных цифр не помню, но суть такова:
Проблемы РН Н-1 определяются во многом противостояниям двух Главных конструкторов: Глушко и Королева/Мишина. Главные конструктора отдельных подсистем негласно поддерживали либо одну, либо другую группу. Политбюро само металось между ними: то Королев, то Глушко, то опять Королев(и впоследствии Мишин), а потом Глушко снова в фаворе, все это сильно вредило основному делу…
Все четыре старта «Науки-1» закончились аварией 1-ой ступени. Перед четвертым запуском была заменена система управления ракетой и введены новые компоненты управления. За управление Н-1 отвечал НИИАП (А-1001), теперь НПО АП, во главе с Пилюгиным. Авария произошла на 107 сек старта, взрыв РН еще через 3 сек, то есть за 4 секунды до штатного отделения 1-ой ступени. Если бы НИИАП честно отнесся к своей работе, то система управления ранее отключила бы первую ступень, дав команду второй ступени отработать большое время. Запуск был произведен, история нашей космонавтики могла быть другой…
Через много лет, «как бы» в отместку была закрыта такая же глушковская ракета (Энергия-Буран), после двух удачных запусков.
4-ый запуск Н-1 мог состояться, но НПОАП(НИИ АП) сделал всё, чтобы это не случилось. Внутренняя борьба существовала уже в те времена. Жаль, космос сегодня выглядел бы совсем по-другому.
Странно, Вы вроде бы с турбинами работаете с критическими приложениями, а так поверхностно подходите к пониманию загрузки компьютера. Может быть у Вас на каждый АЦП отдельно РС-шка стоит (гротеск!), тогда Вам меня не понять. Я говорю о бортовых системах, которые должны надежно исполнять несколько критических приложений параллельно, при этом гарантированно исполнять свою задачу. Чтобы исключить дальнейшие споры, я опишу несколько преимуществ бортовых вычислителей:
* CPU вообще не занимается операциями ввода-вывода (поэтому и может работать при 100% загрузке), соответственно не нормируется и спокойно расширяется линейка устройств ввода-вывода, которая может быть добавлена в систему без upgrade центральных процессоров (Телеметрия, Логи, АЦП, спецустройства, ...) Таким образом гарантируется высочайшая пропускная способность бортовой вычислительной системы.
* Отсутствуют накладные расходы ОС на переключение контекста процессора, более того, если кол-во задач не превышает 32, то переключение контекста отсутствует полностью.
* Реализация части функций ОС — аппаратурой
Есть масса других особенностей, выгодно отличающихся от архитектуры х86 в части надежности и безопасности. Подобные вычислители работают со времен Space Shuttle и Бурана и отлично работают.
Мне кажется, что это Вы неправильно поняли меня. Когда я говорю о загрузке процессора, я конечно имею ввиду загрузку компьютера, где кроме CPU есть оборудование которое влияет на общую загрузку компьютера, Можно подобрать некоторое кол-во задач, которое может привести к серьезной загрузки именно CPU — но это большая редкость, особенно для х86. При разнородных задачах загрузка х86 свыше 35% — это беда, дело не в CPU, дело в арбитраже шины, в IO, контроллерах и в более медленной памяти, наконец. А с учетом того, что именно CPU обрабатывает «медленные» запросы на IO, приводит к тому, что х86 обычно не используется в критических системах в ракетной, авиационной технике, на электростанциях, заводах по обогащению урана и т.д., во всяком случае у «них».
А «100%» не может быть бедой в архитектурах «без общей шины», (хотя в реальных системах уровень держат на уровне 80%), тк задачи в РВ имеют сложную систему приоритетов и безопасности, (не хочу вдаваться глубоко в суть архитектуры) и конечно «основная задача» выполняется с высоким уровнем и если ей будет не хватать ресурсов — то замедлится исполнение задач с низкими приоритетами (обычно, такая ситуация не возникает!)
Поймали на неточности определений. Речь идет о стандартной архитектуре компьютера х86 (IBM PC). Архитектура х86 весьма проста и незамысловата, где главная проблема и тормоз — общая шина и соответственно неудовлетворительный IO, которым, грубо говоря, управляет — CPU.
Просто Вы не в курсе, что кроме Intel существуют другие аппаратные архитектуры, где загрузка почти 100% — это НОРМА, не приводящая к проблемам в эксплуатации. А Ваши клиенты правильно требуют снижения нагрузки на Intel-архитектуру, которая в большинстве случаев не должна превышать 35%, если речь идет о какой-то надежности.
Отличная исчерпывающая статья о проблеме в крупном проекте. Зря намекает Денис Решихин на ошибки в системном проектировании дизайна проекта. Конечно, никаких ошибок в дизайне изначально не было. Таких «детских просчетов» наши разработчики не допускают с печального старта в 1974 году, да и «у них» то-же. Всему виной дополнительным требования по загрузке компьютера на уровне 80% по мощности (хотя 100% загрузка бортового компьютера РН Ариан, в принципе тоже норма), из-за которых пришлось вводить ограничения на проверку параметров в коде. Плюс, грубая ошибка в использовании принципа «повторноиспользуемости кода», при отсутствии тестирования интеграции в условиях новых входных данных.
Анализ кода в этом случае ничего не даст. Ребята просто попытались «сэкономить деньги» на этапе тестирования, а не вышло.
" И проще и дешевле это ПО копировать готовым." — угу, скопировали, — и смех и грех!
Наши школьники, ранее, часто блистали на олимпиадах, однако, в последние времена Китай выигрывает сильно чаще…. Про положение в отраслевых ВУЗах (кроме МГУ (?), возможно, МФТИ (??) и чуть-чуть в детище РЖД) писать не буду — боюсь получить несварение желудка перед обедом. «Нет, конечно не всё гладко...» — в части разработки индустриального и системного ПО: совсем всё негладко.
Кстати, похоже, только в России, уместно теоретизировать о необходимости высшего образования для программистов. А почему встает вопрос недоверия ВУЗам? Потому-что ВУЗы не дают опорного образования в области программирования. Уровень преподавания в них: 1972-1977 год мирового уровня по ряду важных дисциплин.
1.2 Извините, но Вы сами понимаете, что написали? Н-1 имеет на первой ступени 36 двигателей, на второй ступени — не помню, лень смотреть, но тоже, далеко не один двигатель и т.д. Поддержания мощности, тяги, баланса, скорости, угловых значений и т.д. — задача не сравнимая с СУ Р-7. Отказы двигателей в пакете случаются со второй половины 60-х годов, как у нас, так и у «них», и Пилюгин знал об этом, тем более, что на последнем пуске Н-1 — стояла новая СУ, призванная не допустить «не ошибок», а настоящих, мягко говоря, непрофессиональных проколов работы СУ предыдущих запусков Н-1.
2. Я не в чем не собираюсь Вас убеждать. Не верите — Ваше дело. Просто в наше время принято говорить об «убогости» технических решений 60х-80х годов, дабы подчеркнуть собственные достижения, которых по сути нет (пример Линн Индастр, падающие Протоны, которые опять «разучились летать», «невзлетающие Прогрессы» и т.п.), а тогда на каркуляторной мощности и аналоге запускали аппараты к другим планетам. Да, некоторые решения были примитивны, но они работали тогда, поставленная задача выполнялась. Абсолютно все космические решения сегодняшнего дня (кроме одного пуска Ангары) — из СССР. Пилотируемый «Союз» — 1963 года рождения.
3.1 Есть такое понятие — профессионализм. Пироги не должен печь сапожник, и не ключница должна делать водку (с). В СССР была гонка в космосе. Если бы конструкторы создавали и согласовывали все до мельчайших подробностей, то Р-7 до сих пор бы не взлетела. Такой подход означает риск, и как следствие — аварии, порой весьма тяжелые. В такие времена выручает профессионализм и ответственность Конструктора. Странно, что для одних РН А-1001(Пилюгин) создавал нормальные СУ, а в другом случае получалось то, что… получалось, и об этом я пишу как человек который своими глазами видел эту «кухню». Я не обвиняю Пилюгина во вредительстве, он был, как и все остальные Конструкторы — членом «своей» команды. Кстати, и другие конструкторы саботировали данный проект. Вспомните, кто сделал двигатели, а кто должен был их сделать и т.д.
3.2 Лирическое отступление: попробую сыграть в предсказателя-Вы человек, который работает/тал в «околокосмической» теме, Ваш возраст — до 40 лет, поэтому и возник вопрос 3.2. 3.1… Теперь к делу: все четыре старта Н-1 были завершены по команде СУ, на этапе работы первой ступени командой подрыв/ликвидация РН.
1. ДА (Благодаря подобным алгоритмам ранее был спасен не один запуск Протона)
2. Пилюгин был в «другом» лагере. А почему не реализовал подобную автоматику — уже никто не узнает. Техническая возможность была.
3. Конечно должен. А то, что относился «абы-как» к проекту СУ Н-1 доказывает факт взрыва над стартовым столом, в результате которого обе стартовых площадки оказались практически разрушены. Давать команду на ликвидацию надо тоже «вовремя»!
Проблемы РН Н-1 определяются во многом противостояниям двух Главных конструкторов: Глушко и Королева/Мишина. Главные конструктора отдельных подсистем негласно поддерживали либо одну, либо другую группу. Политбюро само металось между ними: то Королев, то Глушко, то опять Королев(и впоследствии Мишин), а потом Глушко снова в фаворе, все это сильно вредило основному делу…
Все четыре старта «Науки-1» закончились аварией 1-ой ступени. Перед четвертым запуском была заменена система управления ракетой и введены новые компоненты управления. За управление Н-1 отвечал НИИАП (А-1001), теперь НПО АП, во главе с Пилюгиным. Авария произошла на 107 сек старта, взрыв РН еще через 3 сек, то есть за 4 секунды до штатного отделения 1-ой ступени. Если бы НИИАП честно отнесся к своей работе, то система управления ранее отключила бы первую ступень, дав команду второй ступени отработать большое время. Запуск был произведен, история нашей космонавтики могла быть другой…
Через много лет, «как бы» в отместку была закрыта такая же глушковская ракета (Энергия-Буран), после двух удачных запусков.
* CPU вообще не занимается операциями ввода-вывода (поэтому и может работать при 100% загрузке), соответственно не нормируется и спокойно расширяется линейка устройств ввода-вывода, которая может быть добавлена в систему без upgrade центральных процессоров (Телеметрия, Логи, АЦП, спецустройства, ...) Таким образом гарантируется высочайшая пропускная способность бортовой вычислительной системы.
* Отсутствуют накладные расходы ОС на переключение контекста процессора, более того, если кол-во задач не превышает 32, то переключение контекста отсутствует полностью.
* Реализация части функций ОС — аппаратурой
Есть масса других особенностей, выгодно отличающихся от архитектуры х86 в части надежности и безопасности. Подобные вычислители работают со времен Space Shuttle и Бурана и отлично работают.
А «100%» не может быть бедой в архитектурах «без общей шины», (хотя в реальных системах уровень держат на уровне 80%), тк задачи в РВ имеют сложную систему приоритетов и безопасности, (не хочу вдаваться глубоко в суть архитектуры) и конечно «основная задача» выполняется с высоким уровнем и если ей будет не хватать ресурсов — то замедлится исполнение задач с низкими приоритетами (обычно, такая ситуация не возникает!)
Анализ кода в этом случае ничего не даст. Ребята просто попытались «сэкономить деньги» на этапе тестирования, а не вышло.