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

au>> Насчёт отношения к делу. Увы, оно имеет свои последствия. И последствия эти — паталогически некачественные продукты. Опять же, для кого-то безошибочная компиляция — уже качество; для кого-то нужна гарантия баг-фри, или все в сад.
Сергей-4030> Я не понял, в чем связь баг-фри и ассемблера?

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

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

В том пресловутом 1%. В любой требовательной задаче по ДСП — там чудеса программизма, только это уже software engineering. Достижение — это качество их продукта, решение задач минимальным железом, и как следствие улучшение прибыльности — прямая выгода компании. Другой вариант — конкурентное превосходство, когда с одним и тем же железом хорошие инженеры могут "500", а плохие только "200". Вторые будут ждать два года пока железо вытянет их работу на "500".

Сергей-4030> Ага, то есть, как минимум, ваши примеры - исчезающе редки (иначе бы вы нашли, правильно?). И вообще - показательно, два столбика вы помните, а результата нет.

С вами очень трудно разговаривать.

Сергей-4030> Все, список окончен.

Это ваш список окончен. Короткий и просто "ваш". У меня список другой, нулевая корреляция с вашим. На этом стоит поставить точку, мне лично уже неинтересно.

au>>>Переделывать железо под драйверы — это не абсурд, а полный кретинизм.
Сергей-4030>> Абсурд - делать дорого там, где можно сделать дешевле. Все остальное - предрассудки.
au> Это "дешевле" такого рода: или я заплачу доллар, или сосед заплатит тыщу. Мне дешевле чтобы сосед заплатил тыщу.

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

Сергей-4030>> Все, список окончен.
au> Это ваш список окончен. Короткий и просто "ваш". У меня список другой, нулевая корреляция с вашим. На этом стоит поставить точку, мне лично уже неинтересно.

Согласен, мне тоже неинтересно.

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

Пример очень удачный. Просто ты мыслишь про БПФ как некий алгоритм с фиксированным набором точек. А подумай немного, когда понадобится 2²⁰ на 2²⁰ точек. Что ты будешь с этой схемой делать?

au> Связь в том, что на ассемблере можно сделать баг-фри.

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

Даже C++ позволяет при тех же затратах писать код, в котором багов меньше если не на два порядка, то хотя бы на порядок. Про всякие Явы, Хаскеллы, Окамлы и Ады тут лучше даже не заикаться. Разница будет такая, что проще сразу застрелиться

au> Ассемблер не "улучшает", и как автор написал, так и будет. Это очень способствует повышению качества.

Только писать нужно намного больше. И ассемблер не заметит огромное количество синтаксических ошибок и совсем не заметит ошибок логических

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

Предмет у них уже сложнее. Старые методы не подходят.

au> Нормальный программист не знает и не хочет знать что такое ассемблер; а слово микрокод для него вообще пустой звук.

Нормальный инженер не знает много чего из физики и не хочет знать. И спины для него пустой звук.

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

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

au> Просто skill shortage, хоть убейся.

Он везде.

au>> Связь в том, что на ассемблере можно сделать баг-фри.
Balancer> "баг-фри" можно на любом языке написать.

Имеется в виду верификация, как я понимаю.

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

А чего же вы пользуетесь-то буржуйским — CAD/CAM/CAE/PDM/PLM, а так же OS, Compilers, text editors, etc — написали и сделали бы своё. Или кишка тонка? Тогда советую сидеть потихоньку. Вон Володя Малюх приглашал программистов для написания bCAD-а — чего-то немного желающих нашлось.

Ну вы ребята и наплодили. Сразу видно кем работают главные завсегдатаи А ещё Авиабаза называется...

Короче отвечу только на то что смог заметить в огне флейма с ходу

au> А потом, для их общего развития, дам им ссылку вот сюда: The page cannot be found
au> Цитата оттуда для нелюбопытных: Praxis produces zero-defect software for the US National Security Agency. С такими заявлениями и клиентом им нужно либо держать марку, либо расстаться с вторичными признаками. Похоже что они держат марку.

"Это ПиАр" (с) не мой

Вы статью-то читали ? А я вот читал.

NSA пока всего лишь изучали их методологию, путём заказа небольшой системки на пробу. В ней ~14000 строк кода на Аде (из них ~10000 ядро). Наваяли за 260 человеко-дней. Также там чётко написано что означает zero-defect: тестирование и некоторое время эксплуатации не выявило глюков. Причём есть маленькая сноска, что независимые тестеры таки два отказа нашли, но они дескать не в ядре, и вообще "Руководство Пользователя" виновато

Так что не надо, пожалуйста, песен.

*Домашняя работа: попробуйте правильно экстраполировать этот пример на ~1000000 строк кода...

au> Насчёт людей на ассемблер. Skill shortage не я выдумал — это просто запомнившаяся цитата.

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

