зур с инфракрасной головкой самонаведения а-ля Питон

Wyvern-2> Вообшем, конструктор, програмист и боеприпасник должны быть в одной голове, а не в одной комнате

Это ушло с уходом травленных на кухне плат и 51-х контроллеров... Один человек в разумные сроки не способен охватить всё.

Nikita> Делает, только вот делает он его согласно стандартам. Ни интерфейсы памяти, ни USB, ни Ethernet он не изобретает, насколько я в курсе

За стандарты разговора не было — а вот железяку он делает свою.

Nikita> Причём здесь "позволит" ??? Это факт. Это реальные ГСН Javelin, PAM и т.п. У ведущих товарищей кастомные микрухи сегмент вычислительных задач такого толка уже давно слили.

Это понятно — частный сектор уже далеко ушёл. Делать всегда и везде своё железо и софт под него — никаких рессурсов не хватит. Но есть и исключения. Просто на сегодняшний день тот же Javelin покрывается существующими FPGA. Но, скажем, та же задача взлома некоторых криптоалгоритмов, как показали работы в том же MIT, при затратах около $100,000 решаются этой аппаратурой намного лучше, чем софтом на универсальных CPU.


Nikita> Да всё дают. Только вот когда бедность - не хватает всем пропорционально. И поэтому "Ариан" валился и от железа тоже - был косяк в конструкции охлаждающей рубашки сопла, например.

Не, на софт сокращают в первую очередь. И именно из-за того самого восприятия, что софт менять легко.

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

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

Серокой> Да не... Ну вот пример. Сделали мы usb стандарта on-the-go. Оказалось, что в Инете нет готовых драйверов к нему, и вообще программная модель у него не поддерживается Линуксом, да и Виндовсом тоже. Хотя какие-нибудь сотовые и прочите КПК используют именно эту модель. И что же? Пришлось выкинуть и делать всё заново. Только потому, что программисты не хотели писать драйвер...

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

Серокой> Да, именно так. ) Я не говорю, я никогда не утверждал, что "аппартатчикам" существенно сложнее или существенно проще. Я говорю, что их работа сравнима по сложности с работой программистов. Мне ж отказывают и в этой сентенции... Это меня крайне возмущает. )

Не в этой. Спроси, у кого из программистов есть те же верификаторы. Или у кого QA приглашают на дизайн продукта. Очень сильно удивишься. Тебе про это и говорят.

Серокой> Ну есть такое... Смотри выше - про USB. ТЗ уточняется, понимается, именно по мере выполнения НИОКР. Но вся беда в том, что понимание приходит программистам позже. Поскольку им на до работать на железке. Вот делаю я какое-о конкретное решение. Не противоречащее ТЗ, кстати. И оказывается, что у программистов иное видение проблемы, что они не могут, ну или не хотят, усложнять себе жизнь. И усложняют её нам, говря - переписывайте как надо нам... Увы. Я как-то приводил яркий пример с S3 и DirectX 10...

Должны работать вместе. А не по отдельности. Можно полностью спецификации открыть. Скажем, как некоторые японские конторы сделали для фришников и линуксят. Тогда сторонние могут прийти.

Серокой> Хуже того, чаще просто не соблюдены хазарды, которые прописаны в стандарте архитектуры! То есть программисты сами пишут как им на душу ляжет! А виноваты, от же прикол, снова железячники! То есть мы вынуждены по заявлению "у вас не работает!" включать в состав ПЛИС анализатор, разбираться с проблемой, чтобы уткнуться в то, что в коде не соблюдены все требования архитектуры!

Не, про это я не говорю. У нас есть несколько человек, которые этим занимаются. Называется процесс triage. Потом отдают более конкретным людям. Всё может ещё не раз поменяться. А код, который помогает отлаживать и/или диагностировать есть у всех.
Серокой> Мы не можем охватить всё. Даже с использованием случайных тестов. Я понимаю, что есть много разных программ, но смотри: время пришло. Мы запускаемся в производство. Программисты не смотли, не успели, не дали задание кому-то ещё проверить работу системы на каком-то реальном приложении. И только потом у них дошли руки. И выявляется какая-то абсолютно эндемичная ситуация. И кто виноват? А железка ушла в производство! И тут -то ошибку лечат программно. потому что так дешевле и проще.

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

au> Кстати, насчёт чая — раз уж тут Мишка пишет, спросите у него как в их организации с этим делом. И для разнообразия погуглите насчёт условий труда в Google Inc.
я в курсе условий труда в Google Inc
собственно, массажистка вынырнула из подсознания именно по их поводу.
другое дело - что такие условия труда рынок предлагает далеко не всегда...

Серокой> Во, и как-то на АБазве была душещипательная в своей художественности история про программу которая не влазила всего одним байтом. Опять страдает программист.
Серокой> А я мог бы рассказать, как писал контроллер статической ОЗУ на МАХ7064, и не не хватало всего одного регистра... Но нет такого таланта, нагнать словом сопереживание.

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

ko4evnik> другое дело - что такие условия труда рынок предлагает далеко не всегда...

