Компьютеры и Космонавтика

[Бродяга]

Ну дадут вам 64-ядерную персоналку с 100 Гигами оперативной памяти и частотой процессора 10 ГГц.
У вас производительность увеличится?

У меня увеличится, и очень заметно :lol:

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

[Дмитрий В.]

Поразительно, но факт, никакого сокращения сроков проектирования и постановки ракетно-космической техники компьютерная техника и IT не принесли.

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

Точно!

[Ark]

А сколько аварийных пусков было у Р-7 и Протонов.
Н-1 вообще не смогли запустить, потому что не умели слаженно управлять таким количеством двигателей.
А потом у Энергии - два пуска почти в точку.
Опять всей страной делали, сколько там смежников 1200 и что
никто не использовал расчёты на ЭВМ.
Вот тут все расчёты и остановились на уровне EC-ках в 1990 году.

Кроме времени проектирования необходимо учесть нелинейно-большую
сложностью проектов и накапливающийся опыт.

[Бродяга]

Потом это все надо будет еще пересчитать в листы формата А4, не забывайте об этом  

Ага, использование более совершенного инструмента требует организации труда под использование этого совершенного инструмента.
 Эту организацию труда могут создат только люди и компьютеры с любой производительностью им в этом не помогут.

[Бродяга]

А сколько аварийных пусков было у Р-7 и Протонов.
Н-1 вообще не смогли запустить, потому что не умели слаженно управлять таким количеством двигателей.
А потом у Энергии - два пуска почти в точку.
Опять всей страной делали, сколько там смежников 1200 и что
никто не использовал расчёты на ЭВМ.
Вот тут все расчёты и остановились на уровне EC-ках в 1990 году.

Н-1 не полетела из-за дибильных двигателей и отсутствия мотивации, а "Энергия" полетела по той причине, что Глушко вызывали в ЦК и грозили отнять академика за то, что он "наш Шаттл" никак не сделает.
 При этом могу сказать, что до запуска "Колумбии" работы по "Энергии" или чему-то подобному велись довольно долго и особо никто не шевелился.

Кроме времени проектирования необходимо учесть нелинейно-большую
сложностью проектов и накапливающийся опыт.

И то, что чем больше людей что-то делают, тем дибильнее оно получается.

[Reader]

Кроме времени проектирования необходимо учесть нелинейно-большую сложность проектов и накапливающийся опыт.

И то, что чем больше людей что-то делают, тем дeбильнее оно получается.

Значит сейчас все будет хорошо  

[Бродяга]

Кроме времени проектирования необходимо учесть нелинейно-большую сложность проектов и накапливающийся опыт.

И то, что чем больше людей что-то делают, тем дeбильнее оно получается.

Значит сейчас все будет хорошо  

На самом деле, есть оптимальное количество людей, если 4 человека будут нести бревно, грубо говоря, эффективнее, чем двое, но 20 человек будут друг другу мешать.
 Особенно это относится к структурам управления.

[Ark]

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

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

[Lev]

Используйте безбумажные технологии.

В том-то и парадокс! Компьютеры и оргтехника резко упростили процесс создания и тиражирования бумаг. И бумаг стало больше!

[Not]

Поразительно, но факт, никакого сокращения сроков проектирования и постановки ракетно-космической техники компьютерная техника и IT не принесли. :cry:  Ну, к примеру, Р-7 была создана за 5 лет (с 1952 по 1957 г.). ЭВМ были использованы, насколько помню, для траекторных расчетов. Никаких САПРов в помине не было. Элон Маск свою несравненно более простую РН Фалкон-1 создавал дольше (считая до первого успешного полета). При этом, компеьютеры никак не снизили количество ошибок при проектировании.
Истребитель F-22 создавался с 1975 (начало концептуальных исследований) до 2005 г. (первое авиакрыло достигло боеготовности). 30 лет. К моменту принятия на вооружение "борт" самолета безнадежно устарел и требует модернизации. И так в аэрокосмической технике везде.
В ряде случаев, повышение быстродействия компов просто бессмысленно. Например, задача оптимизации проектных параметров выбранной схемы РН занимает пару минут. Анализ полученных результатов занимает минимум час, даже увеличение скорости расчетов в 10 раз сократит время на решение задачи на доли процента.

Сроки, возможно, и не сократились, но почему никто не замечает резкого улучшения качества? Посмотрите на американскую космическую программу, в которой использование вычислительной техники сыграло чрезвычайно важную роль. Сколько лет марсоходы бегают по планете? Почему до сих пор функционируют Вояджеры? Нет, безусловно, были и глупые просчеты, когда например перепутали метры и футы. Но это скорее организационная неувязка. Главное же что нам всем дала высокопроизводительная техника - возможность моделировать и верифицировать, не проводя дорогостоящие натурные эксперименты. Если почитать Хольцмана, который сейчас командует в NASA лабораторией надежности ПО, когда он только туда пришел из Bell Labs, ему поручили проанализировать ПО бортового компьютера Deep Space Probe, готовое к выдаче на гора. Он средствами темпоральной логики построил формальную модель, проверифицирова и нашел пять (!) критических синхронизационных дефектов, каждый из которых мог привести к потере аппарата. Естественно, что его техника моделирования и анализа была внедрена.

Мораль: можно и микроскопом гвозди забивать, и на кластере отчет о командировке красиво форматировать. Что вовсе не означает, что кластер отучает думать.

[Гость 22]

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

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

"It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail" (c)

[sychbird]

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

