F-22: «Хищники» опозорили Америку

hsm> Можете привести это самое определение?
Могу. Железо тестируется на том же софте, который тестируется на железе. То есть - как пример - пишете вы брайвер под графику. И для проверки драйвера гонятеся тест, какой-нибудь там x11perf. А потом при проверке железа гоняется тот же самый тест. То есть и железо и ПО тестируются одним и тем же набором программ, а не разными.

Серокой>> Правка железа - это новый цикл тестирования и запуск производства микросхем. И всё это стоит денег, и немалых. И времени по определению больше больше, чем уйдёт на то же тестирование ПО, поскольку плюсуется время изготовления микросхемы.
В.М.> Хе-хе, не знаете вы сколько человек-времени занимает тестирование сложного софта. Порой действительно дешевле железо новое сделать

А почему вы отказываетесь понимать, что железо как минимум так же сложно тестировать, а?

Серокой:

*It's not a lot of work unless you have to do it.*©

Серокой> А почему вы отказываетесь понимать, что железо как минимум так же сложно тестировать, а?
Потому что уже несколько раз в этом топике объяснялось почему это не так. Надо еще раз? Пожалуйста. Суть универсальной программируемой машины в том что прикладная функциональная сложность реализуется в программах, сама машина при этом может быть простой (по идее она должна быть максимально простой), что такое процессор - набор регистров, АЛУ и ввод-вывод, все что сверх этого - всего лишь способ увеличения быстродействия. Программа-же реализует сколь угодно более сложное представление. Что непосредственно отражается на сложности и стоимости его разработки/отладки/тестирования.

au> Серокой:
au> *It's not a lot of work unless you have to do it.*©
Довелось, кстати, разрабатывать-поотлаживать и того и другого.

Серокой>> А почему вы отказываетесь понимать, что железо как минимум так же сложно тестировать, а?
hsm>все что сверх этого - всего лишь способ увеличения быстродействия.
И вот это сверх- уже, как видно на примеретех же самых Пентиумов или графических ускорителей, уже давным давно перестало быть "всего лишь", и возникают такие ситуации, которые при логическом рассуждении элементарно не придут в голову! Как та ошибке с умножением в Pentium-I. Отсюда пишутся генераторы случайных тестов, и тыды, и тыды, не говоря уж о запусках на реальных программах.

hsm>Программа-же реализует сколь угодно более сложное представление. Что непосредственно отражается на сложности и стоимости его разработки/отладки/тестирования.
Программа опирается на тот набор инструкций, который предоставляет ей процессор. Какой бы она сложной не была, она разбивается на элементарные команды. А вот при усложнении она начинает задействовать то самое "всего лишь", и начинается валится куча багов. Железных! Которые фиг отладишь, когда у тебя операционка валится с плавающей ошибкой через сутки работы.

Здравствуйте.

Вот бы наши строевые истребители позорили б страну перелётами через океан, а не залётами над Балтикой. Статья идиотская — для идиотов.

---

Balancer> Кстати, под Linux идёт GNAT Ada Compiler - тот из Ada-сорцов генерирует сишный код, который уже и компилится тем же GCC

Это не Ada, а недоразумение игрушечное. Ada — операционная система со средой разработки. Ada современнее C++ и, тем более, архаичного C.

---

Сергей-4030> Вы это серьезно? Худо-бедно, но сравнивать нынешнее состояние в деле разработки/дизайна и того, что было 20 лет назад - смешно. Сейчас сравнительно мелкие фирмы делают системы такой сложности, на которой 20 лет назад Майкрософт бы загнулась вместе с IBM.

20 лет назад, в 1987 году, Microsoft ещё был предприятием для забавы, хотя Биллу Гейтсу исполнилось 32. IBM уже не радовала успехами в программировании. Если желаете, можно напрячься и вспомнить передовые программные фирмы того времени. Видимо DEC, Sun, Apple; системы вроде VAX VMS или Small Talk — многозадачные графические среды.

---

kirill111> Сразу "Леклерк" вспоминается.

И ничего Вам не вспоминается. Нельзя забыть то, что не знали.

---

101> Да года три-четрые назад это было в планах по F-22 - перейти с Ады на Си...

Уважаемый 101, это так похоже на бред, что, видимо, бред, сон, фантазия. Как и рассуждения об индусах.