au> Люди, пишущие на ассемблере, не раскладывают логику в машинные коды. Они знают архитектуру как свои пять пальцев, и думают в командах процессора.

Ха! Это архитектуру 8086 можно знать и помнить. Архитектуру же Pentium 4 Вы задолбаетесь как запоминать, так и строить в голове для неё эффективный код. Любой приличный компилятор даже архитектора этого самого Pentium 4 порвёт на тряпки.

Совсем недавно один товарищ у нас тут соревновался с микрософтовским компилятором: кто лучше цикл напишет. Наш "герой" там всякие repmov (или как их там) понаваял, тогда как компилятор построил на первый взгляд весьма примитивный код на регистрах и обычных jxx. Запустили: микрософтовский быстрее на порядок Товарищ покурил с полдня - чуть поправил своё творение. Запустили: микрософтовский всё равно быстрее в два с лишним раза Ну лучше он "знает" как устроен конвейер конкретного процессора, какие команды и как лучше всего разложить дабы они параллельно исполнялись и т.д.

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

au> Может вас удивит, но DSP сплошь и рядом программируют на ассемблере при давнем наличии довольно неплохих компиляторов.

Ковырялся я с DSP TI'шными в юности. Не надо, пожалуйста, сказок про "неплохие компиляторы". Убогие они, элементарных вещей не умеют. Поэтому и приходилось (и сейчас приходится, но не мне уже ) ручками на асме.

Nikita> Наш "герой" там всякие repmov (или как их там) понаваял

Сразу видно уровень этого "героя". Строковые операторы стали работать медленнее простых циклов ещё на i486. Об остальном уровне его кода уже по одному этому факту можно судить. Разница по скорости на сегодня как раз около порядка и будет (уже на 486 разница была почти вдвое, на Pentium - в 4..8 раз, ЕМНИП).

Nikita> Ну лучше он "знает" как устроен конвейер конкретного процессора

Просто этот твой товарищ ассемблера не знает Или учился по книжке для 8086

Nikita> Ситуацию ухудшает то, что выход каждой новой версии архитектуры запросто ломает все эти "знания как 5 пальцев".

ИМХО, таких "переломов" больше не было со времён Pentium. В смысле, конечно, появились MMX/SSE/SSE2/SSE3, которые сами по себе не заработают, если ассемблерный код про них не знает, но тут ещё такая фигня, что и компиляторы пока сами эффективно эти возможности использовать не могут. Как раз, как только дело доходит до оптимизации под эти механизмы, наружу достаётся ассемблер...

