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

au>> А я вот понимаю и то и другое. Только трудно разговаривать с идейно-непоколебимыми программерами. На слово "ассемблер" в глазах появляется смесь ужаса, отвращения и уважения, как к тиранозавру.
Mishka> Я не знаю, Ау, сколько ты писал на ассемблере, но я, как реализатор библиотек поддержки для Алгола 68, на ассемблерах разных машин куковал не мало. Да и свои вещи писал не мало. Есть вещи, которые я и сейчас на нём делаю. Но это до определённой сложности проекта. А потом — С++ тот же убивает ассемблер на фиг. Хороша ложка к обеду.

Да порядком, если вспомнить. Под х86 мне больше всего на ассемблере нравилось писать. Под контроллеры разные — вообще только так. Тогда архитектуры были ещё вменяемыми. Потом под техасские дсп — была чисто фана торба, удовольствие получал. Мешал си с ассемблером — очень вкусно, системный уровень на сях, быстрые циклы на асм. Я мысль твою понимаю, не всё масштабируется и есть пределы. Но. Есть и обратное влияние, когда народ заведомо скоростные вещи лепит на С++, просто потому что уже больше никак лучше не умеет. Вот трагедия какая. Тебе класс, от асм до с++ и дальше. А они не знают что они программируют, что там в ящике вообще, как оно устроено. Это абсурд, но это и правда жизни. А посколько таких подавляющее большинство, уже вещи иначе и не мыслятся. Так что ложка хороша к обеду, но у некоторых только вилка.

Серокой> Что есть микрокод? Фурье - это сплошное умножение с накоплением результата. Что замечательно делается железно.

Там есть проблемы с точностью, которые на программном уровне решаются достаточно просто.

Серокой> А обратное неверно разве? Ну так пусть чисто программно всё и делается! Так нет же...

Обратное — не совсем — программного нет без аппартного. Это как фальник и арифметика. Вот нельзя сделать фальник без арифметики. Хотя задачи они решают разные.

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

Так я про то же самое — было раньше. Ушло. Поэтому ОС, к примеру, уже просто так не отладишь, не остановишься. Как говорят — принцип Гейзенберга в программировании.

Mishka> Посмотрел бы я на тебя в жизни, если бы тебя заставляли нагревать воду в чайнике по методу математика.
Зато, скажем, двоично-десятичная коррекция, которая якобы одна команда, на самом деле несколько команд, которые микрокодом выполняются на уровне процессора. Вот где ужас-то.

au> Так что то что стоит на столе — это никоим образом не заслуга программистов, не заслуга архитекторов, а 100% заслуга микроэлектроники. Все остальные деятели на ней паразитируют, или почти не помогают.

Да, а на чём они её разрабатывают? Сплошь на железных решениях? И что такое VHDL, как не заслуга программистов?

Mishka> И что такое VHDL, как не заслуга программистов?
Цитата из моего знакомого, про VHDL:
язык должен быть инструментом, а не головоломкой.©

Серокой>> Что есть микрокод? Фурье - это сплошное умножение с накоплением результата. Что замечательно делается железно.
Mishka> Там есть проблемы с точностью, которые на программном уровне решаются достаточно просто.
Я обоими руками за симбиоз! И за равноправие! Но почему-то программеры упорно считают, что железо второстепеннее. )

Серокой>> А обратное неверно разве? Ну так пусть чисто программно всё и делается! Так нет же...
Mishka> Обратное — не совсем — программного нет без аппартного. Это как фальник и арифметика. Вот нельзя сделать фальник без арифметики. Хотя задачи они решают разные.
Фальник? Сленговое название чего-то?

Mishka> Так я про то же самое — было раньше. Ушло. Поэтому ОС, к примеру, уже просто так не отладишь, не остановишься. Как говорят — принцип Гейзенберга в программировании.
Тем не менее срезку состояния можно получить быстро и в любой момент.
Хотя и тогда люди были - гвозди делать из таких. Например, найти на транзисторной логике причину сбоя в какой-нть ЕС ЭВМ лохматых годов... Ы-ы-ы... Там одних напряжений питания 8 штук...

Balancer> Ты хочешь сказать, что, скажем, софт того же Бурана был "по определению" сложнее железа?

Где-то был топик с описанием бурановского железа... Давно правда... найти бы.

au>> Развиваться ГПУ будут до тех пор, пока не будет достигнуто киношное качество.
hsm> Вот до этого и осталось 1-2 поколения. А дальше - финишь, если только трехмерные экраны не оживят это направление. Но даже если - потребительский предел ясно видим, нет смысла генерить 10000 кадров в секунду если достаточно 60. Для универсального ЦП такого предела не видно.