---

Серокой> Там упоминается в связке с Адой в том числе и для F-22 некий Jovial. Не слышали, шо це такэ?

Jovial — язык среднего уровня на основе синтаксиса Algol 60 со слабой (машинозависимой) типизацией, британской работы. Для встроенных систем малой вычислительной мощности, основной предшественник Ada у американских и британских военных. Замена навороченным ассемблерам. Вроде C, но с развитой арифметикой с фиксированной точкой и прочими особенностями встроенных систем того времени. В невоенных отраслях не распространялся.

Дмитрий Журко

hsm> Суть универсальной программируемой машины в том что
hsm> прикладная функциональная сложность реализуется в программах
hsm> сама машина при этом может быть простой
hsm> что такое процессор - набор регистров, АЛУ и ввод-вывод, все что сверх этого - всего лишь способ увеличения быстродействия
hsm> Программа-же реализует сколь угодно более сложное представление.

"С чего начинается родина" программирования. Только это это всё из тех времён, "когда компьютеры были большими, а мы были маленькими". С тех пор, давно уже, архитектура вычислителя — это переменная величина, её можно думать и делать, а не копировать из "Advances in Digital Computers, 1950". А потому...

hsm> Что непосредственно отражается на сложности и стоимости его разработки/отладки/тестирования.

...тезис рассыпается от старости и полной несостоятельности. У вас на столе считай векторная машина с несколькими крупными вычислителями, один из которых (ГПУ) ну совсем не подходит под ваше определение. А его таки программируют на С к величайшему своему удовольствию люди, в общем-то далёкие от профессионального программирования. Короче, в компьютерном инжиниринге за полвека ВСЁ ОЧЕНЬ ИЗМЕНИЛОСЬ, и даже стало лучше, это пора бы заметить и учесть.

Серокой> Программа опирается на тот набор инструкций, который предоставляет ей процессор.
А из яйца появляется курица. Кто из них сложнее?
Как вы предполагаете - где больше сложности - в русском алфавите или в романе "Война и Мир"? - хорошая аналогия для железа и софта.

au> "С чего начинается родина" программирования. Только это это всё из тех времён, "когда компьютеры были большими, а мы были маленькими". С тех пор, давно уже, архитектура вычислителя — это переменная величина, её можно думать и делать, а не копировать из "Advances in Digital Computers, 1950". А потому...
Проведем мысленный эксперимент. Допустим у нас есть технология дающая неограниченное быстродействие. В таком случае все архитектурные изыски, кеши, вектора, конвейера, ГПУ и пр. и пр., окромя "изначальных", немедленно идут дальним лесом. Машина Тьюринга - самодостаточна. (До появления квантовых, а там - видно будет.)
Так как этого абсолюта нет - приходиться извращаться.
А вообще - о чем собссно спор? Показано и доказано все уже давно. Земля - круглая, Солнце - не центр вселенной, софт - сложнее железа.

Серокой>> Программа опирается на тот набор инструкций, который предоставляет ей процессор.
hsm> А из яйца появляется курица. Кто из них сложнее?
hsm> Как вы предполагаете - где больше сложности - в русском алфавите или в романе "Война и Мир"? - хорошая аналогия для железа и софта.

Если б в книге буквы менялись сами по себе в зависимости от освещённости, листались сами страницы и играла приятная музыка - тогда да, аналогия хорошая.

hsm> А вообще - о чем собссно спор? Показано и доказано все уже давно. Земля - круглая, Солнце - не центр вселенной, софт - сложнее железа.

Центровселеннский шовинизм программистов неискореним.

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

hsm> В процессоре, если вы о нем, "само по себе" ничего не происходит (окромя деградации пп, роста дендритов, электромиграции ...). А только волею исполняемой программы.
Ну да, не происходит! А как же TLB ищет запись по виртуальному адресу, как из кэша извлекается именно те, а не иные данные, да ещё и с поддержкой когерентности с памятью, как ветвления предсказываются? программа и слов-то таких не знает - предсказать бранч!

hsm> А вообще - о чем собссно спор? Показано и доказано все уже давно. Земля - круглая, Солнце - не центр вселенной, софт - сложнее железа.

