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

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

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

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

Дорогой Nikita. Я знаю что я читал, и в рамках ваших слов что не читали вы. Путать тут просто нечего. Я знаю об отказе топливной системы и прочего перечисленного, вы не знаете. Вам это не даёт покоя — что поделать.

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

Это не и только, это приятности, сделанные железячниками для того, чтобы программисты могли комфортно писать код на языке высокого уровня и не беспокоиться о том, как это внутри. А внтури - этакие уэллсовские морлоки.

au>>> MIB determined that one of the root causes of the mishap was an inadequate GN&C software development process
au> au>> MIB determined that there was an inadequate, system-level integration process
au> 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> au>> was a failure to implement existing (NASA) engineering requirements, standards and practices
au> au>> NASA Report: Overview of the DART Mishap Investigation Results - For Public Release | SpaceRef - Your Space Reference
au> au>> Мало?
Сергей-4030>> Чего мало? Даже если допустить, что в процессе детерминирования все было гладко - что следует из вашей цитаты? Я как-то ни грамма не вижу, как из нее следует обязательность ассемблера. Inadequate systems engineering - это, извините, имхо как раз предполагает, что нужно использовать нормальные методы разработки, а не ковыряние в ассемблере, которое и есть - неадекватно в 99.9% случаях.
au> Знаете, это уже просто смешно. Я специально оставлю полную цитату как памятник всей этой мучительной и безысходной дискуссии.
au> И оставьте резюмирование моей точки зрения мне самому.

А вы объясните, что смешно - посмеемся вместе. Вы имеете в виду, что inadequate, system-level integration process значит - ассемблера маловато, так?

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

Сергей-4030> . Это значит, что у проектировщиков железа их (безусловно сложные) задачи просто имеют другие акценты этой сложности, не алгоритмические.
Пусть так! Но это же не значит, что неалгоримические баги не надо отлаживать!

au> Спор вот о чём.
au> Разработка систем управления и ...Системного дизайна нет; сегментирование системы если и делается, то на сумрачно-подсознательном уровне "по понятиям", точно по вашим словам:
И при чем тут вина программистов? Тут консерваторию надо править.
К моим словам отношения практически никакого за исключением того что программная часть системы управления, весом 1000 человеко-лет работы, безусловно должна переноситься на следующую аппаратную платформу, весом 100 человеко-лет, легким движением руки.

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

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

Неужели кто-то где-то запрещает вам искать подобное равноправие?! Неужели вы серьезно полагаете, что имеется в виду неравноправие? Вы что, правда думаете, что затраты на отладку/тестирование больших пакетов больше затрат на отладку-тестирование "железных" проектов из-за чьей-то злой воли? Неужели вы думаете, что производители ПО, коли им так легко проводить отладку, не согласились бы взять ее (и соответствуещее вознаграждение, разумеется), если б это для них было легче? Ведь эта цена все равно снимается с клиента! Рассмотрим пример: делается кристалл, делается ПО в котором используется кристалл. Условно, работа по отладке кристалла - мильон долларей. Работа по адаптации ПО к неотлаженному кристаллу много дешевле (по вашей версии ) - скажем, 10000. Клиент готов платить мильон (т.е. по факту платит, ибо работа все равно должна быть проделана). Разработчик софта, по вашему, такой гадкий, что поступится мильоном прибыли, только чтоб подгадить производителю кристалла? Вам самому-то не смешно?

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

Серокой> Я нигде не говорил о воздушно-идеальной машине Тьюринга. Я говорил о жесткой реальной системе.

Да какая же она воздушно-идеальная, ее вам реализовать - проще пареной репы. И вообще - что за стрелки? Вы говорили:

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

 

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

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

Вы опять мне приписываете то, что я не говорил. Ещё раз: отладить железо так же сложно, как и ПО. То, что ПО делается больше по объёму кода, не говорит о том, что оно сложнее в отладке! Один программный пакет по трудности отладить так же, как и одну микросхему!

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

Пусть даже так. Но почему из этого следует, что все эти навороты не требуют отладки? Как раз наоборот, они существенно усложняют её!