1.     /* post rotation + reordering */
2.     for (k = 0; k < n4; k += 2) {
3.         asm (
4.             "movaps          %0, %%xmm0 \n\t"   // xmm0 = i1 r1 i0 r0: z
5.             "movlps          %1, %%xmm1 \n\t"   // xmm1 = X  X  R1 R0: tcos
6.             "movaps      %%xmm0, %%xmm3 \n\t"   // xmm3 = i1 r1 i0 r0
7.             "movlps          %2, %%xmm2 \n\t"   // xmm2 = X  X  I1 I0: tsin
8.             "shufps $160,%%xmm0, %%xmm0 \n\t"   // xmm0 = r1 r1 r0 r0
9.             "shufps $245,%%xmm3, %%xmm3 \n\t"   // xmm3 = i1 i1 i0 i0
10.             "unpcklps    %%xmm2, %%xmm1 \n\t"   // xmm1 = I1 R1 I0 R0
11.             "movaps      %%xmm1, %%xmm2 \n\t"   // xmm2 = I1 R1 I0 R0
12.             "xorps       %%xmm7, %%xmm2 \n\t"   // xmm2 = -I1 R1 -I0 R0
13.             "mulps       %%xmm1, %%xmm0 \n\t"   // xmm0 = rI rR rI rR
14.             "shufps $177,%%xmm2, %%xmm2 \n\t"   // xmm2 = R1 -I1 R0 -I0
15.             "mulps       %%xmm2, %%xmm3 \n\t"   // xmm3 = Ri -Ii Ri -Ii
16.             "addps       %%xmm3, %%xmm0 \n\t"   // xmm0 = result
17.             "movaps      %%xmm0, %0     \n\t"
18.             :"+m"(z[k])
19.             :"m"(tcos[k]), "m"(tsin[k])
20.         );

Совершенно свежайший пример. Это ffmpeg-0.4.9_p20070129.

au> Отказоустойчивой, значит? А что же у них топливная система, связь, навигация, радар и всё остальное что под компом давеча отказали при перелёте через линию перемены дат?

Вы читали отчёт ? Я вот пока нет. Всё что официально известно - у 6-ти машин какой-то отказ ПО навигационной системы. У остальных вроде всё в порядке было. Так что из Вашего длинного списка пока остаётся только навигация. В которой также есть компоненты с firmware.

au> Всё остальное — не как в десктопах.

Ну не надо. Вы либо давно в десктопы не заглядывали, либо уже забыли что было ультракрутизной 10 лет назад.

au> Сравнение с "обычными" мощными системами корректно, но они в свою очередь нестанимы с десктопами даже когда процессоры одинаковые.

А это неважно. Прикладное ПО будет замечательно работать и на тех, и на тех.

au> Комп Ф-22 — это не далеко "просто железо", как и любой другой многоядерный гетерогенный комп,

Ну да, всяко не десктоп Однако он гораздо проще чем ПО на нём работающее. И переколбасить эту железяку на другую архитектору - PowerPC - у Raytheon'а особых проблем не возникло.

au> тем более для реального времени и высокой (типа) надёжности.

Ха! Так то самое "реальное время" это ведь ПО прежде всего и есть.

Balancer> Строковые операторы стали работать медленнее простых циклов

Даже на 486-х не всё так просто было. Ну да ладно, это дела давно минувших дней...

Balancer> Просто этот твой товарищ ассемблера не знает

Именно про это я и веду речь. Архитектуру современных молотилок не знает никто. Затраты на ассемблерную оптимизацию выросли на порядки. Без бутылки и кучи времени ничего эффективного не напишешь.

Balancer> ИМХО, таких "переломов" больше не было со времён Pentium.

Да постоянно. Новый степпинг - бумс - вдруг выросла латентность кэша в два раза. И приехали...

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

Именно. Поэтому вместо траты времени на изголения с ассемблером нужно компиляторы нормальные делать. Языки удобные для таких задач разрабатывать и т.д.

master> Дешевой рабочей силы и в Малазии хватает, но если Вы подразумеваете хорошие МОЗГИ,за которые можно дешево платить , то тут, я пожалуй соглашусь.

Дело не в качестве мозгов, а в тех знаниях, которые в этих мозгах уже были. Интел сэкономила на обучении. Частично, в общем-то, потому как часть железячников скаталась в США на "курсы повышения квалификации".

Nikita> Именно про это я и веду речь. Архитектуру современных молотилок не знает никто. Затраты на ассемблерную оптимизацию выросли на порядки. Без бутылки и кучи времени ничего эффективного не напишешь.
Как минимум знают системные программисты. Инициализация TLB или кэшей идёт только ассемблером. Ну нет в Цэ-плюс-плюс команды записи в TLB или инвалидации кэшей. )

Серокой> Как минимум знают системные программисты.

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

Серокой> Дело не в качестве мозгов, а в тех знаниях, которые в этих мозгах уже были.

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

Nikita>> Именно про это я и веду речь. Архитектуру современных молотилок не знает никто. Затраты на ассемблерную оптимизацию выросли на порядки. Без бутылки и кучи времени ничего эффективного не напишешь.
Серокой> Как минимум знают системные программисты. Инициализация TLB или кэшей идёт только ассемблером. Ну нет в Цэ-плюс-плюс команды записи в TLB или инвалидации кэшей. )

Если мне склероз не изменяет, существует интеловский компилятор в котором как раз эти директивы есть ( интренсы кажется называются )

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

Google что-ли?

Как-бы ни пошло, можешь в радостях жизни рассказать как было, как проходили интервью? Я сам сейчас всё это прохожу (из армии скоро освобождаюсь), поэтому мне эта тема (интервью на фирмы) внезапно стала интересна

Mishka> Пример очень удачный. Просто ты мыслишь про БПФ как некий алгоритм с фиксированным набором точек. А подумай немного, когда понадобится 2²⁰ на 2²⁰ точек. Что ты будешь с этой схемой делать?
Хых, ты вначале сказал именно про фиксированное количество точек!

xab> Если мне склероз не изменяет, существует интеловский компилятор в котором как раз эти директивы есть ( интренсы кажется называются )
Но тем не менее, это всё равно примочки компилятора, а не языка высокого уровня.

Серокой>> Дело не в качестве мозгов, а в тех знаниях, которые в этих мозгах уже были.
master> Из моего скрадного опыта- я считаю что это не совсем корректное утверждение. Дело в том, что знания в мозгах бывают разные,
master> а применить эти знания в реальных условиях многим проблематично, теряються почему-то. И тогда впрягается интелект, умение распоряжаться знаниями, как накопленныим так и полученныим.

Ну скажем так, это были не просто знания, а опыт работы с соврременными САПРами в области микроэлектроники, а также эти люди имели на счету выпущенный относительно удачный процессор.

Mishka> Пример очень удачный. Просто ты мыслишь про БПФ как некий алгоритм с фиксированным набором точек. А подумай немного, когда понадобится 2²⁰ на 2²⁰ точек. Что ты будешь с этой схемой делать?