Ну так пример был чтобы показать прагматичный подход, и его противоположность. Если у руководителя анализ идёт по критериям полезно/неполезно, то ему всё равно массажистка это, бесплатный буфет, надувной бассейн или четырёхдневная рабочая неделя. А если он мыслит критериями власти, кнутов и пряников, то он будет назначать объём ПЗУ волевым решением, и никаких "массажисток". Вот реальный элемент этого дела — личный кабинет и горячий телефон/емейл. До тошноты уже продемонстрировано опытом и исследованиями, что личный кабинет повышает производительность и качество труда тех же программистов, а после каждого отвлечения на телефон и подобное, требуется порядка 20 минут чтобы вернуться в рабочий режим мышления. Но личный кабинет считается роскошью, даже если это коробка 2х2 с запираемой изнутри дверью, а горячий телефон/емейл — обязательным поводком, потому что иначе начальствующий не может чувствовать что он контролирует и вообще не забыт. В результате обычная практика — фермы из кубиклов (cubicle), где невозможно сосредоточиться, потому что всё слышно со всей фермы, очень легко отвлекать любой фигнёй гораздо чаще, чем раз в 20 минут. А причина всему — дурь и гордость, и плевать как там на результатах отразится.
ферма&nbsp[показать]

Серокой> Это ушло с уходом травленных на кухне плат и 51-х контроллеров... Один человек в разумные сроки не способен охватить всё.

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

ko4evnik>>> 1) алгоритм - есть обобщенный математический метод, программа - его инженерная реализация. это два разных этапа одной работы. вы склонны к тому чтобы видеть их в неразделимом единстве, а я к этому не склонен. просто потому что обычно этими этапами занимаются разные люди и разные подразделения.
Mishka>> Это немного очень упрощённое понимание.
Это немного очень упрощённое описание дихотомии между алгоритмом и программой. которая является ключом к фразе "этими этапами занимаются разные люди и разные подразделения". которая поимела свое развитие в:
Wyvern-2>> Вообшем, конструктор, програмист и боеприпасник должны быть в одной голове, а не в одной комнате
Mishka> Близко к идеалу.
не достаточно точно на мой взгляд. мне видны такие роли:
прикладной математик - описывает модели и обобщенные алгоритмы;
конструктор (инженер-железячник) - предоставляет "железо";
программист - переводит "модели" через "алгоритмы" в "программу" работающую в "железе";
в одном человеке обычно совмещаются только одна-две роли и практически никогда - все три. слишком разные подходы и методы - практически невозможно быть достаточно "глубоким" во всех трех областях.

потому организационно и существуют отделы "математиков", "конструкторов" и "программистов"...

Mishka> Давай начнём с определений тогда.
определение оно как алгебра (не в смыле "наука" а в смысле "совокупность 1)входных элементов, 2)производимых над ними операций, и 3)получаемых с их помощью выходных элементов") - можно на выходе получить чего душе годно путем манипуляций.
т.е. берем "целые положительные числа" и вводим над ними "сумму" и "умножение"- получаем на выходе те же "целые положительные";
вводим дополнительно "разность" - получим на выходе уже просто "целые числа"(не обязательно положительные);
введение "деления" уже порождает веер вариантов - можно получить на выходе "рациональные дроби" а можно оставаться в парадигме "целых" - если наплевать на остаток.
ну и т.д.

Mishka> Вот про то же определения алгоритма — с моим определением согласен?
другими словами - не могу ли я его оспорить? могу, отчего же нет?
было сказано:
Mishka> Алгоритм — набор шагов, завершаемый за конечное, но не ограниченное время.
чего тут введено в качестве "элементов/операций":
1) "дискретность алгоритма" - можно согласиться, а можно и углУбить : чего считать "шагом" например в случае нейронных сетей? или в случае параллельных вычислений? там сложность "единичного шага" может быть настолько высокой, что делает их трудноразличимыми.
2) "конечность" - опять же можно зацепиться. вот к примеру летит ракета к цели - а в гсн у нее крутится программа исполняющая алгоритм минимизации промаха. сам по себе он вполне себе "бесконечен" и ограничен не собственными особанностями, а временем жизни системы.
3) и при этом "не ограниченное время" как бы даже рассматривать грешно, "ибо не бывает"...

"прикопаться можно и к столбу"...

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

Mishka> Второе — говорим про то, что в заголовке (фактически, программно-аппаратные комплексы) или про использование стандартного железа для решения каких-то задач? Это разные вещи.

в заголовке у нас "зур с инфракрасной головкой самонаведения а-ля Питон". можно сказать что там есть "базовая архитектура", но нельзя сказать что есть "стандартное железо".

ko4evnik>> - при разработке военной железки = 1:10 при характерной длительности в единицы лет/десятки месяцев. dixi.
Mishka> Это как? На железке уже есть ОС и компилятор? Откуда? Можно подробней?
примерный "уровень" можно представить по продукции этих вот товарищей: Универсальный программатор. Профессиональные программаторы и средства разработки микроконтроллеров.
микроконтроллер он и в африке микроконтроллер. это как максимум. а то и просто интегральная схема. ПЛИС - как вариант, но он не единственный.