Сергей-4030> Это все применимо к машине Тьюринга ничуть не хуже, чем к любому другому процессору. Значит, саму машину Тьюринга отлаживать тоже не проще, чем любое ПО, которое на ней выполняется. Это - прямое следствие из ваших слов. Поскольку мы явно видим, что следствие неверно, то значит и рассуждать более нечего - вы неправы.

Нет. Машина Тьюринга не подразумевает того, что находится вутри современного процессора, все эти улучшалки, убыстрялки и прочие 3dNow!.

Сергей-4030>>Вы что, правда думаете, что затраты на отладку/тестирование больших пакетов больше затрат на отладку-тестирование "железных" проектов из-за чьей-то злой воли?
Серокой> Вы опять мне приписываете то, что я не говорил. Ещё раз: отладить железо так же сложно, как и ПО. То, что ПО делается больше по объёму кода, не говорит о том, что оно сложнее в отладке! Один программный пакет по трудности отладить так же, как и одну микросхему!

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

au>> Разработка систем управления и ...Системного дизайна нет; сегментирование системы если и делается, то на сумрачно-подсознательном уровне "по понятиям", точно по вашим словам:
hsm> И при чем тут вина программистов? Тут консерваторию надо править.
hsm> К моим словам отношения практически никакого за исключением того что программная часть системы управления, весом 1000 человеко-лет работы, безусловно должна переноситься на следующую аппаратную платформу, весом 100 человеко-лет, легким движением руки.

Не "вина программистов", а сложившийся порочный подход, в общих чертах описанный мною. И эту консерваторию в принципе действительно надо править. Только в принципе, поскольку это распространилось вплоть до лекций в универе, т.е. так уже учат. То, что в целом является комплексной инженерной задачей с нетривиальной оптимизацией, сейчас сводится к вопросу выбора операционной системы и языка программирования. Real-time Java — вас вот в этом словосочетании ничего не смущает? Свежачок-с, а там поди и трендъ.
Насчёт человеко-лет. Это также в общем случае совсем не тривиальное решение, так что безусловного в нём ничего нет. Первый полёт Ариан-5: "безусловно перенесли" некий качественный софт с Ариан-4, в результате ракета полетела за бугор. Это хорошая иллюстрация тому, что программное обеспечение — это часть системы, нравится это или нет, поэтому "перенести" его без последствий просто так нельзя, даже если очень хочется (особенно начальству). Когда на последствия можно забить — тогда и вопроса нет. А если копать глубже, в контексте темы, и почитать что говорят мэтры, то должны отпасть вопросы и про программы в 10млн строк, и про переносы туда-сюда, и про архитектуру, которую-таки надо знать независимо от языка. Никакие лёгкие движения рук кого бы то ни было не проходят без последствий для всей системы. Это должны понимать все, но проблемы с этим пониманием в первую (вторую и третью) очередь у горе-программистов. У хороших программистов такой проблемы нет, потому что они software engineers, а не "программисты".


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

Ох. Я вам сказал что это уже не актуально. Уже всё по-другому. Архитектуры изменились много раз. Машина Тьюринга не производится и не продаётся, пониаете?
То что годится для второй страницы учебника по компьютерной архитектуре, уже не является актуальным для разработки современной техники. Эти вещи надо знать и отличать.

Серокой> ...Один программный пакет по трудности отладить так же, как и одну микросхему!
Это лишенное смысла утверждение. Какую схему? Какой пакет? Набор инверторов К17хх и "Hello world!"? Сложность можно выразить в некоторых объективных единицах - исходников (схема электрическая, списки цепей, Verilog/VHDL, листинг) и документации. Дальше все просто.
ЗЫ
И все это давным-давно подсчитано и оценено. А мы здесь занимаемся толчением воды в ступе.

