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

au> з.ы. Возвращаясь к фигне. Если целью работ является изделие объёмом 3 литра, это значит что на всех этапах разработки действует такое ограничение.
нет не всегда. есть такая штука как имитаторы / эмуляторы.
т.е. вместо какого-то аппаратного/программного элемента впендюривают его функциональный эквивалент. и отлаживают.

au> И если разработчик алгоритма предлагает решение, которое за глаза трудно впихнуть в 3 литра (например, алгоритму требуется вычислительная мощь, соответствущая контуперу объёмом 5 литров, не считая всего прилагающегося) , то в консерватории что-то совсем не так, и тем более неуместно говорить что разработка алгоритма — фигня.
это как раз "рабочий процесс".
как то я убил 4 месяца на то, чтобы в ПЗУшку фиксированного размера впихнуть то, что в нормальном состоянии влазило только во вдвое большую. более извращенно-изощренной программы я в жизни не писал и, надеюсь, не буду. хотя сейчас вспомнить приятно...

Mishka> Только самое большое простое число у всех стран относиться к государственной тайне. Не всё так просто.

А можно ликбез?
Как это понимать вообще? Что значит "самое большое простое число"? Самое большое используемое? Самое большое известное? Но кому??? И т.п.
То есть понятно, что шифрование на это завязано, но вот насчёт именно "самого большого"...

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

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

Серокой> Да ну вас, программистов, со своим программоцентризмом! Программная ошибка меняется банальной перепрошивкой ПЗУ. А аппаратная?
Ага. Только тестирования и валидации, чтобы найти не в бою, надо выполнить намного больше работы.

Что интересно, что на разработку железа дают годы, ближе к десяткам. А на программы — пару лет от силы.

А на исправление ошибок в том же VHDL уходит столько же времени, сколько и в любом другом языке программирования.

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

ko4evnik> это как раз "рабочий процесс".

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

з.ы. Однажды довелось программировать один чип, на который не было документации. Стек не работал — никаких циклов, прерываний, и отладка по осциллографу. Так жить нельзя, только "наёмником"

Mishka> Ага. Только тестирования и валидации, чтобы найти не в бою, надо выполнить намного больше работы.
И что, кто её делает? Программисты? Да если бы! Железячник пишет на бумажке, что он бы хотел протестировать и идёт с ней к программисту-верификатору! Это в лучшем случае. В худшем - пишет сам.
Есть верификаторы, которые работают в тесном сотрудничестве с железяниками, а есть программисты, которые приходят на готовое и почти совсем не замечают проблем, поскольку основные проблемы уже решены. )

Mishka> Что интересно, что на разработку железа дают годы, ближе к десяткам. А на программы — пару лет от силы.
Хм, это где ж такое? Гды на микросхему? В Интеле? А как ж закон Мура?

Mishka> А на исправление ошибок в том же VHDL уходит столько же времени, сколько и в любом другом языке программирования.
Хмм... И что? У тебе есть VHDL, максимум, что ты можешь с ним сделать - меееедленно промоделировать. А микросхема уже готова.
Те проблемы, которые можно решить поправкой HDL и быстрой верификацией на ПЛИС, решаются с помощью верификаторов.

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

ko4evnik> весьма серьезное заявление. а обосновать?

22 года опыта в программировании, разработка компиляторов, ОС, СУБД, работа в команде с инжерами по созданию своей машины. Хватит? Если охота подробнее, то надо указать уровень.

ko4evnik> цыферка из личного опыта. желаете предьявить другую?

Да. Один к одному, как минимум. Разработка компилятора до приличного, как говорил мой научный руководитель, с любого приличного языка (уровня Ады, Алгола 68, С++) — 10 лет. Что и подтверждается всеми компиляторами. Добавить приличный оптимизатор — ещё несколько лет. За это время железо успевает устарёть. Сколько лет надо для доведения ОСи до приличного состояния, указывать надо? Тот же линь на 64 битах глючит, хотя доступны архитектуры уже много лет.

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

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

Не получается. И пример той же Ариан очень хорошо показывает. А вообще надо читать Роберта Гласса.

