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

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

Сделайте лучше, без недоделок. Заодно мильенером станете.

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

Сергей-4030>Сделайте лучше, без недоделок. Заодно мильенером станете.

Не... пища, кров, гарантия безопасности личной и имущества (всё это из расчёта 1 работающий на 7 иждивенцев) + абсолютная свобода добродетели. Этого довольно.
Мильёны же $, (а ведь именно это в Америкосии ставится во главу угла, не правда ли?) с собою в могилу не утянешь, разве в сугубое осуждение.
А вот когда их нерусская доля и в самом деле станет менее располагающей к бредням о своём превосходстве и мировой гегемонии, хотя бы даже мыслью о том, что у него конкретного человечка все шансы разделить участь многих нашедших свой гроб в полях России - вот это будет хорошо, это порядок. Славою же сочтёмся позже.

Кстати, откуда таки глюки F-22 растут предположить хотя бы сможет кто?
Или всёж надо его в ЛИИ перегонять, например посредством тонко воздействующего на навигационную систему вируса?

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

Ну, значит соотечественникам раздадите. Сотню пенсионеров обеспечите пищей, кровом и т.п. Разве это не благородно?

мужественный> Мильёны же $, (а ведь именно это в Америкосии ставится во главу угла, не правда ли?)

Именно. Буквально вот вчера считал варианты - выгодно ли мне сдать детей в больницу для опытов. Получается пока невыгодно. Надо еще родственников из России привезти и сдать тоже.

VooDoo> Как и с процессорами.


http://www.medteh.ru/article-62825.html

VooDoo>> Как и с процессорами.
master> http://www.medteh.ru/article-62825.html

Не надо туфту всякую постить, пожалуйста. Интел нанимает не "разработчиков суперпроцессоров", а дешевую рабочую силу и, афаик, даже не в "суперпроцессорные" департменты. Вы бы еще про супер-дупер-процессор всех времен и народов Эльбрус-3 бы порассуждали.

Сергей:

Вы посмотрите на название темы и учитывайте этой контекст. Я его тут учитываю. То что можно выдумать нерешаемую задачу, или нерешаемую определённым методом задачу — это ёжику ясно. Я вот выставлю требование написать мне баг-фри софт, и послушаю ваших интевьюеров, как они будут выкручиваться. А потом, для их общего развития, дам им ссылку вот сюда: The page cannot be found

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

Насчёт людей на ассемблер. Skill shortage не я выдумал — это просто запомнившаяся цитата.
Насчёт реальных проектов. У вас они одни, у других другие, и цели и приоритеты в каждом разные. То что важно для вас, не имеет значения для других, и наоборот. Удивляюсь что вы этого не понимаете.
Насчёт отношения к делу. Увы, оно имеет свои последствия. И последствия эти — паталогически некачественные продукты. Опять же, для кого-то безошибочная компиляция — уже качество; для кого-то нужна гарантия баг-фри, или все в сад.
Насчёт превосходства компилятора над человеком. Тут не о чем спорить. Если у вас так получилось, значит у вас просто не получилось. Может вы не знаете ту архитектуру. Люди, пишущие на ассемблере, не раскладывают логику в машинные коды. Они знают архитектуру как свои пять пальцев, и думают в командах процессора. В результате получается хорошо или очень хорошо, но есть предел по сложности. Ассемблер с наскока не берётся именно из-за необходимости знать архитектуру и возможности процессора. Это всё равно что пересесть с велосипеда в истребитель, и либо критиковать что он не едет, либо ожидать сразу взлетишь в небо. Этому учатся, тренируются, и потом за ноги не оттащишь. Ваш пример с ассемблером потому совершенно некорректен.
Я помню пример, который вы попросили, но найти не смог. Там в два столбика человек и компилятор — никаких вопросов не остаётся. Хороший компилятор делает не хуже человека простые вещи. Когда вещи уже не простые, компилятор делает консервативно, и результат уже другой. Может вас удивит, но DSP сплошь и рядом программируют на ассемблере при давнем наличии довольно неплохих компиляторов. Системный уровень на них сбагрить приятно, а вот ядра алгоритмов — "нафиг-нафиг"(с).