Сергей-4030>> Это все применимо к машине Тьюринга ничуть не хуже, чем к любому другому процессору. Значит, саму машину Тьюринга отлаживать тоже не проще, чем любое ПО, которое на ней выполняется. Это - прямое следствие из ваших слов. Поскольку мы явно видим, что следствие неверно, то значит и рассуждать более нечего - вы неправы.
Серокой> Нет. Машина Тьюринга не подразумевает того, что находится вутри современного процессора, все эти улучшалки, убыстрялки и прочие 3dNow!.

Понятно. А то, что вне современного процессора - сотни гигабайт сложного кода ваш подход подразумевает? И еще раз (третий), вы написали следующее:

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

 

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

Сергей-4030> Ваши рассуждения, извините, общи до полной потери смысла.
А я упрощал идею до общей. Потому как звучали не менее общие выражения - "ПО сложнее железа". И точка.

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

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

Серокой> Пусть даже так. Но почему из этого следует, что все эти навороты не требуют отладки? Как раз наоборот, они существенно усложняют её!
Вы приписываете оппонентам что-то дьявольское. Кто с этим спорит? Вы поймите - речь идет не о квалификации (таланте-гениальности-зарплате) конкретных исполнителей (разработчиков0-отладчиков) железа и софта. А о том что суммарные затраты труда на ПО превосходят таковые на железо. Чисто количественный показатель. Попробую такую аналогию - покраска авиалайнера требует больших затрат чем покраска истребителя (не Ф-22 ). В силу совершенно объективных причин.

ЗЫ
Для некоторого релакса участников (с толстым Инетом!) - зацените :

Сергей-4030> Еще раз, медленно (извините уж) - все, что вы написали, применимо к машине Тьюринга. И мы уже доказали, что это неверно.
Не применимо, современный процессор - не машина тьюринга. Как минимум, тем, что у Тьюринга за такт рассматривается одна ячейка памяти, в суперскалярных процессорах это не так.
А вообще написано было это скорее чтобы показать абсурдность заявления, что процессор - это "всего лишь" набор АЛУ и регистров. Это-то как раз действительно просто.

Сергей-4030> Если вы хотите дискутировать далее, вам стоило бы наложить некоторые ограничения на ваше исходное заявление, вам не кажется?
Я не вижу, честно сказать, смысла дискутировать уже со вчерашнего дня.

au> Ох. Я вам сказал что это уже не актуально. Уже всё по-другому. Архитектуры изменились много раз. Машина Тьюринга не производится и не продаётся, пониаете?
au> То что годится для второй страницы учебника по компьютерной архитектуре, уже не является актуальным для разработки современной техники. Эти вещи надо знать и отличать.

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

hsm> А о том что суммарные затраты труда на ПО превосходят таковые на железо. Чисто количественный показатель. Попробую такую аналогию - покраска авиалайнера требует больших затрат чем покраска истребителя (не Ф-22 ). В силу совершенно объективных причин.
Так я согласился с этим ещё вчера! Что поскольку на один проц (точнее систему) можно навернуть бесконечно много софта, то это так, да, и вы правы!

hsm> ЗЫ
hsm> Для некоторого релакса участников (с толстым Инетом!) - зацените :
В "просто юморе" уже постили.

au>Это хорошая иллюстрация тому, что программное обеспечение — это часть системы, нравится это или нет, поэтому "перенести" его без последствий просто так нельзя, даже если очень хочется (особенно начальству).

Очень распространенная точка зрения, особенно когда очень хочется монополии (впрочем, ее всегда хочется). Если бы я был производителем гвоздей, я бы сказал так: "проектирование дома - это часть системы гвоздерасположения, нравится это кому-то или нет".

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

Да верю, конечно, что за проблема? Есть они, очень-очень-очень сложные микросхемы. Но из того, что я вижу в реальном мире (стоимость разработки среднего пакета ПП много выше разработки средней микросхемы) я делаю вывод, что в среднем сложность микросхемы ниже. Что за проблема-то? Я ж не делаю из этого вывод, что разработчики микросхем в среднем глупее, правильно?

Сергей-4030> Если бы я был производителем гвоздей, я бы сказал так: "проектирование дома - это часть системы гвоздерасположения, нравится это кому-то или нет".
...но сейчас Вы - программист, откуда следует - ...

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

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