ko4evnik> ага. ну вот есть у вас к примеру Изделие с двигателем, который может использвать топлива типа А, Б или В. и требуется написать простенькую программку, чтобы узнать - на какую дальность это изделие улетит при температуре скажем -10С или скажем при +35С. а для простенькой программки требуется простенькие коэффициентики к примеру для функции Лагранжа, чтоб проинтерполировать поточнее...

И какие проблемы? Математика вся известна более 100 лет. Или чего-то не устраивает? Или всё не так просто?

ko4evnik> чего то я думаю, что голое решето Эратосфена не справится...
Ну, это, конечно, круто алгоритм для вычисления простых чисел использовать для вычисления коэффициентов ф-ции Ла-Гранжа. У нас за такое выгоняли.

Fakir> А можно ликбез?
На том уровне, на котором я знаю — можно.

Fakir> Как это понимать вообще? Что значит "самое большое простое число"? Самое большое используемое? Самое большое известное? Но кому??? И т.п.
Известное. В СССР — КГБ, в США АНБ.

Fakir> То есть понятно, что шифрование на это завязано, но вот насчёт именно "самого большого"...

Дык, всякие алгоритмы с шифрования с открытым ключами типа RSA. Там используются пары простых чисел (иначе возникают проблемы — арифметика остатков очень быстро сводит всё к НОДам и меньшим простым числам), поэтому, если КГБ знает, что АНБ имеет простое число не более N, то количество работы резко уменьшается при криптоанализе.

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

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

Прогамма же есть имплементация алгоритма на конкретном железе, в конкретной среде. Поэтому, тут ещё дополнительные сложности.

ИМХО, это наивно верить, что для всех задач уже есть алгоритмы.

PS Хотя вычисления тех же коэффициентов Ла-Гранжа уже часть алгоритма. Просто выполнили его не программисты, но цена туда тоже идёт.

Серокой> И что, кто её делает? Программисты? Да если бы! Железячник пишет на бумажке, что он бы хотел протестировать и идёт с ней к программисту-верификатору! Это в лучшем случае. В худшем - пишет сам.

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

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

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

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

Серокой> Хм, это где ж такое? Гды на микросхему? В Интеле? А как ж закон Мура?
НУ, скажем, твои любимые видеокарты — сколько дают программистов с момента фиксации железа? Столько же, сколько и железячникам до этого момента? Ни фига, говорят, работайте в параллель. А теперь представь, что тебе дали задание на разработку видеокарты, а под конец сменили шину. А потом тип памяти. Сможешь уложиться в те же сроки?

Серокой> Хмм... И что? У тебе есть VHDL, максимум, что ты можешь с ним сделать - меееедленно промоделировать. А микросхема уже готова.

И чего? А программу тестировать по полной не надо?

Серокой> Те проблемы, которые можно решить поправкой HDL и быстрой верификацией на ПЛИС, решаются с помощью верификаторов.


Если бы. У тебя какой-то очень упрощённый подход.

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

Да ну? Какому конечному программисту? Ему столько же времени и рессурсов дадут? Я выше описал, что надо.

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

Mishka> А программистам приходится жить в мире изменяемого железа.
А ничего, что железо чаще меняется не из-за глюков, а из-за требований самих программистов? То есть когда найдена ошибка - программист ничего не делает. Он тыкает пальцем и ждёт, пока её исправят. Его программа при этом никак не меняется. Это потом начинается: хочу аппаратное копирование кусков! Хочу сопроцессор для быстрого фурье! А здесь у вас не правильные регистры, потому как скачанный мной из Интернета драйвер на вашей железке не работает!

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

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

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

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

Mishka> Да ну? Какому конечному программисту? Ему столько же времени и рессурсов дадут?
Ему дадут больше! Ему, мало того, дано по статусу. У него есть железка, он под неё пишет, а если ошибку нашёл, то пропатчил - и всё. Я выше тоже описал. )

Fakir>> Как это понимать вообще? Что значит "самое большое простое число"? Самое большое используемое? Самое большое известное? Но кому??? И т.п.
Mishka> Известное. В СССР — КГБ, в США АНБ.
> поэтому, если КГБ знает, что АНБ имеет простое число не более N, то количество работы резко уменьшается при криптоанализе.

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