VooDoo>>> Как и с процессорами.
master>> http://www.medteh.ru/article-62825.html
Сергей-4030> Не надо туфту всякую постить, пожалуйста. Интел нанимает не "разработчиков суперпроцессоров", а дешевую рабочую силу и, афаик, даже не в "суперпроцессорные" департменты. Вы бы еще про супер-дупер-процессор всех времен и народов Эльбрус-3 бы порассуждали.

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

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

Только как fallout. В других областях такие фокусы просто не проходят — не абстрагируешься при всём желании, нужно учить матчасть, или сразу на кислород.

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

Mishka> Сколько инженеров понимают математическую подоплеку БПФ?

Ну, мне трудно сказать. Тут вот DSP — обязательная часть курса на бакалавра. Там всё это показывается-рассказывается-сдаётся, и куча прочего подобного. БПФ — это вообще-то типа DSP-101, как "здрасти". Как опция есть real-time DSP — вот это как хорошая раз проверка на вшивость. Даётся сигнал, даётся макет с DSP, и нужно получить на осциллографе правильный результат. Делай как хочешь, кувыркайся как умеешь, а от сигнала не абстрагируешься. Если будет гений, способный на С сделать — медаль ему, седло и телевизор. Но в реальной жизни, если железка способна считать сигнал в два раза чаще, а религия не позволяет овладеть ассемблером, человека пошлют в сад. Ибо балласт.

Серокой>> Тем, что пропала красота и изящность решения RISC.
Mishka> Замечательная простота. Простота для железячников. Для того, чтобы сложить два числа в памяти мне надо (a=a+b):
Mishka> ld r1,a
Mishka> ld r2,b
Mishka> add r1,r2,r1
Mishka> st r1,a
Mishka> Всегда. Вместо одной команды:
Mishka> add a,b,a

Вообще-то, команда так и остаётся одна. a += b;

У RISC всегда позиционировалось перекладывание части работы с плеч и программиста, и железячника, на "плечи" компилятора. Как и у VLIW, кстати, но там другой подход. Но - тоже компилятор.

...

Тем не менее, кстати, выбирая между программированием на ассемблере x86 и программированием на ассемблере ARM я не задумываясь выберу ARM

>Intel скупает российских разработчиков суперпроцессоров
Легко можно понять, что ситуации с процессорами в моей стране это не улучшает.

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

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

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

Производительность центрального процессора (по Гибсону), оп./с	370 тыс.
Число команд центрального процессора	74
Емкость ОЗУ, в 32-х битных словах	128K
Емкость ПЗУ, в 32-х битных словах	16K
Число процессоров ввода-вывода	4
Число линий связи подключения абонентов	21
Логический код обмена информацией с абонентами	последовательный, 36-разрядные кодограммы
Тактовая частота обмена информацией с абонентами, МГц	0,25
Энергопотребление, Вт	270
Напряжение литания, В	27
Температурный диапазон, ⁰С	-10...+50
Масса, кг	33,6

// БЦВК

И это чудо обеспечивало автоматическую посадку

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

Они немного в курсе. Один из них, например, по совместительству начальник крупного центра в Карнеги-Меллоне (не вчерашний, но из той же конторы). Собственно, если все пройдет хорошо я озвучу имя, надеюсь, будет звучать убедительно. Что, впрочем, вряд ли - интервью там зверские.

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

Кто ж не понимает - да, есть проекты, где важен ассемблер. Скажем, в 1 % всех проектов.

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

Я не понял, в чем связь баг-фри и ассемблера?

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

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

au> Я помню пример, который вы попросили, но найти не смог.
Там в два столбика человек и компилятор — никаких вопросов не остаётся. Хороший компилятор делает не хуже человека простые вещи. Когда вещи уже не простые, компилятор делает консервативно, и результат уже другой.

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

Еще раз, отделим мух от котлет. Вы фактически заявили, что есть проекты, в которых переход от грамотно написанного кода на С, C++, Java к ассемблеру даст существенное увеличение эффективности, правда? Дайте, все таки, класс таких задач. Впрочем, давайте я буду гадать.

1. UI. Не улучшается полезно с вашими подходами. Конкретно - на плоских UI отрисовка уже и так более чем достаточно быстра. Увеличение фактически не даст никаких плюсов.

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

3. Файловая система - то же.

4. Network - то же.

Что остается? Остаются:

a. Драйверы, системные библиотеки, ядро и проч. Интересно, но вполне специализированно.

б. "Околодрайверные" проблемы прикладных пакетов.

Все, список окончен.

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

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

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

Сколько апломба... А вы знакомы хоть с одним малазийцем? Китайцем, индийцем? Вы думаете, они генетически ущербны, куда им равняться с гениальными русскими, ага?

hsm> Вот до этого и осталось 1-2 поколения. А дальше - финишь

Какая такая финишЪ? Сцены, всего три-четыре поколения назад, дававшие 10..15fps, сегодня способны выдавать от 7000fps (на моём компе) до 15000fps (на более продвинутых). Банальный glxgears, например. И что? А на практике сегодня есть уже масса игрушек, которые на максимальных настройках дают у меня только 1fps. Или того меньше. Значит, ещё пара поколений только для того, чтобы сегодняшние игры не тормозили. А за это время напишут ещё ой, как много всего. Сегодня в играх ограничений ничуть не меньше, чем 15 лет назад. Это как со знанием. Чем больше возможностей, тем больше ограничений

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

К моему сожалению знаком, за ними моей фирме пришлось всю работу переделовать.

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

Да во всех. Или сегодня на гражданке где-то массово программируют те же i960?

au>Переделывать железо под драйверы — это не абсурд, а полный кретинизм.

Абсурд - делать дорого там, где можно сделать дешевле. Все остальное - предрассудки.

master>>> Дешевой рабочей силы и в Малазии хватает, но если Вы подразумеваете хорошие МОЗГИ,за которые можно дешево платить , то тут, я пожалуй соглашусь.
Сергей-4030>> Сколько апломба... А вы знакомы хоть с одним малазийцем? Китайцем, индийцем? Вы думаете, они генетически ущербны, куда им равняться с гениальными русскими, ага?
master> К моему сожалению знаком, за ними моей фирме пришлось всю работу переделовать.

Уточню за китайцами.

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

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

Другое дело, что на программировании на ассемблере уходит времени на разработку, минимум, раз в 10 больше. Я когда-то приводил пример: Мерянье пи... э... попугаями. Быстродействие языков. [=KRoN=#24.11.02 16:13] 45 минут против пары минут программирования на OCaml и худший по скорости результат

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

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

Сергей-4030> 1. UI.

На десктопе - да. Ассемблеру делать уже нечего. Правда, до сих пор встречаются девайсы, типа того же Casio PV Ну и эмбеддед.

Сергей-4030> 2. DB.

Тут - согласен.

Сергей-4030> 3. Файловая система - то же.

Вопрос спорный. find /usr/src/linux/ -iname *.s|grep fs выдаёт:
romfs.S
fsys.S
spu_restore_crt0.S
spu_save_crt0.S
initramfs_data.S

Может, что-то пропустил. Хотя, конечно, мэйнстримовые FS ассемблерного кода не содержат. Хотя наличие ассемблерного кода сорцах Linux - показатель. Ибо, это вам не Windows, тут переносимость нужна. Оно работает сегодня на x86/ARM/MIPS/PPC/Cell/Alpha/ia64/68k/sh/sparc/etc/etc...

Сергей-4030> 4. Network - то же.

Ebbedded?

Сергей-4030> a. Драйверы, системные библиотеки, ядро и проч. Интересно, но вполне специализированно.
Сергей-4030> б. "Околодрайверные" проблемы прикладных пакетов.
Сергей-4030> Все, список окончен.

В принципе:


916

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

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

Мешает Нужно знать не только особенности железа, но и тонкости компилятора. Собственно, я лет 12..13 назад немало с этим мучился с Watcom C++ 10. Ассемблера не хватало по скорости разработки, скорость компилятора была уже прекрасной (а некоторые решения компилятора по оптимизации сам в свои решения на ассемблере переносил ), но вот быстрые циклы - это был кошмар. Скажем, приходилось вместо:
for(int i=0; i<width; i++) { /* ... */ }
писать в духе
int i=width; while(--i>=0) { /* ... */ }
Только такое разворачивалось в банальный loop

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

Это "дешевле" такого рода: или я заплачу доллар, или сосед заплатит тыщу. Мне дешевле чтобы сосед заплатил тыщу.