ko4evnik>> получается. пример Союзов и Протонов тоже неплохо что-то показывает.
Mishka> Не, так не работает. Сила системы определяется его слабейшим звеном. Здесь я должен заметить, что на Союзах и Протонах доля софтовых решений была намного меньше, чем на Ариане, ИМХО. И интеграция поменьше.
"софтовые решения" там иногда совершенно не "софтовые". в "Союзе", например, если не ошибаюсь, в системе двигателей коррекции есть аналогово-механические рассчетчики. входное воздействие - давление в трубпроводе(?), а функция управления там осуществляется с помощью фигурно-вырезанной стальной фиговины которая это давление напрямую преобразует в угол ориентации(?). совершенно неубиваемая конструкция с мгновенной реакцией. в отличие от всяко-разной электроники...

Mishka> Кстати, а как на Булаве, которая не особо летает?
это не ко мне

ko4evnik>> так математика как бы и не причем. стрельнуть надо живым изделием - чтобы засечки величин получить - между которыми потом с легкостью неописуемой интерполировать. и стрельнуть не один раз...
Mishka> ИМХО, сильно таки при чём.
Mishka> Ну и кто определял модель, по которой надо считать?
"прикладной математик".

ko4evnik>> это был легкий сарказм. с целью указать на то что материя таки первична... и самый распрекрасный алгоритм не поможет "там, где важна только крепость руки".
Mishka> Не понял совсем. Чтобы пользоваться крепкой рукой — нужен алгоритм.
ну это совершенно непродуктивный спор из серии "что первично - курица или яйцо"...

ko4evnik> Это немного очень упрощённое описание дихотомии между алгоритмом и программой. которая является ключом к фразе "этими этапами занимаются разные люди и разные подразделения". которая поимела свое развитие в:

Не должнжо быть дихотомии. Плохо это. Проходил.

ko4evnik> не достаточно точно на мой взгляд. мне видны такие роли:
ko4evnik> прикладной математик - описывает модели и обобщенные алгоритмы;
ko4evnik> конструктор (инженер-железячник) - предоставляет "железо";
ko4evnik> программист - переводит "модели" через "алгоритмы" в "программу" работающую в "железе";

Поскольку по по образованию я прикладник с выбросом в "программисты", то эти две области мне знакомы. Проработал, как первый 10 лет. Но у меня тесно переплеталось первое и второе.

ko4evnik> в одном человеке обычно совмещаются только одна-две роли и практически никогда - все три. слишком разные подходы и методы - практически невозможно быть достаточно "глубоким" во всех трех областях.

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

ko4evnik> потому организационно и существуют отделы "математиков", "конструкторов" и "программистов"...
Не-а, не поэтому. Это скорее деление, придуманное дятьками с властью. Легче так. Я бы организовывал сквозные бригады. Так удобнее и лучше результаты.


ko4evnik> определение оно как алгебра (не в смыле "наука" а в смысле "совокупность 1)входных элементов, 2)производимых над ними операций, и 3)получаемых с их помощью выходных элементов") - можно на выходе получить чего душе годно путем манипуляций.
ko4evnik> т.е. берем "целые положительные числа" и вводим над ними "сумму" и "умножение"- получаем на выходе те же "целые положительные";

В качестве придиризма — ты не путаешь алгебру (как математическое понятие) с её объектами? То, что называешь следует рассматривать как группы, кольца, поля и т.д. И в последнем случае у тебя поля (или даже кольца) не получиться.

ko4evnik> вводим дополнительно "разность" - получим на выходе уже просто "целые числа"(не обязательно положительные);
Ы? Ты не перепутал натуральные или неотрицательные числа с целыми?

ko4evnik> введение "деления" уже порождает веер вариантов - можно получить на выходе "рациональные дроби" а можно оставаться в парадигме "целых" - если наплевать на остаток.
Смотря что ты хочешь получить. Скажем в рамках поля не удасться остаться.

ko4evnik> другими словами - не могу ли я его оспорить? могу, отчего же нет?
Можно сказать, что и оспорить. Но это классическое математическое определение.

ko4evnik> было сказано:
ko4evnik> чего тут введено в качестве "элементов/операций":

Это не важно. С точки зрения математики. Но, поскольку доказана равномощьность машины Тьринга с Марковскими вещами и т.д., то можно сказать, классическое определение МТ.

ko4evnik> 1) "дискретность алгоритма" - можно согласиться, а можно и углУбить : чего считать "шагом" например в случае нейронных сетей? или в случае параллельных вычислений? там сложность "единичного шага" может быть настолько высокой, что делает их трудноразличимыми.

Дискретность алгоритма его неотделяемый атрибут. И сложность тут не важна. Сложность важна в оценке сложностей. Это вполне нормальная область математики. Но сюда её привлекать не надо. Пока. Это будет позже, когда договоримся про алгоритм.