И поиск ведь, надо полагать, постоянно ведётся "вверх"? Или тоже нет смысла?

Mishka> Дык, всякие алгоритмы с шифрования с открытым ключами типа RSA. Там используются пары простых чисел

Это я в курсе про общий принцип, слыхал чуток про NP-полные задачи и проч.

ko4evnik>> это как раз "рабочий процесс".
au> Это неправильный процесс, но широко распространённый.
да, он таки широко распространенный...

au> В правильном процессе вас должны были спросить сколько вам нужно памяти (и не только памяти) для реализации алгоритма, причём это подразумевает демонстрацию работающего прототипа, а потом умножить на два, округлить до верхнего номинала в ряду, и записать полученное значение в ТЗ на железо.
Диавол! а меня не должны ли были спросить, сколько раз на дню ко мне должна приходить массажистка, какого сорта я люблю чай и до какой температуры его потребно кипятить - чтоб алгортим реализовался быстрее, красивше и успешней?? а то может я чего упустил в трудовом договоре....

Серокой> Да ну вас, программистов, со своим программоцентризмом! Программная ошибка меняется банальной перепрошивкой ПЗУ. А аппаратная?

Очень часто программой.

ko4evnik>> весьма серьезное заявление. а обосновать?
Mishka> 22 года опыта в программировании, разработка компиляторов, ОС, СУБД, работа в команде с инжерами по созданию своей машины. Хватит? Если охота подробнее, то надо указать уровень.
это не обоснование, а призыв к пенисометрии
но извольте: 15 лет. там системка, тут вторая, там приборчик, тут программка...

ko4evnik>> цыферка из личного опыта. желаете предьявить другую?
Mishka> Да. Один к одному, как минимум. Разработка компилятора до приличного, как говорил мой научный руководитель, с любого приличного языка (уровня Ады, Алгола 68, С++) — 10 лет.
окей, так и запишем:
соотношение между алгоритмической и железячной частями:
- при разработке компилятора = 1:1 при при характерной длительности разработки в десятки лет;
- при разработке военной железки = 1:10 при характерной длительности в единицы лет/десятки месяцев. dixi.

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

Mishka> А вообще надо читать Роберта Гласса.
читать вообще полезно
"Монтаж" Эйзенштейна тоже неплох, если его правильно понимать.

ko4evnik>> ага. ну вот есть у вас к примеру Изделие с двигателем, который может использвать топлива типа А, Б или В. и требуется написать простенькую программку, чтобы узнать - на какую дальность это изделие улетит при температуре скажем -10С или скажем при +35С. а для простенькой программки требуется простенькие коэффициентики к примеру для функции Лагранжа, чтоб проинтерполировать поточнее...
Mishka> И какие проблемы? Математика вся известна более 100 лет. Или чего-то не устраивает? Или всё не так просто?
так математика как бы и не причем. стрельнуть надо живым изделием - чтобы засечки величин получить - между которыми потом с легкостью неописуемой интерполировать. и стрельнуть не один раз...

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

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

Наверно какие-то такие мысли и посещают руководящие тела, дескать это дело их привилегии назначать объём ПЗУ и сроки разработки, не понимая чем это всё определяется в реальном физическом мире, а не в структуре их огранизационных отношений. Объём ПЗУ лучше сразу в трудовой договор записывать тогда, чтобы не возвращаться к этому вопросу: "Объём ПЗУ и объём кода для реализации любого алгоритма назначается руководством согласно утверждённой сетке объёмов ПЗУ, плюс премиальный объём по выслуге лет, положению в иерархии и личным симпатиям руководства." Кстати, насчёт чая — раз уж тут Мишка пишет, спросите у него как в их организации с этим делом. И для разнообразия погуглите насчёт условий труда в Google Inc.

Серокой>> А аппаратная?
ZaKos> Очень часто программой.
О! Что лишний раз показывает, какая цена программной ошибке, и какая - аппаратной...

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

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

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