Проведу разъяснительно-воспитательную работу с автором алгоритма, который такое заказал. Только так...
Пример из светлой юности. Лекция по конструированию, ведёт Инженер. (мой вольный пересказ)
-- Итак, что же значит технологичность. Вот, например, вы проектируете высокочастотный тракт на волноводах. Вам нужен некий резонатор, и коллега вам предлагает сделать резонатор в виде монолитного полого шара со сложной фигурной резьбой на внутренней его стороне. Это решение даст высокие характеристики, но как вы сделаете эту резьбу внутри монолитного шара?! Коллегу это не интересует, он же не конструктор. Для вас, конструктора, это решение абсолютно нетехнологично.
От себя добавлю: и потому бесполезно на практике, как и БПФ таких размеров.

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

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

Balancer> Даже C++ позволяет при тех же затратах писать код, в котором багов меньше если не на два порядка, то хотя бы на порядок. Про всякие Явы, Хаскеллы, Окамлы и Ады тут лучше даже не заикаться. Разница будет такая, что проще сразу застрелиться

При тех же затратах? Времени и зарплаты, как я понимаю. Я не зря указал применения систем, о которых говорю. Если аффтар может настрочить десять экранов кода в день, а потом куча народа будет итеративно вылавливать там дефекты на протяжении недель и месяцев, то это тоже включай в затраты. Я забыл цифру, но было такое по стоимости выправки косяков в софте в США. Какие-то дикие миллиарды баксов, или сотни — не помню. Чем дальше в проект, тем дороже эта работа. Логично понести малые (но более крупные относительно оплаты труда аффтара) затраты на сравнительно медленную и качественную работу, чем потом иметь шанс провалить большой бюджет и вообще весь проект. Про Аду ты погорячился — там с багами очень строго. Почитай.

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

Ну и пусть пишут больше. Писать мало и быстро для выпуска версии 0.1 можно в мусорном софте, а не в проекте с высокими требованиями и ценой. Это разные миры, как Северная Корея и северная Норвегия. Я кода писал на ассемблере, не испытывал проблем с огромным количеством синтаксических ошибок. Вот не было такого, и всё.

au> Пример из светлой юности. Лекция по конструированию, ведёт Инженер. (мой вольный пересказ)
au> — Итак, что же значит технологичность. Вот, например, вы проектируете высокочастотный тракт на волноводах. Вам нужен некий резонатор, и коллега вам предлагает сделать резонатор в виде монолитного полого шара со сложной фигурной резьбой на внутренней его стороне. Это решение даст высокие характеристики, но как вы сделаете эту резьбу внутри монолитного шара?! Коллегу это не интересует, он же не конструктор. Для вас, конструктора, это решение абсолютно нетехнологично.
au> От себя добавлю: и потому бесполезно на практике, как и БПФ таких размеров.
- На самом деле для настоящего Инженера здесь встаёт лишь одна проблема: можно ли получить из двух половинок, которые потом свинчиваются/свариваются/склеиваются, шар, по требуемым свойствам не отличающийся от монолитного?

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

au> И этот кеш, который, кстати, тоже давно изжил себя,... можно было бы получить линейную память без всяких кешей (что возможно для систем на чипе или систем в корпусе)
Вы представляете себе 4GB на одном чипе с процем? Выход годных и прочие ньюансы? Но даже если, современных гигагерц всеравно не достичь. Нет альтернатив пока.

au> Но нет, софт лежит на рельсах,...
Он лежит на рельсах проложенных принципами работы человеческого сознания.

au> нифига не хотят учиться новым архитектурам...
Это бессмысленно, учитывая скорость обновления архитектур и прикладного ПО. Имеет смысл только в областях применения где эти скорости существенно меньше, соизмеримы со временем карьеры разработчика.

au> Напомню, разогнать малое ядро на современной геометрии трудностей не составляет --
Трудности возниают при переходе на нормальный десктопный масштаб.

au> ...ГПУ считает физику; ГПУ считает обработку сигналов, не имеющих ничего общего с графикой; и т.п. ГПУ наступает на пятки ЦПУ, который вырождается в "ускоритель Виндоус".
Ну вот когда на ГПУ запустят Оракл или Кейденс... Тогда он не будет отличаться от типичного ЦП.
au> Это результат неправильного развития ЦПУ — см. выше про маспар.
А что "маспар"? Это новый философский камень? Вот проблема - заказчик хочет "в два раза быстрее", имеется возможность потратив полчаса на возню с маспаром добиться такого результата? Или надо потратить пару лет и получить ускорение 20%?

au> А всё равнно придётся. Как выкинули лампы, как выкинули транзисторы,...
Только с приходом квантовых компов. До тех пор основы современного ПО остануться незыблемы, также как и закон Ома для железа, на котором оно выполняется.