ko4evnik> 2) "конечность" - опять же можно зацепиться. вот к примеру летит ракета к цели - а в гсн у нее крутится программа исполняющая алгоритм минимизации промаха. сам по себе он вполне себе "бесконечен" и ограничен не собственными особанностями, а временем жизни системы.

Конечность — это по определению. Как предел ряда. Алгоритм минимизации — конечен. Метод — нет. Не надо путать это дело.

ko4evnik> 3) и при этом "не ограниченное время" как бы даже рассматривать грешно, "ибо не бывает"...

Ты, ИМХО, путаешь время жизни системы и определение алгоритма. Это разные вещи.

ko4evnik> "прикопаться можно и к столбу"...
Не выйдет. Потому как надо будет строить свою теорию, а не пользоваться той, которую разработали. Есть много последствий, когда меняешь условия и всё надо передоказывать.

ko4evnik> а суть то дискуссии далеко не так глубока: всего то требуется договорится - чего считать за "этап разработки системы", а чего за "исследования, предшествующие разработки системы"...

Гораздо глубже. Надо просто понять, что надо решить задачу. Поэтому все исследования деляться на всех, а не только на железо. Если ты не считаешь программистов за обезъянок, которые по клаве лупят.

ko4evnik> в заголовке у нас "зур с инфракрасной головкой самонаведения а-ля Питон". можно сказать что там есть "базовая архитектура", но нельзя сказать что есть "стандартное железо".

Дык, архитектура железа определит многое из того, что можно сделать. Если мы берём и говорим, что надо будет поставить туда пень для решения задач, то надо сразу рассмотреть вопросы питания и прочего. Если мы знаем, что рули не развернуть на 180 за секунду, то какой алгоритм не применяй — не получиться.

ko4evnik> примерный "уровень" можно представить по продукции этих вот товарищей: Универсальный программатор. Профессиональные программаторы и средства разработки микроконтроллеров.

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

ko4evnik> микроконтроллер он и в африке микроконтроллер. это как максимум. а то и просто интегральная схема. ПЛИС - как вариант, но он не единственный.

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

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

Дык, именно это я имел в виду. Как только доля софта вырастет — вырастет количество отказов. Печальная такая статистика по другим проектам.

ko4evnik> это не ко мне

Да просто интересно. Чего-то мне кажеться, что это одна из проблем.
ko4evnik> "прикладной математик".

Дык, это и есть начало разработки алгоритма. Но должен был всё-таки не совсем математик, скорее уж аэродинамики с математиками и другими вместе.

ko4evnik> ну это совершенно непродуктивный спор из серии "что первично - курица или яйцо"...

Не, не так. Вот была такая книжечка Громова "Феномен персональных вычислений". Много там говорилось, как эти самые персональные вычисления ускорили прогресс, т.к. каждый смог писать программки. Пару лет назад на Базе был уже спор на эту тему. ИМХО, которое я сказал тогда и повторюсь — этот феномен отбросил программирование, как науку, лет на 20-25 назад. Та самая знаменитая присказка про физиков, которые раньше обменивались идеями, а теперь программами с ошибками — растёт отсюда.

Надо Тико звать.

Тико, вылезай!

Mishka> За стандарты разговора не было — а вот железяку он делает свою.

Так вот и зря не было. Бо стандарты изменяют процесс радикально.

Mishka> Просто на сегодняшний день тот же Javelin покрывается существующими FPGA.

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

Mishka> Но, скажем, та же задача взлома некоторых криптоалгоритмов, как показали работы в том же MIT, при затратах около $100,000 решаются этой аппаратурой намного лучше, чем софтом на универсальных CPU.

Ха! Так криптофичи специально делают как можно более несовместимыми с массовым вычислительным железом, чтобы нельзя было эффективно ломать на стадах копеешных девайсов. Отсюда все эти 6-битные форматы, странная арифметика и т.д. и т.п.

Но ГСН-то с распознаванием изображений тут причём ???

Mishka> Не, на софт сокращают в первую очередь. И именно из-за того самого восприятия, что софт менять легко.

Неправда. Софт сокращают в первую очередь, бо он нынче почти везде самая дорогая часть. И сокращают вполне грамотно. Отпиливая цельные фичи прежде всего.

Nikita> Так вот и зря не было. Бо стандарты изменяют процесс радикально.
Стандарты — это хорошо. Но это запланированное отставание. Немного участвую в разработке стандартов. Так вот компании, которые их делают (в том числе и в таких общественных конторах, как IETF) всегда изначально получают преимущество. И пользуются этим вовсю.

Поэтому на стандарты надо смотреть двояко:
1. Сокращение затрат и ускорение процесса разработки. Но только в том случае, если эти стандарты дают всё, что нужно.
2. Создание своих стандартов в других случаях. Затраты тут могут быть очень большими.

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

Это тоже не совсем правда. Скажем, на многих раутерах (та же MPLS поддержка) стали применять ПЛИСы. Но на самых самых у многих всё ещё не они, бо не успевают они часто.

