Автопилот существует и даже имеет множество воплощений. Рикша/такси/личный водитель/… Примерно так и воспринимают эти системы потребители. Простой человеческий фактор в условиях отсутствия необходимости разбираться в проблематике и малых рисков.
По сути же вопроса авиационные эквивалентны, упомянутые выше, по ряду параметров проще обсуждаемых систем. Во-первых, в авиации гораздо строже регламент эксплуатирования воздушного пространства, а это радикально снижает влияние человеческого фактора. Количество и разнообразие природных явлений/процессов также не сопоставимо с особенностями рельефа и разметки на земле. Не говоря уже о числе смежных объектов, управляемых человеком или автоматикой. Иными словами, история показывает, что существование и развитие автопилотируемых средств в авиации есть задача несколько более простая. И эти средства, по своей сути, есть ни что иное как полноценный эквивалент пилота, к чему мы пока не готовы на земле. Поскольку в авиации есть понимание последствий отказа этого технического средства, оно воспринимается как ассистент пилота, хотя в техническом смысле оно является его полноценным эквивалентом по многим параметрам. На земле у водителя риски ниже и степень расслабленности соответственная.
Более полувека назад придумана замечательная штука, которая называется Variance reduction. От ее классической трактовки произрастают такие не менее замечательные методы, как: Common Random Numbers, Antithetic variates, Control variates, Stratified sampling, Latin hypercube sampling (LHS) и многие другие.
На подавляющем большинстве реальных задач они сводят к нулю необходимость городить кластер или организовывать параллельные вычисления. В части стат. моделирования в статье раскрыт лишь инженерный подход, к сожалению.
Дело в том, что вся теория RT-систем обычно подразумевает планирование CPU
Вот тут немного не соглашусь, зарубежные труды по этой теме уже много десятилетий приводят примеры из разных областей.
Поскольку трудов по применению классики в новых условиях не предвидится, хотелось бы верить, что будет в будущем статья на эту тему, как раз раскрывающая эти тезисы.
Теоретический предел по времени отклика в 69% справедлив только для систем с единственным процессором. Согласитесь, в современных реалиях апеллирование к оценке второй половины прошлого века выглядит более чем странно. RM и EDF не применяются в явном виде в SMP, поскольку в этом классе систем они не оптимальны. В том числе ввиду влияния эффекта Далла (Dhall's effect), от которого свободны такие методы, как RM_US/SM_US и многочисленные многопроцессорные модификации EDF. Касательно последних встает вопрос об их применимости в промышленности, ввиду их явной академичности. Во всяком случае, об их серьезном применении в промышленности для решения реальных задач на реальном же железе ничего не известно (впрочем, буду рад переубедиться).
Все замечания отношу исключительно к Hard Real-Time системам, поскольку Soft являются утопией. Там, где не требуется Hard можно обойтись и без Real-Time. Если цена пропуска дедлайна не имеет значения, не имеет смысла и заморачиваться с RTOS.
EDF относится к частично-динамическим дисциплинам планирования, в то время, как стандартом в системах жесткого реального времени являются статические. Мифа #7 является мифом лишь в классе не-статических процедур. В промышленных задачах миф #7 оказывается полностью выполнимым, поскольку c 2001 года известны условия, при которых гарантируется 100% соблюдение дедлайнов в статике в SMP-системах.
В части указанных недостатков современная наука дает однозначный ответ — полностью динамические дисциплины, такие как PFair.
Boost у GPU динамический, видео память настраивается драйвером, eDRAM фиксированная по размеру. О каких параметрах, определяющих производительность, идет речь?
У них свой компилятор, именуют они его не иначе как lcc. Фронтенд у него с gcc по большей части совместим, бэкенд свой. По glibc же напишите им запрос соответствующий, будет интересно узнать что напишут в ответ.
В этой истории здравое звено начинается ровно в точке привнесения в модель фактора межродовых войсковых коммуникаций. Страшилки страшилками, но до того недавнего момента, когда Алмаз-Антей подмял под себя всю отрасль окончательно, не существовало даже гипотетической возможности подобные технологии контролировать.
К объективным состоявшимя фактам также можно отнести переход проектов вроде X-37 из ведомства NASA в ведомство DARPA.
Заметьте, никто не говорит о «совокупной стоимости владения» новым продуктом. Сдается мне, что этот параметр либо не внушает оптимизма, либо никто его не оценивал.
Тенденция конечно же положительная, но мне больше интересно как будут решаться вопросы вида: «у моего подчиненного в виндовс работало так-то, здесь не работает/работает не так, как ожидалось/...»; «ранее был специфичный драйвер/софт/периферия, что делать в новых реалиях». Если такие вопросы подразумевается отдавать на откуп каждому отдельному ведомству, то головной боли всем только многократно прибавится. Если же подразумевается некая организация, которая (а) в состоянии все это сопровождать и (б) обладает достаточно компетентным кадровым составом, то почему о них не сказано ни слова?
Фигурируют регулярно формулировки вида «произведен успешный пуск, выведены спутники такой-то страны». Кто в таком сценарии оплачивает аренду, пуск и собственно носитель?
Если известно, хотелось бы узнать как эти средства коррелируют с общей экономической базой отрасли? Собственно, интересует потенциальная прибыль и спрос со стороны заинтересованных стран. С неделю назад беседовал с коллегой из РКК «Энергия», по его словам на 10 лет выделено 2.2 триллиона рублей, при изначальной оценке затрат на существующие проекты в 4+. Как он утверждает, около 50% от выделенных средств только МКС съедает. Идет ли речь о какой-либо окупаемости космодрома? Благодарю.
Нет, вы не поняли: приличные люди не копаются в ассемблере
Ну почему же? Да, они не копаются в нем напрямую, однако проблемы исполнителей в конечном итоге рикошетят наверх, если дело дойдет до срыва заказа. Однако, это далеко от обсуждаемого вопроса.
Ну а то, что потом из этой документации вы не можете выудить ничего полезного — так это никого не волнует, и в первую очередь ваше же начальство: «Тебе же дали документацию — читай внимательнее!»
Вы погружаетесь в частности и субъективность, чего сами же просили не допускать. Напомню основной тезис: документация на выходе не лучшего качества.
приличные люди достаточно быстро перестают таковыми быть когда речь заходит о необходимости разбираться в ассемблере ПО для Эльбрус ОС.
Конкретно по вашему вопросу. Отбросив субъективные сентенции и регламентируемые стандаром кальки, содержание широкого ряда упомянутых документов не предполагает погружение в тематику в разумные сроки.
По сути же вопроса авиационные эквивалентны, упомянутые выше, по ряду параметров проще обсуждаемых систем. Во-первых, в авиации гораздо строже регламент эксплуатирования воздушного пространства, а это радикально снижает влияние человеческого фактора. Количество и разнообразие природных явлений/процессов также не сопоставимо с особенностями рельефа и разметки на земле. Не говоря уже о числе смежных объектов, управляемых человеком или автоматикой. Иными словами, история показывает, что существование и развитие автопилотируемых средств в авиации есть задача несколько более простая. И эти средства, по своей сути, есть ни что иное как полноценный эквивалент пилота, к чему мы пока не готовы на земле. Поскольку в авиации есть понимание последствий отказа этого технического средства, оно воспринимается как ассистент пилота, хотя в техническом смысле оно является его полноценным эквивалентом по многим параметрам. На земле у водителя риски ниже и степень расслабленности соответственная.
На подавляющем большинстве реальных задач они сводят к нулю необходимость городить кластер или организовывать параллельные вычисления. В части стат. моделирования в статье раскрыт лишь инженерный подход, к сожалению.
Все верно, только Вы забыли следующие моменты:
Вот тут немного не соглашусь, зарубежные труды по этой теме уже много десятилетий приводят примеры из разных областей.
Поскольку трудов по применению классики в новых условиях не предвидится, хотелось бы верить, что будет в будущем статья на эту тему, как раз раскрывающая эти тезисы.
Все замечания отношу исключительно к Hard Real-Time системам, поскольку Soft являются утопией. Там, где не требуется Hard можно обойтись и без Real-Time. Если цена пропуска дедлайна не имеет значения, не имеет смысла и заморачиваться с RTOS.
P.S. Прошу прощения, запостил не в ответ.
В части указанных недостатков современная наука дает однозначный ответ — полностью динамические дисциплины, такие как PFair.
К объективным состоявшимя фактам также можно отнести переход проектов вроде X-37 из ведомства NASA в ведомство DARPA.
Тенденция конечно же положительная, но мне больше интересно как будут решаться вопросы вида: «у моего подчиненного в виндовс работало так-то, здесь не работает/работает не так, как ожидалось/...»; «ранее был специфичный драйвер/софт/периферия, что делать в новых реалиях». Если такие вопросы подразумевается отдавать на откуп каждому отдельному ведомству, то головной боли всем только многократно прибавится. Если же подразумевается некая организация, которая (а) в состоянии все это сопровождать и (б) обладает достаточно компетентным кадровым составом, то почему о них не сказано ни слова?
Ну почему же? Да, они не копаются в нем напрямую, однако проблемы исполнителей в конечном итоге рикошетят наверх, если дело дойдет до срыва заказа. Однако, это далеко от обсуждаемого вопроса.
Вы погружаетесь в частности и субъективность, чего сами же просили не допускать. Напомню основной тезис: документация на выходе не лучшего качества.
Конкретно по вашему вопросу. Отбросив субъективные сентенции и регламентируемые стандаром кальки, содержание широкого ряда упомянутых документов не предполагает погружение в тематику в разумные сроки.