Здравствуйте, AndreyFedotov, Вы писали:
AF> Вариант "Да ктож ему столько даст". Это так ситуация, когда вычислительные ресурсы лишь не намного превосходят потребности решаемых задач. То есть запас по времени очень не большой. Типичным примером являются телекоммуникационные системы.
Не а. Не являются. На самом деле, стоимость железа в телекоме не имеет значения -- она составляет очень небольшую часть стоимости всей системы. Для крупных промышленных проектов затраты на разработку софта на два порядка больше. При проектировании железа обычно закладывают максимум, достижимый на доступной элементной базе в данный момент. Ну разумеется, ограничивающим фактором является класс аппаратуры. Скажем, если девайс стоит на улице -- сразу идут ограничения, ну и.т.д.
Основная проблема тут в другом. Аппаратура не покупается на 1 год. Т.е. после своего развертывания она будет эксплуатироваться много лет. При этом апгрейд железа уже невозможен -- только софта. Ну а поскольку аппетиты со временем растут, очень часто возникает ситуация, когда нужно выжать максимум на заданной аппаратной базе чисто програмными средствами.
Телеком вообще характерен тем, что мощности процессоров здесь не хватает и всегда не будет хватать. Поскольку ни один существующий процессор не может обработать поток данных всего с одного оптоволоконного кабеля. Т.е. пропускная способность каналов связи, и даже радиоканалов, растет по крайней мере не медленнее, чем вычислительная мощьность процессоров.
AF>Здесь стоимость оборудования играет гораздо более высокую роль, чем для систем управления АЭС или аэропортами, а объёмы производства гораздо выше. Потому ставить оборудование с большим запасом по производительности не рентабельно. В этих условиях софт обычно проще, чем для систем управления АЭС, с точки зрения его логики, но зато возникает ряд других проблем.
Нет, не проще. На самом деле, софт в телекоме по логике своей работы очень сложен -- АЭС тут отдыхают.
Страуструп не зря ведь С++ выдумал для того чтобы с этой сложностью бороться.
AF> Обычно используются компиляторы и инструментарий сторонних производителей. Очень часто это производители железа, поставляющие со своим железом так же компиляторы ЯВУ. Беда в том, что вы не можете наверняка знать, как ведёт себя компилятор. Более того, многие из этих компиляторов весьма здорово отличаются от стандарта (и не в лучшую сторону).
Эта проблема раньше действительно была, но сейчас она уже не имеет прежней остроты. Тот же GCC вполне юзабелен.
AF>Потому часто работа начинается с детального исследования своиств комилятора. Но и этого мало! Качество компиляторов не особенно высокое и часто оказывается, что в них есть ошибки, иногда достаточно критичные. И вот тут то начинается самое веселье! Вы вынуждены переходить на новую версию компилятора — в середине, а то и в конце проекта и тут выясняется, что вместе с поправленной ошибкой — производетель компилятора переколбасил половину кодогенерации! Что-то у вас было inline — и вдруг перестало! А всё потому, что обнаружив, что inline функции реализованы неверно, производитель компялятора их вообще убрал! И это совершенно реальный случай. И далеко не единственный.
AF> В таких условиях использование любого ЯВУ, со скрытыми фичами — вроде C++ может являть собой огромный риск для всего проекта.
Если нет приличного компилятора -- то да. Но эта проблема к языку имеет касательное отношение.
Есть ещё одна проблема -- люди. И она, как показывает опыт, более существенна, чем даже качество компиляторов. Индокитай блин. Где моя атомная бонба!
AF> Потому в таких случаях предпочитают использовать C, Pascal или уж если и использовать C++, но в режиме процедурного программирования, притом аккуратно отслеживая, что бы не допустить ни в коем случае какую либо из столь полезных фич. Обычно такое использование напоминает C with classes гораздо больше, чем C++. Кстати некоторые производители компиляторов так и выпускают "C++" без шаблонов или инлайн-функций — ведь всё равно клиенты ими не пользуются!
Это просто дурь -- С++ без инлайн-функций и шаблонов -- не С++. На фиг не нужен.
AF> Вариант "впихиваем невпихуемое". Это ситуация когда аппаратные ресурсы используются близко к абсолютному максимуму. Это и есть то самое сверх-жёсткое реальное время. Тут счёт идёт на такты.
Не совсем. Тут дело в особенностях режима работы, а не в недостатке вычислительной мощности.
AF> О языках вроде C++ речи даже близко не идёт. Значительная (иногда большая) часть кода написана на ассемблере, остальное — C или Pascal
Здравствуйте, AndreyFedotov, Вы писали:
AF> ядерных объектов, таких как АЭС.
...
AF> От себя добавлю, что если речь идёт о проектах, вроде софта для АЭС
Судя по частоте упоминания, примерно половина программистов в России пишет софт для АЭС.
Я вобщем то тоже не большой спец по подобным вещам, но сдается мне, что на критических участках, вроде управления замедлителем или давлением в теплообменных контурах, управляет совсем не софт.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Вариант "Да ктож ему столько даст". Это так ситуация, когда вычислительные ресурсы лишь не намного превосходят потребности решаемых задач. То есть запас по времени очень не большой. Типичным примером являются телекоммуникационные системы.
Ш>Не а. Не являются. На самом деле, стоимость железа в телекоме не имеет значения -- она составляет очень небольшую часть стоимости всей системы.
Это смотря для чего конкретно. Если речь идёт о корневых узлах интернет или телефонной сети — то тут согласен — идеология та же, что и в случае других критичных и уникальных систем.
Однако если речь идёт об аппаратуре, массово распространённой, вроде того, что устанавливается на АТС или обычных офисных АТС — то тут стоимость железа гораздо более существенна и играет роль преимущества в конкурентной борьбе.
Про продукты крупно-серийные (вроде тех же мобильников) — то тут цена железа ещё более существенна, но там как правило софт гораздо сложнее, и реальное время, за рамками ядра, ответственного за коммуникации не существенно. Потому ядро пишут применяя одни технологии — а всё остальное — совсем другие.
Ш>Для крупных промышленных проектов затраты на разработку софта на два порядка больше. При проектировании железа обычно закладывают максимум, достижимый на доступной элементной базе в данный момент. Ну разумеется, ограничивающим фактором является класс аппаратуры. Скажем, если девайс стоит на улице -- сразу идут ограничения, ну и.т.д.
Полностью согласен. Собственно именно это я и утверждал, когда рассмартивал вариант автоматизации крупных промышленных и военных объектов — вроде АЭС, топливохранилищ и критичных производств. Там действительно стоимость железа — малая часть, потому там достаточно свободно с вычислительными ресурсами, зато очень сложный софт.
Ш>Основная проблема тут в другом. Аппаратура не покупается на 1 год. Т.е. после своего развертывания она будет эксплуатироваться много лет. При этом апгрейд железа уже невозможен -- только софта. Ну а поскольку аппетиты со временем растут, очень часто возникает ситуация, когда нужно выжать максимум на заданной аппаратной базе чисто програмными средствами.
Это так, но это относится скорее к телекому, чем к объектам вроде АЭС. Для последних связка аппаратура + софт сертифицируется всякий раз отдельно, стоит это не мало и изменения того или другого происходят очень редко.
Ш>Телеком вообще характерен тем, что мощности процессоров здесь не хватает и всегда не будет хватать. Поскольку ни один существующий процессор не может обработать поток данных всего с одного оптоволоконного кабеля. Т.е. пропускная способность каналов связи, и даже радиоканалов, растет по крайней мере не медленнее, чем вычислительная мощьность процессоров.
Это так, кроме того, поскольку в телекоме пропускная способность — как то скорость или количество каналов — является основным товаром, то возникает устойчивая тенденция навешивать на железо всего по максимуму.
AF>>Здесь стоимость оборудования играет гораздо более высокую роль, чем для систем управления АЭС или аэропортами, а объёмы производства гораздо выше. Потому ставить оборудование с большим запасом по производительности не рентабельно. В этих условиях софт обычно проще, чем для систем управления АЭС, с точки зрения его логики, но зато возникает ряд других проблем.
Ш>Нет, не проще. На самом деле, софт в телекоме по логике своей работы очень сложен -- АЭС тут отдыхают. Ш>Страуструп не зря ведь С++ выдумал для того чтобы с этой сложностью бороться.
В принципе согласен, погорячился. Смотря где и в чём. Иногда гораздо проще, иногда и существенно сложнее. И C++ там в некоторых случаях применяется очень успешно. Да и не только он — например там в некоторых случаях очень успешно применяются функциональные языки.
AF>> Обычно используются компиляторы и инструментарий сторонних производителей. Очень часто это производители железа, поставляющие со своим железом так же компиляторы ЯВУ. Беда в том, что вы не можете наверняка знать, как ведёт себя компилятор. Более того, многие из этих компиляторов весьма здорово отличаются от стандарта (и не в лучшую сторону).
Ш>Эта проблема раньше действительно была, но сейчас она уже не имеет прежней остроты. Тот же GCC вполне юзабелен.
Увы это не совсем так. Если используется предидущее поколение железа (устаревшее примерно на год), то компиляторы действительно уже есть, тот же GCC. Но часто разработка ведётся под новое железо для которого компиляторы ещё сырые, а ждать появления стабильных — нет времени.
AF>>Потому часто работа начинается с детального исследования своиств комилятора. Но и этого мало! Качество компиляторов не особенно высокое и часто оказывается, что в них есть ошибки, иногда достаточно критичные. И вот тут то начинается самое веселье! Вы вынуждены переходить на новую версию компилятора — в середине, а то и в конце проекта и тут выясняется, что вместе с поправленной ошибкой — производетель компилятора переколбасил половину кодогенерации! Что-то у вас было inline — и вдруг перестало! А всё потому, что обнаружив, что inline функции реализованы неверно, производитель компялятора их вообще убрал! И это совершенно реальный случай. И далеко не единственный.
AF>> В таких условиях использование любого ЯВУ, со скрытыми фичами — вроде C++ может являть собой огромный риск для всего проекта.
Ш>Если нет приличного компилятора -- то да. Но эта проблема к языку имеет касательное отношение.
И да и нет. Дело даже не в качестве компилятора, а в тех свойствах языка, которые в иных обстоятельствах дают существенные преимущества, но могут быть реализованы совершенно по разному различными компиляторами или даже разными версиями одного компилятора — то есть в предсказуемости кода, порождаемого компилятором языка. Опять таки это вроде бы не относится непосредственно к самому языку, но поскольку без компилятора толку от языка нет, то на практике проблема решается выбором языка и ограничений на его использование.
Ш>Есть ещё одна проблема -- люди. И она, как показывает опыт, более существенна, чем даже качество компиляторов. Индокитай блин. Где моя атомная бонба!
Полностью согласен.
Только это проблема универсальная.
AF>> Потому в таких случаях предпочитают использовать C, Pascal или уж если и использовать C++, но в режиме процедурного программирования, притом аккуратно отслеживая, что бы не допустить ни в коем случае какую либо из столь полезных фич. Обычно такое использование напоминает C with classes гораздо больше, чем C++. Кстати некоторые производители компиляторов так и выпускают "C++" без шаблонов или инлайн-функций — ведь всё равно клиенты ими не пользуются!
Ш>Это просто дурь -- С++ без инлайн-функций и шаблонов -- не С++. На фиг не нужен.
Но именно так его часто испольуют разработчики железа. Косвенно в этом можно убедиться, поговорив с каким-нибудь железячником — выясняется, что человек использует C++ последние 15 лет, но о шаблонах знает лишь то, что они есть
AF>> Вариант "впихиваем невпихуемое". Это ситуация когда аппаратные ресурсы используются близко к абсолютному максимуму. Это и есть то самое сверх-жёсткое реальное время. Тут счёт идёт на такты.
Ш>Не совсем. Тут дело в особенностях режима работы, а не в недостатке вычислительной мощности.
Согласен. Так я же и не устверждаю, что единственный вариант жёсткого реального времени — это недостаток ресурсов, это так же может быть связано и с режимом работы и с объёмом обрабатываемых данных.
AF>> О языках вроде C++ речи даже близко не идёт. Значительная (иногда большая) часть кода написана на ассемблере, остальное — C или Pascal
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AndreyFedotov, Вы писали:
AF>> ядерных объектов, таких как АЭС.
AVK>...
AF>> От себя добавлю, что если речь идёт о проектах, вроде софта для АЭС
AVK>Судя по частоте упоминания, примерно половина программистов в России пишет софт для АЭС.
Нет конечно. Но речь то изначально шла не о том, чего больше, ПК или АЭС, а о том, что есть другие области, чем написание бизнес софта для ПК, в которых используются совершенно другие подходы.
Кстати, если чуть-чуть подумать, то восторг от того, что в россии пишется преимущественно софт под Windows или в крайнем случае Linux/FreeBSD, быстро проходит, а в замен приходят мысли о месте негров в мировом разделении труда и том, чем это закончится для оных негров.
AVK>Я вобщем то тоже не большой спец по подобным вещам, но сдается мне, что на критических участках, вроде управления замедлителем или давлением в теплообменных контурах, управляет совсем не софт.
Там используются механика, но ведь ей тоже надо управлять.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Про продукты крупно-серийные (вроде тех же мобильников) — то тут цена железа ещё более существенна, но там как правило софт гораздо сложнее, и реальное время, за рамками ядра, ответственного за коммуникации не существенно. Потому ядро пишут применяя одни технологии — а всё остальное — совсем другие.
Про конкретно мобильники могу сказать, что у нас подавляющую долю занимает Си, но есть и относительно немного Си++ (а точнее "Си с классами"), и так же есть относительно немного асма на нижнем уровне.
Ш>>Эта проблема раньше действительно была, но сейчас она уже не имеет прежней остроты. Тот же GCC вполне юзабелен. AF>Увы это не совсем так. Если используется предидущее поколение железа (устаревшее примерно на год), то компиляторы действительно уже есть, тот же GCC. Но часто разработка ведётся под новое железо для которого компиляторы ещё сырые, а ждать появления стабильных — нет времени.
Вообще-то разработка компилятора ведется под процессор. Не думаю, что предыдущее поколение содержит какие-то масштабные изменения, что аж весь компилятор приходится писать с нуля. Измнения-то по сути затрагивают лишь часть генератора, да оптимизатора.
Хотя, если скакать с проца на проц, или использовать тот, который на каждый свой релиз полностью меняет архитектуру ... тады да.
Ш>>Это просто дурь -- С++ без инлайн-функций и шаблонов -- не С++. На фиг не нужен. AF>Но именно так его часто испольуют разработчики железа. Косвенно в этом можно убедиться, поговорив с каким-нибудь железячником — выясняется, что человек использует C++ последние 15 лет, но о шаблонах знает лишь то, что они есть
Согласен. Например, у нас он используется в одной подсистеме просто для того, чтобы можно было отнаследоваться. А потом просто создается единственный статический экземпляр класса, который свою работу и делает.
Инлайн функции в большинстве своем, например, вообще зло — лишние расходы на память, которая очень дорога.
Тут приоритет имеет оптимизация по памяти, а не по скорости. И ежу понятно, что ни о каком ГЦ не может быть и речи. Основное правило — выделяй память как можно позже, освобождай как можно раньше.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Avantasia — Memory";
Здравствуйте, ansi, Вы писали:
A>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Про продукты крупно-серийные (вроде тех же мобильников) — то тут цена железа ещё более существенна, но там как правило софт гораздо сложнее, и реальное время, за рамками ядра, ответственного за коммуникации не существенно. Потому ядро пишут применяя одни технологии — а всё остальное — совсем другие.
A>Про конкретно мобильники могу сказать, что у нас подавляющую долю занимает Си, но есть и относительно немного Си++ (а точнее "Си с классами"), и так же есть относительно немного асма на нижнем уровне.
Согласен. Слова не мальчика но мужа! Та же ситуация и у других разработчиков под мобильники. Даже в проклятом буржуинстве.
Ш>>>Эта проблема раньше действительно была, но сейчас она уже не имеет прежней остроты. Тот же GCC вполне юзабелен. AF>>Увы это не совсем так. Если используется предидущее поколение железа (устаревшее примерно на год), то компиляторы действительно уже есть, тот же GCC. Но часто разработка ведётся под новое железо для которого компиляторы ещё сырые, а ждать появления стабильных — нет времени. A>Вообще-то разработка компилятора ведется под процессор. Не думаю, что предыдущее поколение содержит какие-то масштабные изменения, что аж весь компилятор приходится писать с нуля. Измнения-то по сути затрагивают лишь часть генератора, да оптимизатора. A>Хотя, если скакать с проца на проц, или использовать тот, который на каждый свой релиз полностью меняет архитектуру ... тады да.
Теоретически всё это так. Но практически всё зависит от того, с каким железом вы имеете дело. Если это ARM7 или ARM9 — то есть железо, ядро которого хорошо описано, стандратизовано и сертифицированно — то с компилятором всё достаточно просто. Да хотя бы CodeWarrior.
Но если речь идёт о DSP процессорах, то там часто приходится использовать кристалы от разных производителей или разных серий. Даже у одного производителя кристаллы могут иметь различные компиляторы (хотя они обычно встроены в единую среду разработки в виде отдельных модулей). Обычно если новый кристал совместим с более старыми кристалами, то разработка начинается с компилятором под более старый кристал (но часто не учитывающего каких-то особенностей нового, допустим некоторых команд), а продолжается уже с новым. Вот этот то момент смены компилятора особенно критичен, особенно если компилятор сырой
Ш>>>Это просто дурь -- С++ без инлайн-функций и шаблонов -- не С++. На фиг не нужен. AF>>Но именно так его часто испольуют разработчики железа. Косвенно в этом можно убедиться, поговорив с каким-нибудь железячником — выясняется, что человек использует C++ последние 15 лет, но о шаблонах знает лишь то, что они есть
A>Согласен. Например, у нас он используется в одной подсистеме просто для того, чтобы можно было отнаследоваться. А потом просто создается единственный статический экземпляр класса, который свою работу и делает. A>Инлайн функции в большинстве своем, например, вообще зло — лишние расходы на память, которая очень дорога. A>Тут приоритет имеет оптимизация по памяти, а не по скорости. И ежу понятно, что ни о каком ГЦ не может быть и речи. Основное правило — выделяй память как можно позже, освобождай как можно раньше.
Согласен.
Так и живём...
Здравствуйте, AndreyFedotov, Вы писали:
AF> Имеет Влад и самое прямое. Если реальное время "достаточно жёсткое", то есть гарантированное время отклика близо ко времени решения задачи (притом не любым, а оптимальным или близим к нему образом), то произоводительность имеет критическое значение.
Производительность должна быть достаточной. Ну, а повторяться не охота.
AF> Самое прямое. Ты же не станешь отрицать, что любой алгоритм сборщика мусора — потенциально (с точки зрения математики) медленнее, чем алгоритм работы с кучей (вырожденные или специально подобранные случаи вроде очень хорошо написанного первого и очень плохо написанного второго я не рассматриваю)?
Стану. Хип из большинства ОС откровенно проигрывает ЖЦ на объектах малого размера.
Ну, и к теме СРВ это не имеет ни малейшего отношения. Там важно отсуствие непредсказуемых задержек. Вот тут ЖУ сложнее. Но есть специальные версии ЖЦ которые гарантируют определенное время сборки мусора.
AF> Причём медленнее по банально простой причине — сборщику мусора приходится анализировать запутанные связи в программе во время выполнения, в то время как в куче эти связи приходится учитывать и оптимизировать разработчику — ещё в Design Time.
Большинство же релализаций CRT-куч (и им подобных) основано на связанных списках и дают нехилые (и гланое не предсказуемые) задержки при фрагментации кучи.
AF>>> В системах жёсткого реального времени могут быть опасны даже такие фичи C++ как dynamic_cast — так как последний требует линейного времени работы (в зависимости от глубины типов), что явным образом не видно.
VD>>Жить вообще опасно.
AF>Гениальный ответ! Якрий, красивый, интересный, мудрый... И абсолютно не относящийся к сути дела.
Для особо непонятливых — это был сарказм.
AF>Да, я понимаю, что извернувшись через одно (или несколько мест), можно программировать для RT-OS даже на BASIC.
Почему даже? Чем он хуже других?
AF> Вот только зачем?
Например, чтобы уменьшить количество ошибок и время отладки.
AF> Что бы фанатично заявить что Basic самый крутой язык программирования?
Подобные заявления обычно присущи представителям другого языка.
AF> Или же всё-таки стоит выбрать более удобные в данном контексте средства для решения данной задачи?
Вопрос, что считать удобством при решении задачи? Выбр более низкоуровневого языка — это не выбор более удобного решения. Это выбор самого легкодоступного решения которое потом приведет у более сложной разработке. Именно по этому ребята из Сана и занимаются разработкой ЯваРВ, а разные телекомуникационные компании даже используют динамически типизированные функциональные языки.
AF>>>Да, понятно что и на одной ноге можно мастерски научиться танцевать при желании. Только вот зачем?
VD>>Вот и меня это интересует. Давай спросим об этом у поклонников С++.
AF>Подозреваю, что применительно к OS-RT придётся спрашивать у поклонников C# и Java.
Да, нет. С++ это всегда танцы с бубном.
AF>Для СРВ лучшим выбором может быть даже не C++, а C, Pascal или даже, в некоторых случаях, ассемблер. У если не то пошло — то лучшим, чем C# или Java выбором для них будет ужастный Оберон!
Выбор ассемблера может быть оправдан только очень ограниченными возможностями аппаратной платформы или отсуствием компиляторов. Сдается мне, что выбор С/С++ должен вестись по тем же принципам.
AF>Потому то именно на нём, а не C# или Java пишут системы управления критичными объектами.
Не смешите меня. Когда речь идет о чем-то ктитическом, то С/С++ выбирают или от безысходности, или явные фанатики.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Знаешь, Влад, а ведь даже редактор, который ты переписываешь для Януса, так же можно считать real-time системой, т.к. результат работы в нем появляется прямо в реальном времени, без задержек и отсрочек.
Точно. Значит на дотнете без каких либо модификаций можно писать СРВ. Так о чем ты тогда?
E>Но ведь это же не то, о чем идет речь в данной ветке. И уж совсем точно ты не обратил внимания на фразу "жестких требований".
Да, уж. Я заметил, что слова о медленности управляемого кода являются не обоснованными и сильно задолбавшими. На что мне вылили тираду о СРВ. Жусткость и мягкость будет изумительным продолжением разговора.
VD>>Ладно обратимся опять к википедии.
E>Ты все сведения черпаешь из википедии?
Нет.
E> А "википедия" -- это что, признаный авторитетный источник?
Википедия — это доступный источник с достаточно качественным (в большинстве случаев) содержимым.
E>Типа Большой Совецкой Энциклопедии?
К сожалению, БСЭ не содержит информации по программированию и всему что с ним связано. Когда я обосновываю свои утверждения в общих областях, то ссылаюсь на БСЭ с удовольствием, например, http://rsdn.ru/Forum/Message.aspx?mid=1088033&only=1
.
E>Конечно, сапожник всегда без сапог ходит. Я шесть лет проработал в КБ, основной специализацией которого были системы реального времени (как военного, так и гражданского назначения (АСУТП и ИИС)). Задачами жесткого реального времени, правда, заниматься не пришлось. Но наслышан.
Темболее странно слышать от тебя такие суждения. И уж совсем странно видеть как ты помогашь уходить от сбсужения скорости и переводишь стрклки на СРВ.
E>Так вот, касаясь википедии. Мне сложно судить, насколько она качественно написана в разделах о реальном времени.
Большинство информации в википедии цельно-тянуто из других авторитетных источников. Во многом она заполняется людьми профессионально занимающимися некоторыми вопросами. К сожалению это не всегда так и иногда попадаются плохие описания.
E> Но если ты черпаешь знания о реальном времени из википедии, то остается вопросить "А судьи кто?". Что-то мне не кажется, что ты компетентен в данных вопросах.
Может не стоит напиарать на некомпитентность источника без хотя бы каких-то других источников?
E>Под нормальными задачами реального времени я понимал задачи с временами, измеряемыми единицами миллисекунд.
И чем они нормальнее чем задачи в которых требуются времена отклика в доли милисекунд или в сотни милисекунд?
VD>>Когда заранее? А если алгоритм требует постоянно занимать и освобождать память? А вот это народ о чем говорит: real-time heap?
E>Понятия не имею о чем кто и чего говорит. Я лично говорю о том, что видел и с чем работал. Алгоритмы с new/delete и динамическим перераспределением памяти идут лесом, да еще и со срашной силой.
Тогда еще раз спрошу в чем тогда проблема использовать ЖЦ-системы? Если память не занимается, то она и не освобождается. Достаточно одной АПИ функции запрещающей сборку мусора для некого участка кода и пиши себе СВР на чем угодно. Вот только в рельной жизни алгоритмы зачастую оказывются по слжнее.
E> Вся память выделяется заранее в виде пулов или цепочек буферов.
И в чем проблема построить ЖЦ на базе пулов или управляемый в ручную кучу?
E> И все что требуется при дальнейшей работе -- это просто циклически переназначать указатель на текущий буфер.
И почему этим не могут заниматься функции malloc/free или GC?
E>>> при раскручивании системы. Более того, часто эта память выделяется не через new, а в виде статических глобальных массивов.
VD>>Зашибись. Значит на любом ЖЦ можно писать real-time-системы, так как на любом ЖЦ можно не знаимать память во время работы. Займи себе все чт нужно при раскрутке системы и никаких сборк мусора не будет.
VD>>Бред? Несомненно...
E>Хочется особо подчеркнуть, что этот бред был написан тобой. И я совершенно не понимаю, откуда ты его вывел.
Специально не стираю твои слова. Честно говоря думал, ты заметишь, что это просто развитие твоей мысли.
E>И если тебе так уж нравится читать википедию, то прочти вот это: http://en.wikipedia.org/wiki/Real-time_operating_system E>Особенно раздел Memory allocation E>
E>Memory allocation is even more critical in a RTOS than in other operating systems.
E>Firstly, speed of allocation is important. A standard memory allocation scheme scans a linked list of indeterminate length to find a suitable free memory block; however, this is unacceptable as memory allocation has to occur in a fixed time in a RTOS.
E>Secondly, memory can become fragmented as free regions become separated by regions that are in use. This can cause a program to stall, unable to get memory, even though there is theoretically enough available. Memory allocation algorithms that slowly accumulate fragmentation may work fine for desktop machines—when rebooted every month or so—but are unacceptable for embedded systems that often run for years without rebooting.
E>The simple fixed-size-blocks algorithm works astonishingly well for simple embedded systems.
E>Что-то здесь про GC ни сном, ни духом.
Про ЖЦ в СВР сказано не мало в других источниках. Эта же цитата говорит о том, что занятие памяти хотя и критично, но не запрещено в СВР. Другими словами это ты привел цитату опровергающую твои же слова.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
VD>>А ты на JavaRT?
AF> На JavaRT писать не приходилось.
Тогда есть о чем поговорить.
AF> Зато приходилось иметь дело с 8, 16 и 32 битными контроллерами, а так же кучей DSP. Так там, если задача критичная (по отношению требуемое для её решения времени к гарнтированному времени отклика), неудобен был даже C++, Проще и лучше было писать на C, а в некоторых случаях на ассемблере. Поскольку подобных экспериментов с каждым из этих языков было проделано множество и не только мной — опыт достаточно хороший для того, что бы на его основе делать выводы про переспективы применения в данных областях той или иной технологии. Так вот JavaRT там как корове ярмо — по тем же причинам, по которым там частенько выступал в таком же качестве C++.
То есть предлагашь развить тему производительности управляемого кода уже даже не на СВР, а на программирование котроллеров?
Может уже хватит этого фарса? Какое отношение котроллеры имеют к данному воросу?
Ну, а предпочтение С вместо С++ это вообще странно выглядит. Языки то обратно совместимы. Я еще понял бы если бы ты о С99 говорил. Пиши себе на подмножестве С++ не вызывающем рантаймтых операций...
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>> ядерных объектов, таких как АЭС.
AVK>>...
AF>>> От себя добавлю, что если речь идёт о проектах, вроде софта для АЭС
AVK>>Судя по частоте упоминания, примерно половина программистов в России пишет софт для АЭС. AF> Нет конечно. Но речь то изначально шла не о том, чего больше, ПК или АЭС, а о том, что есть другие области, чем написание бизнес софта для ПК, в которых используются совершенно другие подходы. AF> Кстати, если чуть-чуть подумать, то восторг от того, что в россии пишется преимущественно софт под Windows или в крайнем случае Linux/FreeBSD, быстро проходит, а в замен приходят мысли о месте негров в мировом разделении труда и том, чем это закончится для оных негров.
Ну, на самом деле, это не только в России. Естественно, наибольший сегмент рынка по числу особенно мелких приложений -- это бизнес-программирование.
Но должен заметить, что в России делают и передовые разработки. Так что не всё так плохо.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, ansi, Вы писали:
A>>Здравствуйте, AndreyFedotov, Вы писали:
AF> Теоретически всё это так. Но практически всё зависит от того, с каким железом вы имеете дело. Если это ARM7 или ARM9 — то есть железо, ядро которого хорошо описано, стандратизовано и сертифицированно — то с компилятором всё достаточно просто. Да хотя бы CodeWarrior. AF> Но если речь идёт о DSP процессорах, то там часто приходится использовать кристалы от разных производителей или разных серий. Даже у одного производителя кристаллы могут иметь различные компиляторы (хотя они обычно встроены в единую среду разработки в виде отдельных модулей). Обычно если новый кристал совместим с более старыми кристалами, то разработка начинается с компилятором под более старый кристал (но часто не учитывающего каких-то особенностей нового, допустим некоторых команд), а продолжается уже с новым. Вот этот то момент смены компилятора особенно критичен, особенно если компилятор сырой
Для DSP ситуация действительно хуже. Но и здесь есть прогресс.
Здравствуйте, VladD2, Вы писали:
E>>Под нормальными задачами реального времени я понимал задачи с временами, измеряемыми единицами миллисекунд.
VD>И чем они нормальнее чем задачи в которых требуются времена отклика в доли милисекунд или в сотни милисекунд?
Тем, что это не экстрим, а вполне нормальный тем. Доли миллисекунд, т.е. микросекунды -- это уже достаточно жесткое время. А сотни миллисекунд, т.е. десятые секунды, могут быть жестким временем только при очень больших объемах вычислений или какой-то специфической работой с периферией, которую сложно впихнуть в сотню миллисекунд.
Теперь скажу свое мнение по поводу GC в системах с жесткими требованиями к реальному времени. Garbage Collector изначально предназначен для того, чтобы собирать освободившуюся память и отдавать ее под новые нужды. В тех системах реального времени, с которыми я сталкивался, память не освобождалась и не перевыделялась. Поскольку вся она была выделена заранее. А так как в процессе работы нет перевыделений памяти, то и GC не нужен.
Далее, по поводу того, чтобы смещать указатель на текущий буфер по цепочке заранее выделенных буферов. Нет смысла здесь применять malloc/free или GC потому, что при смене указателя буфера не оказываются свободными -- вот ведь в чем фокус. Стандартная практика -- это выделение заранее стольких буферов, сколько задач одновременно будет обрабатываться. Скажем есть task1, которая считывает данные из порта и заносит в буфер A. Есть task2, которая обрабатывает данные в буфере B. И есть task3, которая берет готовые данные из буфера C выпихивает их в выходной порт. Так вот при наступлении следующего такта просто происходит циклическая смена указателей. task1 начинает писать в C, task2 обрабатывает данные в А, а task3 берет данные из B. На следующем такте очередная смена буферов. И так далее. Ничего не выделяется, ничего не освобождается.
И еще по поводу использования динамически выделяемой/освобождаемой памяти в задачах реального времени. На знаю, как ситуация будет обстоять сейчас, с развитием lock-free алгоритмов, но раньше вызов malloc/free (new/delete) блокировал mutex. И если нить с низким приоритетом (например, 1) вошла в new, а здесь случилось прерывание, которое запустило нить с более высоким приоритетом (например, 3), то при попытке нити с высоким приоритетом войти в new получится так, что нить с приоритетом 3 будет заблокирована и будет ждать освобождения нити 1. Но тут может вступить в дело нить с приоритетом 2. И пока она не завершится нить с приоритетом 1 не продолжит свою работу. А значит и не продолжит свою работу нить 3. И получится ситуация, которая в задачах реального времени просто недопустима: нить с приоритетом 3, запущенная перед нитью с приоритетом 2 не сможет работать, пока не завершится нить с приоритетом 2. А ведь ОСРВ как раз отличаются от ОС общего назначения тем, что они очень строго гарантируют приоритетность задач и очень малое время переключения на задачи с более высокими приоритетами. И вот в такую тонкую кухню запустить GC, который живет по свои законам и, мягко говоря, плюет на весь остальной процесс и его приоритеты?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?
Моя работа почти целиком связана с разработкой встраиваемого ПО реального времени. И мне важно, чтобы одна или несколько задач начинали выполняться "не позднее чем" и вовремя завершались. Скорость здесь имеет к теме лишь косвенное отношение.
Разработка встраиваемого ПО для систем реального времени (не путать с ОСРВ!) на языке типа Java -- можно сказать, мечта последних нескольких лет. Хотя ни один из распространенных языков, к сожалению, не позволяет решить главной проблемы в такого рода проектах -- проблемы сложности. Между прочим, думаю, не лишен интереса самый первый из всех JSR в Java Community Process: http://www.rtsj.org/rtj_org_mirror/rtsj-V1.0.pdf). Там можно посмотреть, как может быть устроена такого рода система.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>Да, нет. С++ это всегда танцы с бубном.
Ш>>Не забывай добавлять -- "у меня".
VD>У тебя, у тебя.
Здравствуйте, Шахтер, Вы писали:
AF>> Нет конечно. Но речь то изначально шла не о том, чего больше, ПК или АЭС, а о том, что есть другие области, чем написание бизнес софта для ПК, в которых используются совершенно другие подходы. AF>> Кстати, если чуть-чуть подумать, то восторг от того, что в россии пишется преимущественно софт под Windows или в крайнем случае Linux/FreeBSD, быстро проходит, а в замен приходят мысли о месте негров в мировом разделении труда и том, чем это закончится для оных негров.
Ш>Ну, на самом деле, это не только в России. Естественно, наибольший сегмент рынка по числу особенно мелких приложений -- это бизнес-программирование.
И то правда. Ш>Но должен заметить, что в России делают и передовые разработки. Так что не всё так плохо.
Делают. И это вселяет оптимизм. Вопрос лишь в отношении числа этих разработок к числу разработок под обычные ПК. По-моему оно таки уступает тому что есть на западе.
Спасибо за линки.
AL>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?
AL>VladD2, конечно, несколько эмоционален. Но абсолютно прав по сути. Вместо википедии предлагаю посмотреть классиков типа Таненбаума и Станковича (http://www.ece.cmu.edu/~ece749/docs/rtEmbSysSurvey-Stankovic.pdf).
Согласен, о чём неоднократно и писал. Только обратите внимание, о том контексте, в котором классики рассматривают СРВ. Речь идёт о достаточно крупных системах, в которых есть запас вычислительных ресурсов.
AL>Моя работа почти целиком связана с разработкой встраиваемого ПО реального времени. И мне важно, чтобы одна или несколько задач начинали выполняться "не позднее чем" и вовремя завершались. Скорость здесь имеет к теме лишь косвенное отношение.
Опять таки согласен. Вам нужно обеспечить гарантированное время отклика. И скорость здесь вторична. Правда до тех пор, пока ресурсов системы хватает для того, что бы у вас был выбор, как обеспечивать это время отклика. Честно говоря у меня сложилось впечатление, что системы о которых вы говорите работают с реальным временем, порядка сотен микросекунд и более, при не очень большом объёме вычислений. А вам, конечно, хорошо знакомо, какая огромная разница обеспечить время отклика в миллисекунды или в микросекудны. Классики главным образом пишут о временах реакции от сотен микросекунд (0.1 мс) и выше, но зато в системах с очень сложной логикой. Но ведь это далеко не все СРВ.
Ясть СРВ сложные — где главное — борьба со сложностью, тут вы совершенно правы относительно возможностей и подходов (например системы управления промышленными объектами), а есть СРВ быстрые — где главное любой ценой уложиться по времени (например сетевые концентраторы и т.п.).
В случае сложных СРВ (о которых в основном и пишут классики) у ЯВУ, даже высокоуровневых, таких как Оберон, Java или функциональные языки — может быть и есть вполне успешное применение.
AL>Разработка встраиваемого ПО для систем реального времени (не путать с ОСРВ!) на языке типа Java -- можно сказать, мечта последних нескольких лет. Хотя ни один из распространенных языков, к сожалению, не позволяет решить главной проблемы в такого рода проектах -- проблемы сложности. Между прочим, думаю, не лишен интереса самый первый из всех JSR в Java Community Process: http://www.rtsj.org/rtj_org_mirror/rtsj-V1.0.pdf). Там можно посмотреть, как может быть устроена такого рода система.
Согласен. И даже объяснил почему. Однако есть различие между является мечтой и является основной практикой. В высказывании Влада было несколько посылов, в частности и такой — что применение C++ обусловлено кривизной рук тех, кто не умеет применять что-то другое. На мой взгляд это совершенно неверный посыл. Об этом хорошо написал Евгений здесь
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Имеет Влад и самое прямое. Если реальное время "достаточно жёсткое", то есть гарантированное время отклика близо ко времени решения задачи (притом не любым, а оптимальным или близим к нему образом), то произоводительность имеет критическое значение.
VD>Производительность должна быть достаточной. Ну, а повторяться не охота.
Достаточной для чего? Для того, что бы по времени на пределе вписать вылизанный и оптимизированный на всех возможных уровнях алгоритм или что бы успела отработать сделанная задней ногой криворукая реализация?
AF>> Самое прямое. Ты же не станешь отрицать, что любой алгоритм сборщика мусора — потенциально (с точки зрения математики) медленнее, чем алгоритм работы с кучей (вырожденные или специально подобранные случаи вроде очень хорошо написанного первого и очень плохо написанного второго я не рассматриваю)?
VD>Стану. Хип из большинства ОС откровенно проигрывает ЖЦ на объектах малого размера.
И по какому параметру?
VD>Ну, и к теме СРВ это не имеет ни малейшего отношения. Там важно отсуствие непредсказуемых задержек. Вот тут ЖУ сложнее. Но есть специальные версии ЖЦ которые гарантируют определенное время сборки мусора.
Совершенно верно. Есть. Но нет тех, у которых это время статистически меньше — чем у кучи. Есть лишь системы, где это не важно — т.е. где есть запас ресурсов.
AF>> Причём медленнее по банально простой причине — сборщику мусора приходится анализировать запутанные связи в программе во время выполнения, в то время как в куче эти связи приходится учитывать и оптимизировать разработчику — ещё в Design Time.
VD>Real-time GC
Спасибо за ссылку.
VD>Большинство же релализаций CRT-куч (и им подобных) основано на связанных списках и дают нехилые (и гланое не предсказуемые) задержки при фрагментации кучи.
Ровно тоже самое относится к GC, с той только разницей, что тут не возможно предсказать не только время задержки, но и момент, когда она случится. Кроме того, алгоритмов кучи для СРВ с гарантированным временем думаю уж никак не меньше, чем алгоритмов GC
VD>Для особо непонятливых — это был сарказм.
Вывернулся!
AF>>Да, я понимаю, что извернувшись через одно (или несколько мест), можно программировать для RT-OS даже на BASIC.
VD>Почему даже? Чем он хуже других?
AF>> Вот только зачем?
VD>Например, чтобы уменьшить количество ошибок и время отладки.
Влад и это был бы твой выбор для СРВ? Ты думаешь что основная сложность там в ловле ошибок в простеньком коде?
VD>Подобные заявления обычно присущи представителям другого языка.
VD>Вопрос, что считать удобством при решении задачи? Выбр более низкоуровневого языка — это не выбор более удобного решения. Это выбор самого легкодоступного решения которое потом приведет у более сложной разработке. Именно по этому ребята из Сана и занимаются разработкой ЯваРВ, а разные телекомуникационные компании даже используют динамически типизированные функциональные языки.
VD>Да, нет. С++ это всегда танцы с бубном.
AF>>Для СРВ лучшим выбором может быть даже не C++, а C, Pascal или даже, в некоторых случаях, ассемблер. У если не то пошло — то лучшим, чем C# или Java выбором для них будет ужастный Оберон!
VD>Выбор ассемблера может быть оправдан только очень ограниченными возможностями аппаратной платформы или отсуствием компиляторов. Сдается мне, что выбор С/С++ должен вестись по тем же принципам.
AF>>Потому то именно на нём, а не C# или Java пишут системы управления критичными объектами.
VD>Не смешите меня. Когда речь идет о чем-то ктитическом, то С/С++ выбирают или от безысходности, или явные фанатики.
Влад, я вообще не фанат того или иного языка. Мне лично ближе C++, но подозреваю, что писать можно и нужно на языке, наиболее оптимальном для решения задачи. Кстати я неоднократно писал о самых разных языках, применяемых в СРВ, включая функциональные языки и даже Оберон.
Кстати некоторые производители компиляторов так и выпускают "C++" без шаблонов или инлайн-функций — ведь всё равно клиенты ими не пользуются! 