Nikita> Ха! Так криптофичи специально делают как можно более несовместимыми с массовым вычислительным железом, чтобы нельзя было эффективно ломать на стадах копеешных девайсов. Отсюда все эти 6-битные форматы, странная арифметика и т.д. и т.п.

Не, тут вся математика направлена на то, чтобы трудно было считать. А вот получилось, что не всё предусмотришь.

Nikita> Но ГСН-то с распознаванием изображений тут причём ???

Это пример задачи, где существующие ПЛИСы не особо рулят. И таких задач много.

Nikita> Неправда. Софт сокращают в первую очередь, бо он нынче почти везде самая дорогая часть. И сокращают вполне грамотно. Отпиливая цельные фичи прежде всего.

Не, не особо. Тот Ratheon, westinhouse, Boeing, LM наши клиенты. Так что знаю немного изнутри. Но отпиливать надо. Иначе получается как в письме в Communications of the ACM — смотри картинку.

Mishka> Стандарты — это хорошо. Но это запланированное отставание.

Хорошо быть здоровым и богатым. Отрастим местные Intel/IBM/Microsoft - будут и наши стандарты. А пока актуально реальное каждодневное отставание, а не потенциальное стандартное.

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

Это очевидно, но в области железячных архитектур к ВПК имеет отношение достаточно отдалённое.

Mishka> Это тоже не совсем правда.

Правда-правда.

Mishka> Скажем, на многих раутерах (та же MPLS поддержка) стали применять ПЛИСы.

Отличный пример!!! Даже в такой массовой продукции как роутеры (сравните с жалкой ~1000 годового производства ГСН для Javelin'ов) как ни откроешь cisco - так ALTERA сплошником.

Mishka> Не, тут вся математика направлена на то, чтобы трудно было считать.

Математика направлена на то, чтобы было трудно считать на массовых дешёвых системах.

Mishka> А вот получилось, что не всё предусмотришь.

Вы это о чём От специализированной кастомной железки никто и не собирался защищаться.

Mishka> Это пример задачи, где существующие ПЛИСы не особо рулят. И таких задач много.

Формулировка неправильная. Задач требующих воплощения кастомных архитектур в кастомных же микрухах - раз-два и обчёлся. Всё остальное успешно решается комбинированием стандартных массовых девайсов/архитектур.

Mishka> Не, не особо.

Особо. На тестировании Flight Control System никто не экономит. Экономят на тестировании некритических компонент. От того что у рисовалки картографического модуля снесёт крышу при пересечении линии дат самолёт не упадёт.

Mishka> Иначе получается как в письме в Communications of the ACM — смотри картинку.

Стенания "раньше трава была зеленее".

Mishka> Это пример задачи, где существующие ПЛИСы не особо рулят. И таких задач много.

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

ko4evnik>> Это немного очень упрощённое описание дихотомии между алгоритмом и программой. которая является ключом к фразе "этими этапами занимаются разные люди и разные подразделения". которая поимела свое развитие в:
Mishka> Не должнжо быть дихотомии. Плохо это. Проходил.
не должно быть. а она есть. плохо это. да.

ko4evnik>> не достаточно точно на мой взгляд. мне видны такие роли:
ko4evnik>>1) прикладной математик - описывает модели и обобщенные алгоритмы;
ko4evnik>>2) конструктор (инженер-железячник) - предоставляет "железо";
ko4evnik>>3) программист - переводит "модели" через "алгоритмы" в "программу" работающую в "железе";
Mishka> Поскольку по по образованию я прикладник с выбросом в "программисты", то эти две области мне знакомы. Проработал, как первый 10 лет. Но у меня тесно переплеталось первое и второе.

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

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

ага. только сильно желательно чтобы была взаимность.
чтобы не испытывать когнитивный диссонанс, объясняя "нумеру первому", что в условиях микроконтроллера - флоат может быть и двухбайтным - что дает 4-5 надежных знаков после запятой, и потому в модели не имеет смысла задавать коэффициенты с точностью в 7-8 знаков.
или что рассчитывать синус можно и целочисленно...

ko4evnik>> потому организационно и существуют отделы "математиков", "конструкторов" и "программистов"...
Mishka> Не-а, не поэтому. Это скорее деление, придуманное дятьками с властью. Легче так. Я бы организовывал сквозные бригады. Так удобнее и лучше результаты.

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

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

ko4evnik>> определение оно как алгебра (не в смыле "наука" а в смысле "совокупность 1)входных элементов, 2)производимых над ними операций, и 3)получаемых с их помощью выходных элементов") - можно на выходе получить чего душе годно путем манипуляций.
ko4evnik>> т.е. берем "целые положительные числа" и вводим над ними "сумму" и "умножение"- получаем на выходе те же "целые положительные";
Mishka> В качестве придиризма — ты не путаешь алгебру (как математическое понятие) с её объектами? То, что называешь следует рассматривать как группы, кольца, поля и т.д. И в последнем случае у тебя поля (или даже кольца) не получиться.