Да не финиш. Непочатый край в физике и разной "хореографии" — массовые сцены, хотябы лес с ветром — зашибись расчётов там, и ЦПУ не поможет никакой, только массивно-параллельные считалки. ЦПУ, как его не мучай, остаётся последовательным, и ничего с этим не поделаешь. Виной тому, кстати, как раз программисты, которые успешно угробили все благие начинания — тот же транспьютер — а теперь, уже по воле интела, всё повторяется, но на извращённом уровне. Вместо тысяч ядер, возможных сегодня на чипе с концепцией транспьютера, имеем несколько с огромной кучей кеша. И этот кеш, который, кстати, тоже давно изжил себя, подпирает разбухший софт. Если бы делалось только то, что нужно делать, если бы софт писался оптимально, а не всё одним пальцем, то можно было бы получить линейную память без всяких кешей (что возможно для систем на чипе или систем в корпусе), кучу ядер (к чему волей-неволей идёт дело), и кто знает ещё чего. Но нет, софт лежит на рельсах, программеры сперва учатся (в универах) писать последовательно, потом изобретают способы распараллеливания (не слишком удачно), нифига не хотят учиться новым архитектурам (маспар давно доступен), и мы имеем что имеем. Напомню, разогнать малое ядро на современной геометрии трудностей не составляет — см. на процы во всяких гаджетах, и давно было бы то, что нынче интел подаёт как диво дивное: проц с 80 ядрами покомпактнее и распределённой памятью. Как говорится, Welcome to twenty years ago.

au>> даже AI (простите за выражение) уже норовят выделить в ускоритель, хотя пока это мечты. В принципе генеральная линия направлена на игровую приставку и медиацентр в одном корпусе.
hsm> Логично, если нужна именно игровая приставка. Но это не весь рынок.

Это метод. Графика, физика, и вот аи можно разносить на выделенные вычислители. А они, как это теперь случилось усилиями нвидия, могут быть программируемыми. И, о ужас! — ГПУ считает физику; ГПУ считает обработку сигналов, не имеющих ничего общего с графикой; и т.п. ГПУ наступает на пятки ЦПУ, который вырождается в "ускоритель Виндоус". Это результат неправильного развития ЦПУ — см. выше про маспар.

au>> .Мы несколько отклонились от темы.
hsm> Это точно

Но всё же не очень. КОТС влазит в военное железо, со всеми вытекающими...

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

Я про качества уже сказал. Меня лично полностью устраивала Винда-95 на П-100 с 32М памяти. Сейчас это сколько-то процентов от дешёвого телефона. Меня так же устраивает ХР, но под ней уже проц на порядок быстрее, памяти на порядок больше, а для меня разница не ощущается. Виста ещё добавила порядок на всё, с учётом многоядерных процев.
Насчёт производительности. Если закрыть глаза на Винду и прочее такое, если посмотреть на задачи, которые требуют максимальной мощи, то там всё замечательно. Пример — радары. Кто бы подумал что АФАР на тыщу модулей влезет в ~250кг? Вот это польза, вот это разница, и вот это производительность. Но если бы эти радары программировались на каком-нибудь C++++, не было бы ничего по куче причин. Это контраст. Кстати, в них фпга идут со свистом.
Насчёт виртуальной машины. Это, на мой взгляд, то, что хотят горе-программисты. Типа, "я напишу как смогу, а ты уж давай отработай без синих экранов". Как Мишка справедливо указал на пределы масштабируемости асм и прочего, есть пределы "отрыва от физики". Заабстрагировавшись от железа до абсурда, абстрагируются и от роста мощи железа, компенсируя его ростом неэффективности использования софтом ресурсов машин. В результате, как в примере выше, та же винда особо не меняет потребительских качеств на протяжении десятка лет, не смотря на рост мощи на порядок (или порядки — где как).

au>> Просто, как я уже пытался объяснить, вполне нормальная концепция была деформирована и доведена до полного абсурда и, на сегодня, логического тупика.
hsm> Концепция - "выкиньте все, во что вы вкладывались последние годы (десятилетия), и начните жизнь с читого листа" - нежизнеспособна.

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

au>> Тем не менее, когда дело доходит до серьёзных дел, всё становится на свои места. У некоторых. Не всегда. Вот у Ф-22 не совсем встало, хотя, уверен, там за этим пытались следить хотябы просто по инерции.
hsm> Мир вообще не совершенен. Тем не менее куда-то движется. Вояджер все-еще летиит, марсоходы ползают, и Ф-22 отдебажат. Когда-то было иначе?