Огромные долгоживущие научно-технологические конгломераты рано или поздно начинают загнивать.

Рецепт очевиден: перезагрузка с форматированием.

[sychbird]

А по философским аспектам темы пришел в голову модельный эксперимент, который может дать ответ на сомнения.

Можно ли, при неограниченном финансировании исследовательской подготовки восстановить технологию производства скрипок Страдивари? И можно ли этого добиться только при кустарном характере производства или можно хотя бы малосерийное наладить?

[Бродяга]

Главное же что нам всем дала высокопроизводительная техника - возможность моделировать и верифицировать, не проводя дорогостоящие натурные эксперименты. Если почитать Хольцмана, который сейчас командует в NASA лабораторией надежности ПО, когда он только туда пришел из Bell Labs, ему поручили проанализировать ПО бортового компьютера Deep Space Probe, готовое к выдаче на гора. Он средствами темпоральной логики построил формальную модель, проверифицирова и нашел пять (!) критических синхронизационных дефектов, каждый из которых мог привести к потере аппарата. Естественно, что его техника моделирования и анализа была внедрена.

Замечательно, а неисправность в оборудовании так можно найти?

[Бродяга]

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

Вы не совсем правы.
 Суть в чём, мощный компьютер, с огромными возможностями означает очень большие затраты на создание совершенного специализированного ПО для этого компьютера или же это будет "то же что на ассемблере", но в 1000 раз больше объёмом.

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

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

Огромные долгоживущие научно-технологические конгломераты рано или поздно начинают загнивать.

Рецепт очевиден: перезагрузка с форматированием.

Ну вот мы имеем Маска и Рутана в качестве "свежей операционки", посмотрим, что получится.

[Бродяга]

А по философским аспектам темы пришел в голову модельный эксперимент, который может дать ответ на сомнения.

Можно ли, при неограниченном финансировании исследовательской подготовки восстановить технологию производства скрипок Страдивари? И можно ли этого добиться только при кустарном характере производства или можно хотя бы малосерийное наладить?

Ну это кому как.
 Я Страдивари от чего другого ни разу не отличу.

[Not]

Главное же что нам всем дала высокопроизводительная техника - возможность моделировать и верифицировать, не проводя дорогостоящие натурные эксперименты. Если почитать Хольцмана, который сейчас командует в NASA лабораторией надежности ПО, когда он только туда пришел из Bell Labs, ему поручили проанализировать ПО бортового компьютера Deep Space Probe, готовое к выдаче на гора. Он средствами темпоральной логики построил формальную модель, проверифицирова и нашел пять (!) критических синхронизационных дефектов, каждый из которых мог привести к потере аппарата. Естественно, что его техника моделирования и анализа была внедрена.

Замечательно, а неисправность в оборудовании так можно найти?

Можно. Ошибки в оборудовании находят (обходят) во время эксплуатации изделия. Однако, ПО должно быть к этому готово. Простейшие примеры: память с битом четности, мажоритарное управление. Далее, модель ПО нужно рассматривать совместно с моделью железа. Например, ПО можно зашить в ПЛМ (программируемую логическую матрицу). Повреждение ПЛМ в данном случае неотличимо от ошибки в ПО.

Но, все это требует немалых вычислительных затрат в процессе как проектирования, так и эксплуатации

[Not]

Суть в чём, мощный компьютер, с огромными возможностями означает очень большие затраты на создание совершенного специализированного ПО для этого компьютера или же это будет "то же что на ассемблере", но в 1000 раз больше объёмом.

Чепуха. Пишите декларативно, и будет вам счастье.

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

Помимо "блочного" (видимо вы имели ввиду структурное, времен 70-х) существует объектное, аспектное, функциональное, декларативное и т.д. Выбирайте инструмент по задаче. Что не означает, что программировать большие комплексы просто. Но и инструменты должны быть адекватны мощности ВМ.

[Бродяга]

Можно. Ошибки в оборудовании находят (обходят) во время эксплуатации изделия. Однако, ПО должно быть к этому готово. Простейшие примеры: память с битом четности, мажоритарное управление. Далее, модель ПО нужно рассматривать совместно с моделью железа. Например, ПО можно зашить в ПЛМ (программируемую логическую матрицу). Повреждение ПЛМ в данном случае неотличимо от ошибки в ПО.

Но, все это требует немалых вычислительных затрат в процессе как проектирования, так и эксплуатации

ПО "совместно с моделью железа"?

 Я выше приводил пример, у меня "Панель управления" слетала ругаясь на IE.
 Так вот, это видеокарта накрылась, причём звук, что интересно, работал. Слава богу, знакомый в фирме, которая продала мне комп, отлично знал этот баг и определил его мгновенно.

 Вы сколько работы угрохаете на "модель железа", если это современное сложное "железо", а не что-то преднамеренно упрощённое?

 Могу привести примеры интереснее, причём всё это касается массовых продуктов, которые эксплуатируются сотнями тысяч и миллионами людей, и статистку набрать не представляет труда.

[Бродяга]

Чепуха. Пишите декларативно, и будет вам счастье.

Вы хотите сказать, что на современном компьютере человек может как-то выдать больше "чистого кода" в единицу времени, чем раньше?

Помимо "блочного" (видимо вы имели ввиду структурное, времен 70-х) существует объектное, аспектное, функциональное, декларативное и т.д. Выбирайте инструмент по задаче. Что не означает, что программировать большие комплексы просто. Но и инструменты должны быть адекватны мощности ВМ.

Ага, все эти методы ещё ужаснее на практике.