нет. по крайней мере то чему меня учили вполне соответсвует Википедийному (http://ru.wikipedia.org/wiki/Алгебра): "Алгебра — упорядоченная пара множеств A(R,E). Первое множество (R) — элементы какой либо природы (числа, понятия, буквы). Второе множество (E) — операции над первым множеством (сложение, умножение, возведение в степень)."

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

и больше используется более сильный вариант (где Rвх==Rвых), не потому что другой "не верен", а потому что "для математика удобней".

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

ko4evnik>> вводим дополнительно "разность" - получим на выходе уже просто "целые числа"(не обязательно положительные);
Mishka> Ы? Ты не перепутал натуральные или неотрицательные числа с целыми?
я их не путал просто потому что строго не вводил
"иногда два брата-помидора, которые тащат пьяного друга-огурца, это всего лишь два брата-помидора, которые тащат пьяного друга-огурца..."

ko4evnik>> введение "деления" уже порождает веер вариантов - можно получить на выходе "рациональные дроби" а можно оставаться в парадигме "целых" - если наплевать на остаток.
Mishka> Смотря что ты хочешь получить. Скажем в рамках поля не удасться остаться.

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

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

ko4evnik>> было сказано:
ko4evnik>> чего тут введено в качестве "элементов/операций":
Mishka> Это не важно. С точки зрения математики. Но, поскольку доказана равномощьность машины Тьринга с Марковскими вещами и т.д., то можно сказать, классическое определение МТ.
можно сказать, а можно и не.
потому что таких "классических определений" полна Википедия (http://ru.wikipedia.org/wiki/Алгоритм) - и все в деталях чуток отличаются. т.е. граничные условия каждого из очерчивают чуть-чуть отличающиеся области.
так что как минимум следует доопределять "классическое определение МТ по учебнику такому-то"...

ko4evnik>> 1) "дискретность алгоритма" - можно согласиться, а можно и углУбить : чего считать "шагом" например в случае нейронных сетей? или в случае параллельных вычислений? там сложность "единичного шага" может быть настолько высокой, что делает их трудноразличимыми.
Mishka> Дискретность алгоритма его неотделяемый атрибут. И сложность тут не важна. Сложность важна в оценке сложностей. Это вполне нормальная область математики. Но сюда её привлекать не надо. Пока. Это будет позже, когда договоримся про алгоритм.
я сделал акцент не на "сложность", а на "трудноразличимость". т.е. трудность не во внутренней сложности шага, а в способе исчисления шагов. саму "дискретность" можно мыслить очень по разному.

возвращаясь к примеру с движками Союза: там имеются все признаки исполнения алгоритма, если принять что количество шагов ==1.

ko4evnik>> 2) "конечность" - опять же можно зацепиться. вот к примеру летит ракета к цели - а в гсн у нее крутится программа исполняющая алгоритм минимизации промаха. сам по себе он вполне себе "бесконечен" и ограничен не собственными особанностями, а временем жизни системы.
Mishka> Конечность — это по определению. Как предел ряда. Алгоритм минимизации — конечен. Метод — нет. Не надо путать это дело.
опять же "по определению". то что это чистая математическая абстракция и на реальный мир она натягивается как сова на глобус - это как бы остается за кадром...

ko4evnik>> 3) и при этом "не ограниченное время" как бы даже рассматривать грешно, "ибо не бывает"...
Mishka> Ты, ИМХО, путаешь время жизни системы и определение алгоритма. Это разные вещи.
опять же "определение"...

ko4evnik>> "прикопаться можно и к столбу"...
Mishka> Не выйдет. Потому как надо будет строить свою теорию, а не пользоваться той, которую разработали. Есть много последствий, когда меняешь условия и всё надо передоказывать.
ага. слова не мальчика, но мужа.
когда меняешь условия с "разработки компиляторов" на "разработку военной железки" таки "всё надо передоказывать"

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

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

ko4evnik>> ну это совершенно непродуктивный спор из серии "что первично - курица или яйцо"...
Mishka> Не, не так. Вот была такая книжечка Громова "Феномен персональных вычислений". Много там говорилось, как эти самые персональные вычисления ускорили прогресс, т.к. каждый смог писать программки. Пару лет назад на Базе был уже спор на эту тему. ИМХО, которое я сказал тогда и повторюсь — этот феномен отбросил программирование, как науку, лет на 20-25 назад. Та самая знаменитая присказка про физиков, которые раньше обменивались идеями, а теперь программами с ошибками — растёт отсюда.

чего в этом удивительного? читая классиков:
" ...переход от чистой магии через алхимию к технологии...
маг - каждый! - был уникальным и избранным;
алхимик - нечеловечески упорным;
технологов можно было печь как блины, не слишком заботясь о качестве каждого..."

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

Mishka> Дык, именно это я имел в виду. Как только доля софта вырастет — вырастет количество отказов. Печальная такая статистика по другим проектам.
ну так и урок - следует препятствовать неконтролируемому росту доли софтовых решений и не допускать деградации руководства процессом.

Mishka> Надо Тико звать.
Mishka> Тико, вылезай!
да, Тико, вылезай