hsm> По теме - у Ф-16 поначалу обладал такой "фичей" - при пересечении экватора переворачивался вверх ногами. Была обнаружена и пофиксена при очередной перетряске ПО.

Это глюк. Давеча освежил — Ф-16 летел над Мёртвым морем на малой высоте, т.е. на отрицательной высоте над уровнем моря. И у него не отказало всё на свете, как в случае с Ф-22. Прогресс.

Серокой>> А вот с БПФ странно - оно замечательно ложится на железо. Просто просится...
Mishka> Давай, без микрокода.

Мишка, БПФ как раз без микрокода ложится на железо. Есть стройная схемка-лесенка (или как по-русски на жаргоне?) из сумматоров со связями, на выходе у неё БПФ. Пример просто неудачный, но мысль понятна.

au>> Так что то что стоит на столе — это никоим образом не заслуга программистов, не заслуга архитекторов, а 100% заслуга микроэлектроники. Все остальные деятели на ней паразитируют, или почти не помогают.
Mishka> Да, а на чём они её разрабатывают? Сплошь на железных решениях? И что такое VHDL, как не заслуга программистов?

Мы не делим заслуги и не пинаем программистов. Речь о методах и отношении к инженерному делу. У программистов последние два пункта хромают на всю голову. Ты, как я понял, совершенно нерепрезентативен. Нормальный программист не знает и не хочет знать что такое ассемблер; а слово микрокод для него вообще пустой звук.
VHDL — это продукт и заслуга computer engineers. Лишь очень малая доля программистов может претендовать на это достойное звание. То же, кстати, по Аде. Чем больше узнаю (заинтересовало), тем больше уважаю. Ассемблер, как пример, просто требует чтобы программист был хоть плохоньким, но инженером. Поэтому писатели его ненавидят. Но это не значит что программист, будучи инженером, обречён всю жизнь всё на свете писать только на ассемблере. Далее, тот же (хороший) программист может хорошо писать на С++, но я уже не уверен что результат будет хорошим, т.к. результат этот — плод не только работы этого программиста, но и серой массы, которой я ни грамма не доверю важное дело. Потому что серая масса не состоит на 100% из хороших программистов-инженеров, и бесконечно строит патчи-версии-релизы (patch culture), что для инженера просто недопустимо. Это не значит что программист-инженер должен с полпинка выдавать идеальный софт, но это значит что хороший инженер с хорошими инструментами (что по определению исключает языки выше С) должен делать хороший софт, т.е. когда он закончит, он должен сказать "я закончил — получите". И не начинать с того момента делать критикал апдейты, сервис паки, патчи, багфиксы и т.д и т.п. Вот это — программист, который просто не инженер, а писатель прозы. То что ты тут написал позволяет мне думать что ты хороший программист. Но, увы, снова, таких как ты — единицы на тыщу, и это реальный дефицит, из-за которого проекты порой вынуждены использовать С++ там где явно нужен ассемблер. Просто skill shortage, хоть убейся.

VooDoo>> К счастью, военное железо всё таки отстает от гражданского .
master> Поясни


VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого

au> Мы не делим заслуги и не пинаем программистов. Речь о методах и отношении к инженерному делу. У программистов последние два пункта хромают на всю голову. Ты, как я понял, совершенно нерепрезентативен. Нормальный программист не знает и не хочет знать что такое ассемблер; а слово микрокод для него вообще пустой звук.

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

au> Но, увы, снова, таких как ты — единицы на тыщу, и это реальный дефицит, из-за которого проекты порой вынуждены использовать С++ там где явно нужен ассемблер. Просто skill shortage, хоть убейся.

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

VooDoo>>> К счастью, военное железо всё таки отстает от гражданского .
master>> Поясни
master> VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого

Во всех странах, где хоть сколько-либо развита эта область. Скажем, в США. В Индии.

VooDoo>>> К счастью, военное железо всё таки отстает от гражданского .
master>> Поясни
master> VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого

В Израиле так точно. Думаю что и в США.

au> Ну, раз уж я дежурный сегодня..
au> Во-первых, рост мощи процев (всех на свете) — это сугубое достижение микроэлектроники. Только за счёт её успехов стали возможны гигагерцы и почти уже гигатранзисторы в рамках более-менее приемлемой потребляемой мощи. Только благодаря ей стали возможны и гигабайты. Все эти достижения сделали более-менее жизнеспособным тот метод создания программного обеспечения (вдумайтесь в слово: обеспечение). Русским языком: прогрессирующе неэффективные методы и результаты создания прог выезжают на пока растущей микроэлектронике.