Серокой> Но я не понял фразы - "кто программистам даст столько рессурсов и времени?" Почему именно программистам? Прости, но с равной долей тут должны стоять (и стоят!) железячники! Ответственность за баг подёт на них, а вовсе не на программистов-верификаторов.

Потому программистам, что я описал нормальный процесс разработки софта. Embedded софт должен проходить дополнительные проверки. Ну и QA (не весь, а специальные люди) должны быть частью процесса проектирования софта. Понимаешь, не разработки, а проектирования. Ну, и как говорит довольно новые методологии (все ветки extremeprogramming) — тесты должны быть разработаны даже до разработки софта. Я с этим согласен (хотя не везде согласен с XP методологией и её отпрысков). Но эта тема, на которую можно говорить очень много — диссер у моего научного руководителя был посвящён верификации программ, а позже куча работ — созданию методологий по производсту надёжных программ.

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

Не, ничего. Это часто происходит по той причине, что товарищи железячники берут short cuts. Проще в железе воплотить. Ну, и не производят часто совместного анализа требований и спецификаций на решение задачи. Поэтому и происходят такие возвраты. Пример au, как он решал задачу путём применения ПЛИС — классический пример.

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

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

Серокой> Дело в том, что железо редко меняется по прихоти. В ТЗ означен типа памяти, ну и так далее. Я ж выше писал, что изменения - чаще всего просто правка багов. Или внесение фич по требованию программистов.

О, если бы так же было для программеров, то и вопросов бы не было. Только очень мало людей могут это сделать. Т.е. сделать, как в ТЗ (приличном ТЗ, а не "сделайте так, чтобы работало и решало") — проблем не возникает. Проблема в том, что тут пытаются решить задачи, которые сами постановщики ТЗ не понимают, не знают, как решить. Уровень абстракции намного выше, оперируют блоками, которые, по сути, сами офигенные задачи. А потом проблемы — прямо на фейсе.

Серокой> Параллельно конечно же ведётся. Но грубо говоря, 5% последних багов занимают 95% времени. То есть когда железка дышит,то начинается кое-какая жизнь. Например, загрузка ОС на ней. Но в общем-то ОС, несмотря на свою сложность - это конечный набор ситуаций, и ошибки есть, которые будут выловлены потом, на каких-то прикладных задачах, когда железо уже будет не на стадии ПЛиС.

Не, ОС — это только кажеться, что это набор конечных ситуаций. Т.е. математически это корректно. Но вот скажи ты мне — у вас временные диаграммы в ОСи построены? Кто-то проверял на непротиворечивость? Невозможность появления dead lock-ов, плохой конкуренции за рессурсами? А веть это составные части обязательных проверок параллельных систем.

Серокой> Надо. Но у него это получается быстрее. И проще исправить ошибку.

Оно получиться быстрее, если выделить ему столько рессурсов, сколько я упомянул ранее. У вас такое делается?

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

Почему же не понял? Понял. Подгоняют всех.

Серокой> ТИ когда на макете с ПЛИС более-менее задышало, тут всё, сроки поджали (а срок обычно около года, не больше), всё, надо отправлять на изготовление, изготовили, спаяли, а тут программистам наконец-то захотелось проверить, скажем, запуск "исков" в нестандартном режиме, и всё полетело. А поздно, железо готово и его фиг исправишь.

Ы? А почему это проблема программистов? Налицо, ИМХО, не понимание. Это проблема тестировщиков железа. Я понимаю, что есть дорогие ошибки. Но тут и кроется главное наше несогласие — в этот момент почти все считают, что программы легче исправить. Не понимая, что надо прогнать с самого начала — начиная с архитектуры (и дизайна). Кто даст столько времени и рессурсов, чтобы это сделать? Вот и лепят заплату, которая позже вылезет боков с вероятностью 90%.