ko4evnik> следует препятствовать неконтролируемому росту доли софтовых решений и не допускать деградации руководства процессом.

Но как, Холмс?!
Это же строго против шерсти "прогресса". Рост доли софта растёт ещё и потому что кодеров просто больше количественно и они дешевле. Любой студент может что-то как-то программировать, быстро учит языки и при желании без труда становится http://en.wikipedia.org/wiki/Code_monkey Электроника же учить надо по полной программе, и качество его работы проверяется законами физики, в том числе искрами и дымом. А если нужно что-то нелёгкое, вроде синтеза VHDL в правильные схемы фпга, то быстро такие не учатся, так что их просто мало. Не знаю как сейчас из-за GFC, но не так давно спецы по фпга были в остром дефиците, так что это влияло на принятие решений в сторону софта.
А насчёт руководства, то беда в том откуда оно берётся. Два источника: из бизнес-школ и из ушедших на повышение. Но первые ни ухом ни рылом в технике, вторые точно так же в руководстве, но все жаждут повелевать декретами. Впрочем, первые и в руководстве так же обычно. Так что о деградации можно не беспокоиться — она достигнута. Читаю о великих проектах, и понимаю что это уже рассказы с другой планеты, и всегда там руководили исключения, исключительными же методами.

ko4evnik>> следует препятствовать неконтролируемому росту доли софтовых решений и не допускать деградации руководства процессом.
au> Но как, Холмс?!
au> Это же строго против шерсти "прогресса".
а что "шерсть прогресса" в том чтобы отказаться от контроля и почковать "броуновских кодеров-дрозофил"?

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

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

au> А насчёт руководства, то беда в том откуда оно берётся. Два источника: из бизнес-школ и из ушедших на повышение. Но первые ни ухом ни рылом в технике, вторые точно так же в руководстве, но все жаждут повелевать декретами. Впрочем, первые и в руководстве так же обычно.

первое чего следует осознать вылупившемуся специалисту - "руководства не существует. существуют контрагенты." и мир становаится простым и понятным.

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

Mishka> А чего ты сам не сел и не написал? Писание драйверов очень техническая работа.
Ну да, встречный вопрос - почему программисты не сели и не написали совй контроллер USB? Потому что каждый должен заниматься своим делом.

Mishka> Не в этой. Спроси, у кого из программистов есть те же верификаторы.
Хм, это специфика нашей работы. И наши верификаторы "выпестованы" также нами, из нашей среды, а не взятые на стороне. Кроме того, ммм, у вас есть бета-тестеры. А это конечно не верификаторы, но у нас такого набора эникейщиков в смысле нажимателей на всё подряд нет и набор этот в общем-то не нужен. Специфика отладки, как и говорил...
У вас же есть люди, которые как-то заточены на тестирование вашего программного продукта, нет разве?

Mishka> Должны работать вместе.
Так и стараемся. Я и показываю, что это должна быть совместная работа, и она у нас вовсе не проще вашей.

Mishka> Не, про это я не говорю. У нас есть несколько человек, которые этим занимаются. Называется процесс triage.
Ну вот, есть же. У нас верификаторов тоже 4 человека... разве много?

Mishka> код, который помогает отлаживать и/или диагностировать есть у всех.
Эмм... Тут мораль была в другом - мы искали их ошибку, создавая отладочный код. Их, не свою. )

ko4evnik>>> следует препятствовать неконтролируемому росту доли софтовых решений и не допускать деградации руководства процессом.
au>> Но как, Холмс?!
au>> Это же строго против шерсти "прогресса".
ko4evnik> а что "шерсть прогресса" в том чтобы отказаться от контроля и почковать "броуновских кодеров-дрозофил"?

Шерсть "прогресса", а точнее тренд/тенденция, в том что способность создавать деградирует последние лет 20. Это легко видно в софте, в управлении, и в электронике тоже, хотя там законы физики гораздо более дисциплинируют. Тут надо уточнить: раньше были программисты в смысле software engineer (в контексте темы — embedded), именно такие и для таких придумали Аду, они же не имели проблем с ассемблером, а потом итеративное абстрагирование от реальности открыло путь кодерам-дрозофилам, кодемакакам, аутсорсингу в джунгли и соответствующему падению качества в унитаз и далее по трубе. Кто-то до сих пор создаёт программы для промышленных контуперов, которым не позволено быть дефектными — наверно это те же люди, что занимались этим и раньше. А может это просто бастион PLC держится, потому что там программирование специфическое.

ko4evnik> вобщем то я считаю что и нормального кодера надо учить примерно так же...

Тут терминология важна. Это software engineer-а надо учить так же. А кодер — это вроде электрика на уровне ПТУ. Беда в том, что с терминологией проблема в том числе и в образовании, и по-моему оно уже зациклилось: выросло поколение кодеров, которые думают что они инженеры, и которые уже учат следующее поколение кодеров. Это люди которые не только совсем не знают что они программируют, но и знать этого не хотят. Они кодят, потому и кодеры, или кодомакаки (code monkeys).