Вы говорите, извините, херню. Там, где дешевле обновить железо - надо обновлять железо, естественно. А вот буквально вчера я был на интервью в одной очень интересной компании, так там буквально все интервью были построены примерно так - вот возьмем направленный граф и попробуем найти, есть ли циклы в нем. Отвечаешь - OK, не проблема, делаем так и так. Хорошо, говорят, а теперь считаем, что число вершин в графе - сто миллиардов, а число связей - триллион, не помещается, разумеется, ни в какую память и даже не во все дисковые массивы, при том результат должен быть готов через 10 секунд. И что, куда вы ваши знания ассемблера и микроэлектроники приткнете? Между прочим, класс задачек - именно тот, с которым та компания сталкивается.

au> Вы не в курсе дела
Я в курсе дела.

>объясняю. Проведите эксперимент. Любую 3д игру с динамикой остановите на паузу. Потом остановите на паузу те же звёздные войны в сцене с высокой динамикой (бой со стрельбой). Рассмотрите внимательно, и вы увидите что такое киношное качество. Всё дело в свете и особенностях отрисовки, а это вполне на пути развития ГПУ. К самим играм это может не иметь отношения вообще.

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

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

>VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого
Не ПО, а железо.

>>VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого
VooDoo> Не ПО, а железо.

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

>И ПО, и железо.
Тем хуже.

au>и это реальный дефицит, из-за которого проекты порой вынуждены использовать С++ там где явно нужен ассемблер. Просто skill shortage, хоть убейся.

Да, только вы забыли упомянуть, что доля этих проектов в общем числе - там, где ДЕЙСТВИТЕЛЬНО нужен ассемблер - исчезающе мала.

au> Я мысль твою понимаю, не всё масштабируется и есть пределы. Но. Есть и обратное влияние, когда народ заведомо скоростные вещи лепит на С++, просто потому что уже больше никак лучше не умеет. Вот трагедия какая. Тебе класс, от асм до с++ и дальше.

Так это не программистов трагедия — это всеобщая трагедия.

au> А они не знают что они программируют, что там в ящике вообще, как оно устроено.

Но не надо в обратную сторону ударятся — не видеть леса за деревьями.

au> Это абсурд, но это и правда жизни. А посколько таких подавляющее большинство, уже вещи иначе и не мыслятся. Так что ложка хороша к обеду, но у некоторых только вилка.

Сколько инженеров понимают математическую подоплеку БПФ? 6 лет назад был такой разговор с ab, если помнишь такого из Владика.

Серокой> Зато, скажем, двоично-десятичная коррекция, которая якобы одна команда, на самом деле несколько команд, которые микрокодом выполняются на уровне процессора. Вот где ужас-то.

Да почему ужас-то? Всякому овощу своё время. Всякой букашке — свои таракашки.

Серокой> Я обоими руками за симбиоз! И за равноправие! Но почему-то программеры упорно считают, что железо второстепеннее. )

Да не второстепенное оно. Оно первично. Просто масштабы задач разные. И каждый кулик своё болото хвалит.

Серокой> Фальник? Сленговое название чего-то?

Функциональный Анализ.

Серокой> Тем не менее срезку состояния можно получить быстро и в любой момент.

А что она даст? У тебя слово состояния — гигабайты сейчас. Количество вариантов — надо перечислять?

Серокой> Хотя и тогда люди были - гвозди делать из таких. Например, найти на транзисторной логике причину сбоя в какой-нть ЕС ЭВМ лохматых годов... Ы-ы-ы... Там одних напряжений питания 8 штук...

Я уже рассказывал на форуме, как мы помогали инженерам искать проблему в логике исполнения команды сравнения на ЕС-1046.

>>VooDoo поясните ПОЖАЛУЙСТА, где и в какой стране военное програмное обеспечение отстает от гражданскогогогого
VooDoo> Не ПО, а железо.
Железо тоже, процессоры со своей высокой скоростью обработки иныолрмации как не странно зависят от дисководов .... от банальных маленьких двигателей, которые раскрутят диск и передадут информацию. В моей стране, по крайней мере на уровне микродвигателей, порядок

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

Пардон, что вмешиваюсь в беседу программистов, но эту фразу надо будет непременно "влепить" разработчикам CAD/CAM/CAE/PDM/PLM, наипаче американским, как они уже достали своими недоделками и вумными рассуждениями о тяжёлой своей доле, за наш счёт разумеется.