Спор вот о чём.
Разработка систем управления и расчёта на на базе программируемых вычислитей подразумевает: 1) systems design 2) partitioning 3a) hw design 3b) sw design 4) verification, testing, etc. На практике зачастую всё делается иначе: 1) пишется некое sw 2) берётся некое hw 3) дебаггится до минимального удовлетворения заказчика. Системного дизайна нет; сегментирование системы если и делается, то на сумрачно-подсознательном уровне "по понятиям", точно по вашим словам:
hsm> что такое процессор - набор регистров, АЛУ и ввод-вывод, все что сверх этого - всего лишь способ увеличения быстродействия
hsm> Программа-же реализует сколь угодно более сложное представление.

Вменяемых причин для этого не вижу. Могу только с глубоким сожалением присоединиться к этому заключению:
hsm> Центровселеннский шовинизм программистов

Спор о том, что это порочно со всех без исключения сторон кроме горе-программистов и их поклонников.

au> MIB determined that one of the root causes of the mishap was an inadequate GN&C software development process
au> MIB determined that there was an inadequate, system-level integration process
au> MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap
au> was a failure to implement existing (NASA) engineering requirements, standards and practices
au> NASA Report: Overview of the DART Mishap Investigation Results - For Public Release | SpaceRef - Your Space Reference
au> Мало?

Чего мало? Даже если допустить, что в процессе детерминирования все было гладко - что следует из вашей цитаты? Я как-то ни грамма не вижу, как из нее следует обязательность ассемблера. Inadequate systems engineering - это, извините, имхо как раз предполагает, что нужно использовать нормальные методы разработки, а не ковыряние в ассемблере, которое и есть - неадекватно в 99.9% случаях.

Серокой> А почему вы отказываетесь понимать, что железо как минимум так же сложно тестировать, а?

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

Серокой>> А почему вы отказываетесь понимать, что железо как минимум так же сложно тестировать, а?
Сергей-4030> Мы не отказываемся. Это вы отказываетесь понимать, что "железный софт", как правило, решает задачи очень хорошо определенные и частные.

Ну да, когда на системном контроллере идёт DMA от диска, стучится Ethernet со срочно пришедшем пакетом данных и ещё и сваливается прерывание от таймера, а write-back кэш в это время заканчивает переписывание линейку памяти, то определённости - хоть отбавляй!

au> Серокой:
au> *It's not a lot of work unless you have to do it.*©

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

au> Вы признались

Признаются в суде.

au> что не читали, я читал.

Вы что-то путаете. Я не читал отчёт. Вы наверняка тоже его не читали. А вот заявления соответствующих пресс-служб ВВС США лично я читал.

Серокой> Центровселеннский шовинизм программистов неискореним.
Вот так-же убивались сторонники плоской Земли.
Это объективная реальность, в ощщущениях, а не чьи-то происки.

au>> Серокой:
au>> *It's not a lot of work unless you have to do it.*©
Сергей-4030> Еще раз, резюмируем вашу точку зрения. Злые софтверщики заставляют хардверщиков сто раз переделывать сложную работу потому, что софтверщикам лень пальцем пошевелить. Вроде, я ничего не упустил, да? При этом, разумеется (без этого такой ситуации просто не получилось бы) софтверщики всего мира в преступном сепаратном сговоре.

Я лично прошу признать равноправие и искать баланса между ПО и железом.

Серокой> Ну да, не происходит! А как же ...
- всего лишь следствие исполнения программы. И только.

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

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

au>> MIB determined that one of the root causes of the mishap was an inadequate GN&C software development process
au>> MIB determined that there was an inadequate, system-level integration process
au>> MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap
au>> was a failure to implement existing (NASA) engineering requirements, standards and practices
au>> NASA Report: Overview of the DART Mishap Investigation Results - For Public Release | SpaceRef - Your Space Reference
au>> Мало?
Сергей-4030> Чего мало? Даже если допустить, что в процессе детерминирования все было гладко - что следует из вашей цитаты? Я как-то ни грамма не вижу, как из нее следует обязательность ассемблера. Inadequate systems engineering - это, извините, имхо как раз предполагает, что нужно использовать нормальные методы разработки, а не ковыряние в ассемблере, которое и есть - неадекватно в 99.9% случаях.

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