ko4evnik> первое чего следует осознать вылупившемуся специалисту - "руководства не существует. существуют контрагенты." и мир становаится простым и понятным.

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

з.ы. Вот достижения. Внимание следует обратить на то в чём соревнуются, ну и просто визуально на результаты: http://74.125.153.132/.../tpj/issues/vol2_3/tpj0203-0012.html
Соревнований молодёжи на надёжность и бездефектность их творений как-то не припомню.

au> Соревнований молодёжи на надёжность и бездефектность их творений как-то не припомню.

Наверное, потому что для этого нужен опыт. Который у большинства представителей молодёжи отсутствует

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

Нет, но потому что молодёжь просто не учат этому. Тот кто учит, тот должен учить делать правильно, основываясь на своём опыте, а не бросать молодых на грабли. Нас учили, именно своему опыту, поэтому не имея своего, мы уже были опытны опытом наших учителей. Таких мало было, но и то хорошо. В частности, нас учили "делать хорошо, а плохо получится само". Сейчас молодёжь учат делать как-нибудь, а как получится — неважно, ведь всегда можно выпустить новую версию и пожаловаться на сложность, хотя сложность самодельная — никто их не учил делать просто. Кстати, вот пример результатов — страниц много, но очень занимательное чтиво. Пишет наш выходец, ныне преподающий самым лучшим студентам во Франции. http://ufn.ru/tribune/trib110604.pdf

au> Нет, но потому что молодёжь просто не учат этому. Тот кто учит, тот должен учить делать правильно, основываясь на своём опыте, а не бросать молодых на грабли.
Дизайну программ, системной архитектуре в хороших местах таки ещё учат.
В совсем хороших - молодым ещё и скармливают кучу полезных вещей - от "правил дебаггинга" до design patterns.

Проблема не в этом. А в том, что нельзя поставить план "выпустить 10000 докторов наук" или "выпустить 100000 классных программистов". Потому что знаниями-то напичкать можно, но любая интеллектуальная деятельность требует интеллекта, а он получается как-то иначе... ВУЗ его не генерит никак.

С другой стороны, сейчас вопрос часто ставится так, что "пусть мы будем есть говно, но говна у нас должно быть МНОГО". ПартияРынок сказал "надо!"?. КомсомолВсеобуч ответил - "есть!". Нужны говнокодеры, но МНОГО? Будут. Никто ж не платит за качество. Нужно кучу фич за три дня (и 2.5 уже прошли), и чтоб свистело и моргало, и чтоб шибко много работнику не платить... а что там внутри кода, который свистит и моргает - какая разница? Как Вы сказали, Бангалор? Какая средняя зарплата? О! По рукам!
Качество сейчас мало ценится. А там, где оно ценится, и за него платят... вот та-ам - вполне может сидеть грамотный чел, который способен качественно писать на яве, отдебажить ассемблерный код и написать ПЛИС для аппаратной оптимизации.

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

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

au> Соревнований молодёжи на надёжность и бездефектность их творений как-то не припомню.
Олимпиада по информатике.

Татарин> Качество сейчас мало ценится. А там, где оно ценится, и за него платят... вот та-ам - вполне может сидеть грамотный чел, который способен качественно писать на яве, отдебажить ассемблерный код и написать ПЛИС для аппаратной оптимизации.

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

Татарин> И не надо этих страданий про "нас и молодёжь" , просто раньше люди после техникума становились электриками, а сейчас - программистами.

Страдания у тех, кому приходится выбирать говно из говна. Причём страдания эти я предпочитаю в исполнении ветеранов, которые сравнивают свою работу и достижения, и работу пионеров и их достижения. Культура качества и просто стремление к совершенству дали результаты, о которых сейчас молодёжь не заикнётся даже. Та культура сохранилась в нишах, вроде http://en.wikipedia.org/wiki/DO-178B и http://en.wikipedia.org/wiki/Ravenscar_profile — много ли молодёжи в этих нишах? Насчёт электриков — электрик ошибается по-крупному лишь один раз, а программист-кодомакак так живёт. Электрическая схема без крупных ошибок удивления не вызовает? Про сложность сразу скажу: она создаётся руками авторов, а не навязывается природой, в отличии от электричества.

au>> Соревнований молодёжи на надёжность и бездефектность их творений как-то не припомню.
Татарин> Олимпиада по информатике.

А там анализировали код на бездефектность всякими методами? Или на глаз? Вот Ganssle пишет:

Several studies have shown that the use of SPARK and the methods Praxis advocates accelerate delivery and reduces (dramatically) bug rates. For instance, a joint NSA/Praxis/ SPRE project named Tokeneer resulted in about 10K lines of code and consumed 260 person-days, a productivity rate far higher than most commercial projects. That includes the time to generate hundreds of pages of documents. A total of 54 defects were found during development (including specification errors and coding mistakes); of those, 36 were "minor," meaning spelling errors and the like. Eighteen important bugs in 10KLOC. Software for dependable systems

 

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