Серокой> Ему дадут больше! Ему, мало того, дано по статусу. У него есть железка, он под неё пишет, а если ошибку нашёл, то пропатчил - и всё. Я выше тоже описал. )
Да не работает так. Вот как создал исправление, то, по хорошему, надо посмотреть — а как влияет на архитектуру, нарушение взаимотношения блоков, временные диаграмы, статус конечных автоматов (я тебе могу рассказать, как мы полтора месяца недавно елозили из-за такой ошибки, пока я не проанализировал конечный автомат состояний реализации сетевого протокола (нашего) и просто не запретил другой стороне, пользуясь статусом principal software engineer, делать то, что они делали).

ko4evnik> это не обоснование, а призыв к пенисометрии
ko4evnik> но извольте: 15 лет. там системка, тут вторая, там приборчик, тут программка...

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

Вот про то же определения алгоритма — с моим определением согласен?

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

Кстати, надо привлечь Tico — он реально embedded developer.

ko4evnik> окей, так и запишем:
ko4evnik> соотношение между алгоритмической и железячной частями:
ko4evnik> - при разработке компилятора = 1:1 при при характерной длительности разработки в десятки лет;

Запросто.

ko4evnik> - при разработке военной железки = 1:10 при характерной длительности в единицы лет/десятки месяцев. dixi.

Это как? На железке уже есть ОС и компилятор? Откуда? Можно подробней?

ko4evnik> получается. пример Союзов и Протонов тоже неплохо что-то показывает.

Не, так не работает. Сила системы определяется его слабейшим звеном. Здесь я должен заметить, что на Союзах и Протонах доля софтовых решений была намного меньше, чем на Ариане, ИМХО. И интеграция поменьше. Кстати, а как на Булаве, которая не особо летает?

ko4evnik> читать вообще полезно

Просто Гласс один из немногих, кого прилично перевели и он был известен в СССР. Хотя он писал и после развала. Переводили его уже в России — я про это не в курсе.

ko4evnik> "Монтаж" Эйзенштейна тоже неплох, если его правильно понимать.


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

ИМХО, сильно таки при чём.
Ну и кто определял модель, по которой надо считать?

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

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

Mishka> Это как? На железке уже есть ОС и компилятор? Откуда? Можно подробней?

Ну Вы жжёте Нормальные ВПК уже лет десять как переехали на стандартные архитектуры - и в железе, и в ПО. Кастомные решения остались разве что в местах границы аналог/цифра, да и там от них уже научились избавляться - SDR, например.

Конкретно для ГСН а-ля Python задачи обработки изображений сейчас обычно реализуются на совершенно стандартных FPGA.

Mishka> Здесь я должен заметить, что на Союзах и Протонах доля софтовых решений была намного меньше, чем на Ариане, ИМХО.

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

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

Близко к идеалу.

Nikita> Ну Вы жжёте Нормальные ВПК уже лет десять как переехали на стандартные архитектуры - и в железе, и в ПО. Кастомные решения остались разве что в местах границы аналог/цифра, да и там от них уже научились избавляться - SDR, например.

Дык, изначально вопрос даже не в этом — Серрокой не пересел вообще, он своё железо делает.

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

Nikita> Конкретно для ГСН а-ля Python задачи обработки изображений сейчас обычно реализуются на совершенно стандартных FPGA.

Обсуждали уже это. Если позволит — хорошо. Если нет — приходится лепить что-то другое.

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

Учись Читать! (С) Никита.

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

Mishka> Дык, изначально вопрос даже не в этом — Серрокой не пересел вообще, он своё железо делает.

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

Mishka> Обсуждали уже это. Если позволит — хорошо.

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

Mishka> Про то и разговор, что не дают рессурсов программистам в нужном количестве.

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

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

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

Mishka> Никто не говорит, что у них лафа. Но и почти всегда им давать больше времени и ресурсов тоже не правильно. Это надо осознать просто. Поскольку создаётся программно-аппаратный комплекс. Когда для решения задач подходит стандартное железо, то другое дело. Ты пытаешься на это дело перейти, но, ИМХО, тут больше разговор именно о программно-аппаратном комплексе.
Да, именно так. ) Я не говорю, я никогда не утверждал, что "аппартатчикам" существенно сложнее или существенно проще. Я говорю, что их работа сравнима по сложности с работой программистов. Мне ж отказывают и в этой сентенции... Это меня крайне возмущает. )

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

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

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