Здравствуйте, VladD2, Вы писали:

C>>3. Скорость, скорость, скорость.

VD>Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.

Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

Здравствуйте, AndreyFedotov, Вы писали:

AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

Ты сам лично много написал программ для таких ОС?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

IT>Ты сам лично много написал программ для таких ОС?

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

IT>Ты сам лично много написал программ для таких ОС?

А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"

Здравствуйте, eao197, Вы писали:

E>А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, eao197, Вы писали:

E>>А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"

IT>Как раз ничего личного. Просто мне интересно и более важно мнение людей, которые лично делали то о чём говорят, а не просто теоретизируют на заданную тему.

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

Здравствуйте, AndreyFedotov, Вы писали:

AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

Тут есть только два вопроса.
1. Ты новсти читашь? Тогда почитай вот эту http://www.zdnet.ru/?ID=494076
2. Какое отношение имеет ОС реального времени к бредовым заявлениям о скорости постоянно звучащих на этом форуме? Они все о рельном времени? А почему в качестве примера все время наровят игрушки привести? А ведь нет никаких проблем скачать и движок на шарпе сделанный и игрушку... и позапускать тесты / поиграть.

Здравствуйте, eao197, Вы писали:

E>А, теперь понятно. Да, действительно, их мнение весомее. Но сам факт существования ОС реального времени, имхо, уже доказывает необходимость задач, где скорость очень важна.

Не сочти за переход на твою личноть, но ты сам то подумал что сказал? Какое отношение скорость имеет к требованиям реального времени? В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>А, теперь понятно. Да, действительно, их мнение весомее. Но сам факт существования ОС реального времени, имхо, уже доказывает необходимость задач, где скорость очень важна.

VD>Не сочти за переход на твою личноть, но ты сам то подумал что сказал? Какое отношение скорость имеет к требованиям реального времени?

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

VD> В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.

Видел я Sun-овские извраты в j2me на STK-шных SIM-картах. Когда размер стека всего 256 байт и никакого GC в принципе. И некоторые C/C++ программисты, которые пытались в этом деле программировать плевались жутко и говорили -- дайте нам обычный C и все станет на порядок проще. И глядя на исходники STK аплетов я с ними соглашался.

Здравствуйте, eao197, Вы писали:

E>Самое прямое. Без приличной скорости жестких требований по предсказуемости и времени отклика не удовлетворить.

Значит не подумал. Характеристикам реального времени удовлетворяли досисторические процессоры.

Ладно обратимся опять к википедии.

http://en.wikipedia.org/wiki/Realtime

An operation within a larger dynamic system is called a real-time operation if the combined reaction- and operation-time of a task is shorter than the maximum delay that is allowed, in view of circumstances outside the operation. The task must also occur before the system to be controlled becomes unstable. A real-time operation is not necessarily fast, as slow systems can allow slow real-time operations. This applies for all types of dynamically changing systems. The polar opposite of a real-time operation is a batch job with interactive timesharing falling somewhere in-between the two extremes.

В общем, как я понимаю, ты просто не понимашь сути термина которым оперируешь.

E>В нормальных задачах реального времени,

О, как! У нас появился еще один термин "нормальные задачи реального времени".

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

Когда заранее? А если алгоритм требует постоянно занимать и освобождать память? А вот это народ о чем говорит: real-time heap?

E> при раскручивании системы. Более того, часто эта память выделяется не через new, а в виде статических глобальных массивов.

Зашибись. Значит на любом ЖЦ можно писать real-time-системы, так как на любом ЖЦ можно не знаимать память во время работы. Займи себе все чт нужно при раскрутке системы и никаких сборк мусора не будет.

Бред? Несомненно...

VD>> В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.

E>Видел я Sun-овские извраты в j2me на STK-шных SIM-картах.


E> Когда размер стека всего 256 байт и никакого GC в принципе.

Можно узнать когда? Ты на дату новости глянь.

E>И некоторые C/C++ программисты, которые пытались в этом деле программировать плевались жутко и говорили -- дайте нам обычный C и все станет на порядок проще. И глядя на исходники STK аплетов я с ними соглашался.

Плющихся во все стороны и орущих "дайте мне xxx, а ваш yyy дерьмо" я видел очень много. В 99% случаев оказывалось, что проблема была в яйцах танцоров.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.

VD>Тут есть только два вопроса.
VD>1. Ты новсти читашь? Тогда почитай вот эту http://www.zdnet.ru/?ID=494076
VD>2. Какое отношение имеет ОС реального времени к бредовым заявлениям о скорости постоянно звучащих на этом форуме? Они все о рельном времени? А почему в качестве примера все время наровят игрушки привести? А ведь нет никаких проблем скачать и движок на шарпе сделанный и игрушку... и позапускать тесты / поиграть.

Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?
Ты знаешь, что именно сделала Sun, что бы можно было писать на Java для ОС реального времени? Поинтересуйся. Там GC даже близко не стоял — как только требуется жёсткое реальное время, или используется, но ценой больших затрат на зачистку памяти — что бы гарантировать заданное время отклика. Это уже не совсем Java и методы программирования там скорее напоминают C++, притом при фиксированном распределении памяти.
Sun сделала JavaRT не потому, что Java это лучший язык для OS-RT, а, отчасти, для того, что бы отхватить часть рынка, но главным образом не от хорошей жизни. Программистов на Java на западе пруд пруди и стоят они относительно дёшево. Программистов на C++ гораздо меньше, а тех, кто в состоянии писать для OS-RT — совсем мало и стоят они очень дорого. Потому есть прямой экономический смысл сделать Java, который приспособлен для OS-RT, что бы облегчить переход Javaистов к программированию под эти ОС, а заодно использовать часть подходящих и хорошо уже знакомых Javaистам библиотек.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Самое прямое. Без приличной скорости жестких требований по предсказуемости и времени отклика не удовлетворить.

VD>Значит не подумал. Характеристикам реального времени удовлетворяли досисторические процессоры.
VD>....
VD>В общем, как я понимаю, ты просто не понимашь сути термина которым оперируешь.
Влад, не передёргивай. Я более, чем уверен, что Евгений понимает суть систем РВ так же хорошо как и ты. А разводить демогогию вокруг того, что раз система реального времени должна иметь время отклика не более чем или фиксированное, то давайте поставим время отклика час и тогда у нас все системы будут ОС-РВ, не стоит. Это и так очевидно.

E>>В нормальных задачах реального времени,
VD>О, как! У нас появился еще один термин "нормальные задачи реального времени".
На большее чем прицепиться к словам терпения не хватило?
Как не странно речь идёт о задачах, реализация выполнения которых для ОС-РВ потребует хорошо подумать, что бы вписаться в те временные рамки, за которые должен быть получен отклик.

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

VD>Когда заранее? А если алгоритм требует постоянно занимать и освобождать память? А вот это народ о чем говорит: real-time heap?

Всё это хорошо тогда, когда у тебя есть хотя бы 20-30% свободных временных ресурсов для работы. А их часто просто нет. Кроме того, приведённый алгоритм несчадно жрёт память. А её тоже может не быть

E>> при раскручивании системы. Более того, часто эта память выделяется не через new, а в виде статических глобальных массивов.

VD>Зашибись. Значит на любом ЖЦ можно писать real-time-системы, так как на любом ЖЦ можно не знаимать память во время работы. Займи себе все чт нужно при раскрутке системы и никаких сборк мусора не будет.

VD>Бред? Несомненно...

А зачем тогда сборщик мусора? И какой прок от языков, построенных вокруг него? Он просто превращается в ненужный рудимент.
В системах жёсткого реального времени могут быть опасны даже такие фичи C++ как dynamic_cast — так как последний требует линейного времени работы (в зависимости от глубины типов), что явным образом не видно.

VD>>> В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.

E>>И некоторые C/C++ программисты, которые пытались в этом деле программировать плевались жутко и говорили -- дайте нам обычный C и все станет на порядок проще. И глядя на исходники STK аплетов я с ними соглашался.

VD>Плющихся во все стороны и орущих "дайте мне xxx, а ваш yyy дерьмо" я видел очень много. В 99% случаев оказывалось, что проблема была в яйцах танцоров.

Да, понятно что и на одной ноге можно мастерски научиться танцевать при желании. Только вот зачем?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Самое прямое. Без приличной скорости жестких требований по предсказуемости и времени отклика не удовлетворить.

VD>Значит не подумал. Характеристикам реального времени удовлетворяли досисторические процессоры.

Знаешь, Влад, а ведь даже редактор, который ты переписываешь для Януса, так же можно считать real-time системой, т.к. результат работы в нем появляется прямо в реальном времени, без задержек и отсрочек. Но ведь это же не то, о чем идет речь в данной ветке. И уж совсем точно ты не обратил внимания на фразу "жестких требований".

VD>Ладно обратимся опять к википедии.

Ты все сведения черпаешь из википедии? А "википедия" -- это что, признаный авторитетный источник? Типа Большой Совецкой Энциклопедии?

VD>В общем, как я понимаю, ты просто не понимашь сути термина которым оперируешь.

Конечно, сапожник всегда без сапог ходит. Я шесть лет проработал в КБ, основной специализацией которого были системы реального времени (как военного, так и гражданского назначения (АСУТП и ИИС)). Задачами жесткого реального времени, правда, заниматься не пришлось. Но наслышан.

Так вот, касаясь википедии. Мне сложно судить, насколько она качественно написана в разделах о реальном времени. Но если ты черпаешь знания о реальном времени из википедии, то остается вопросить "А судьи кто?". Что-то мне не кажется, что ты компетентен в данных вопросах.

E>>В нормальных задачах реального времени,

VD>О, как! У нас появился еще один термин "нормальные задачи реального времени".

Под нормальными задачами реального времени я понимал задачи с временами, измеряемыми единицами миллисекунд. Это как раз задачи, которыми занимаются специализирующиеся на этом фирмы и организации, как говорится, собаку съевшие на этом деле. Причем даже задачи с темпом в 10-20 миллисекунд могут оказаться задачами очень жесткого времени, если в один квант придется впихнуть много вычислений и/или операций ввода вывода. А ведь бывает, что темп работы измеряется микросекундами.

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

VD>Когда заранее? А если алгоритм требует постоянно занимать и освобождать память? А вот это народ о чем говорит: real-time heap?

Понятия не имею о чем кто и чего говорит. Я лично говорю о том, что видел и с чем работал. Алгоритмы с new/delete и динамическим перераспределением памяти идут лесом, да еще и со срашной силой. Вся память выделяется заранее в виде пулов или цепочек буферов. И все что требуется при дальнейшей работе -- это просто циклически переназначать указатель на текущий буфер.

E>> при раскручивании системы. Более того, часто эта память выделяется не через new, а в виде статических глобальных массивов.

VD>Зашибись. Значит на любом ЖЦ можно писать real-time-системы, так как на любом ЖЦ можно не знаимать память во время работы. Займи себе все чт нужно при раскрутке системы и никаких сборк мусора не будет.

VD>Бред? Несомненно...

Хочется особо подчеркнуть, что этот бред был написан тобой. И я совершенно не понимаю, откуда ты его вывел.

И если тебе так уж нравится читать википедию, то прочти вот это: http://en.wikipedia.org/wiki/Real-time_operating_system
Особенно раздел Memory allocation

Memory allocation is even more critical in a RTOS than in other operating systems.

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.

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.

The simple fixed-size-blocks algorithm works astonishingly well for simple embedded systems.

Что-то здесь про GC ни сном, ни духом.

VD>>> В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.

E>>Видел я Sun-овские извраты в j2me на STK-шных SIM-картах.
E>> Когда размер стека всего 256 байт и никакого GC в принципе.

VD>Можно узнать когда? Ты на дату новости глянь.

Последние 4-ре года. Коллеги по работе каждый день парятся, когда пытаются впихнуть апплет на карту в 32K, из которых мы имеем право занять не более половины. А покупать карты хотя бы 64K операторы пока не сильно торопятся.

E>>И некоторые C/C++ программисты, которые пытались в этом деле программировать плевались жутко и говорили -- дайте нам обычный C и все станет на порядок проще. И глядя на исходники STK аплетов я с ними соглашался.

VD>Плющихся во все стороны и орущих "дайте мне xxx, а ваш yyy дерьмо" я видел очень много. В 99% случаев оказывалось, что проблема была в яйцах танцоров.

Я тоже, а форумах RSDN, как и на любых других, это вообще не редкость. Но в данном случае я знаю о чем говорю. И знаю людей, которые жаловались на STK-шную Java. И мне самому приходилось некоторые фрагменты STK апплетов анализировать и править. Поэтому могу утверждать, что на малых объемах памяти и слабых вычислительных ресурсах Java -- это лажа полная. Голый C, не говоря уже про ассемблер, уделает ее под орех. Как по удобству использования, так и по компантности результирующего кода.

Здравствуйте, AndreyFedotov, Вы писали:

VD>>В общем, как я понимаю, ты просто не понимашь сути термина которым оперируешь.
AF> Влад, не передёргивай. Я более, чем уверен, что Евгений понимает суть систем РВ так же хорошо как и ты. А разводить демогогию вокруг того, что раз система реального времени должна иметь время отклика не более чем или фиксированное, то давайте поставим время отклика час и тогда у нас все системы будут ОС-РВ, не стоит. Это и так очевидно.

Демагогию тут разводит кто-то другой. Я же замети только то, что вопрос скорости к вопросу о системах реального времени не имеет. Это разные вещи. Именно по этому приводить СРВ в качестве аргумента в разговоре о скорости управляемого кода является той самой демагогией.

E>>>В нормальных задачах реального времени,
VD>>О, как! У нас появился еще один термин "нормальные задачи реального времени".
AF>На большее чем прицепиться к словам терпения не хватило?

Не просто радуюсь с примеров той самой... Вместо аргументов "громкие слова".

AF>Всё это хорошо тогда, когда у тебя есть хотя бы 20-30% свободных временных ресурсов для работы. А их часто просто нет. Кроме того, приведённый алгоритм несчадно жрёт память. А её тоже может не быть

Всего может не быть. Но какое это отношение имеет к ЖЦ?

AF> А зачем тогда сборщик мусора? И какой прок от языков, построенных вокруг него?

Это ко мне вопросы? Это же не я говрю о том что в СВР память нельзя занимать?

AF> Он просто превращается в ненужный рудимент.

Это без разницы. Главно, что его никак нельзя привратить в контраргумент при таких условиях.

AF> В системах жёсткого реального времени могут быть опасны даже такие фичи C++ как dynamic_cast — так как последний требует линейного времени работы (в зависимости от глубины типов), что явным образом не видно.

Жить вообще опасно.

AF>Да, понятно что и на одной ноге можно мастерски научиться танцевать при желании. Только вот зачем?

Вот и меня это интересует. Давай спросим об этом у поклонников С++.

Здравствуйте, AndreyFedotov, Вы писали:


AF> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?

Писал, под ДОС. А ты на JavaRT?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndreyFedotov, Вы писали:


AF>> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?

VD>Писал, под ДОС. А ты на JavaRT?

На JavaRT писать не приходилось. Зато приходилось иметь дело с 8, 16 и 32 битными контроллерами, а так же кучей DSP. Так там, если задача критичная (по отношению требуемое для её решения времени к гарнтированному времени отклика), неудобен был даже C++, Проще и лучше было писать на C, а в некоторых случаях на ассемблере. Поскольку подобных экспериментов с каждым из этих языков было проделано множество и не только мной — опыт достаточно хороший для того, что бы на его основе делать выводы про переспективы применения в данных областях той или иной технологии. Так вот JavaRT там как корове ярмо — по тем же причинам, по которым там частенько выступал в таком же качестве C++.

Здравствуйте, VladD2, Вы писали:

VD>Демагогию тут разводит кто-то другой. Я же замети только то, что вопрос скорости к вопросу о системах реального времени не имеет. Это разные вещи. Именно по этому приводить СРВ в качестве аргумента в разговоре о скорости управляемого кода является той самой демагогией.

Имеет Влад и самое прямое. Если реальное время "достаточно жёсткое", то есть гарантированное время отклика близо ко времени решения задачи (притом не любым, а оптимальным или близим к нему образом), то произоводительность имеет критическое значение.

AF>>Всё это хорошо тогда, когда у тебя есть хотя бы 20-30% свободных временных ресурсов для работы. А их часто просто нет. Кроме того, приведённый алгоритм несчадно жрёт память. А её тоже может не быть

VD>Всего может не быть. Но какое это отношение имеет к ЖЦ?

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

AF>> А зачем тогда сборщик мусора? И какой прок от языков, построенных вокруг него?
VD>Это ко мне вопросы? Это же не я говрю о том что в СВР память нельзя занимать?
AF>> Он просто превращается в ненужный рудимент.
VD>Это без разницы. Главно, что его никак нельзя привратить в контраргумент при таких условиях.

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

AF>> В системах жёсткого реального времени могут быть опасны даже такие фичи C++ как dynamic_cast — так как последний требует линейного времени работы (в зависимости от глубины типов), что явным образом не видно.

VD>Жить вообще опасно.

Гениальный ответ! Якрий, красивый, интересный, мудрый... И абсолютно не относящийся к сути дела.
Да, я понимаю, что извернувшись через одно (или несколько мест), можно программировать для RT-OS даже на BASIC. Вот только зачем? Что бы фанатично заявить что Basic самый крутой язык программирования? Или же всё-таки стоит выбрать более удобные в данном контексте средства для решения данной задачи?

AF>>Да, понятно что и на одной ноге можно мастерски научиться танцевать при желании. Только вот зачем?

VD>Вот и меня это интересует. Давай спросим об этом у поклонников С++.

Подозреваю, что применительно к OS-RT придётся спрашивать у поклонников C# и Java.
Для СРВ лучшим выбором может быть даже не C++, а C, Pascal или даже, в некоторых случаях, ассемблер. У если не то пошло — то лучшим, чем C# или Java выбором для них будет ужастный Оберон!
Потому то именно на нём, а не C# или Java пишут системы управления критичными объектами.

Здравствуйте, VladD2, Вы писали:

VD>Плющихся во все стороны и орущих "дайте мне xxx, а ваш yyy дерьмо" я видел очень много. В 99% случаев оказывалось, что проблема была в яйцах танцоров.

Чертовски кстати неплохое замечание ! Я точно на этом форуме парочку таких встречал .

Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, AndreyFedotov, Вы писали:


AF>>> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?

VD>>Писал, под ДОС. А ты на JavaRT?

AF> На JavaRT писать не приходилось. Зато приходилось иметь дело с 8, 16 и 32 битными контроллерами, а так же кучей DSP. Так там, если задача критичная (по отношению требуемое для её решения времени к гарнтированному времени отклика), неудобен был даже C++, Проще и лучше было писать на C, а в некоторых случаях на ассемблере.

Вот тут ты не совсем прав. На самом деле С++ в любом случае предпочтительней. Даже начальные фичи типа пространств имен, инлайн-функций, более строгий контроль типов и.т.п очень сильно помогают по сравнению с голым C. Просто не надо использовать тех фич языка, которые не адекватны задаче.
А, кроме того, кроме execution plane всегда ведь присутствует control plane, и здесь, объектно-ориентированные свойства языка значительно упрощают жизнь. А в execution plane, там где нужно выжимать скорость можно писать в чисто процедурном стиле.
Что касается ассемблера -- реально при современном качестве оптимизаторв он в большинстве случаев не нужен.
Он реально нужен только для решения ряда очень специальных задач, ну, например, реализация семафоров требует прямого использования команд процессора для атомарного чтения.записи. В моей практике был только один случай полномасштабного использования ассемблера -- но это был сверхжесткий real-time.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Когда я писал о C++ я не ставил себе целью утвержать или тем более доказывать, что C++ менее предпочтителен или не подходит для RTOS. Тем более, что в большинстве случаев для RTOS именно он и используется. Моей целью было продемонстировать, что даже применение такого, предсказуемого и близкого к аппаратуре языка как C++ может мешать и вызывать проблемы в RTOS — особенно в RTOS жёсткого реального времени. Что тем более делает сомнительным полезность применения там более абстрагированных и высокоуровневых (а следовательно ещё менее предсказуемых) языков — таких как Java или C#.
Я видел несколько разных ситуаций связанных с RTOS, отличавшихся весьма различными условиями и требованиями, что обуславливало различные (иногда диаметрально противоположные) подходы и философию, соответственно делались совершенно различные выводы о полезности и применимости тех или иных средств — в частности языков программирования.

Вариант "что нам стоит дом построить". Это те ситуации, когда вычислительные ресурсы значительно превосходят то, что требуется для решения поставленных задач в заданные интервалы времени или достаточно просто вписать решение задачи в заданный интервал. Эта ситуация может, в принципе встречаться на какой угодно аппаратуре — как медленном микроконтроллере, которому нужно выдать реакцию — произведение трёх 32 битных чисел раз в 0,5 секунды, так и в сверх-навороченном мультипроцессорном блоке, которому нужно выдать реакцию за доли миллисекунды — главное — что на самом деле и там и там задача решается гораздо быстрее, чем это необходимо, и есть значительный запас времени для её решения.
Такая ситуация на практике возникает как правило в полномаштабных OSRT вроде QNX (или оберон системах). Например в системах управления особо важными или опасными промышленными объектами, вроде хранилищ топлива или ядерных объектов, таких как АЭС. На них главное — это надёжность системы, а не её производительность или эффективность. И в здравом уме никто не станет устанавливать медленную систему, рискуя в какой-то ситуации нарваться на нехватку ресурсов на подобном объекте. Наоборот, даже сертифицировав систему на более медленном оборудовании, всегда есть тенденция использовать более быстрое — так, на всякий случай.
Так же это наблюдается в промышленное железе на основе 32 битных контроллеров. Там часто ресурсов такого процессора в разы больше, чем требуется для решения поставленных задач.
Кроме того, обычно такие системы довольно велики по объёму и обладают довольно сложной логикой. Это и определяет подход к ним. Тут используются очень многие идеи, подходы и приёмы программирования обычных Windows или Linux/UNIX систем. Правда поскольку это всё-таки RTOS — приходится их применять гораздо аккуратнее, чем это было бы в аналогичной Windows системе — например следить за теми скрытыми эффектами (вроде времени поиска при приведении типов, времянки new/delete), которые возникают при применении той или иной конструкции языка. Соотвтественно в этих системах наиболее полезными оказываются ООП языки тот же C++ или Оберон. Первый по вполне понятным причинам, а второй благодая его изначальной ориентированности на построение и использование в подобных системах — в частности реализациями сборки мусора ориентированной именно на RTOS — с гарантированным временем работы (что в данном случае очень важно). Подозреваю, что в подобных системах займёт со временем достойное место и JavaRT.
Ш>Вот тут ты не совсем прав. На самом деле С++ в любом случае предпочтительней. Даже начальные фичи типа пространств имен, инлайн-функций, более строгий контроль типов и.т.п очень сильно помогают по сравнению с голым C. Просто не надо использовать тех фич языка, которые не адекватны задаче.
Ш>А, кроме того, кроме execution plane всегда ведь присутствует control plane, и здесь, объектно-ориентированные свойства языка значительно упрощают жизнь. А в execution plane, там где нужно выжимать скорость можно писать в чисто процедурном стиле.
Ш>Что касается ассемблера -- реально при современном качестве оптимизаторв он в большинстве случаев не нужен.
Ш>Он реально нужен только для решения ряда очень специальных задач, ну, например, реализация семафоров требует прямого использования команд процессора для атомарного чтения.записи. В моей практике был только один случай полномасштабного использования ассемблера -- но это был сверхжесткий real-time.
Потому в контексте данных систем полностью согласен с вышесказанным. За исключением ядра ОС (и то частично), драйверов или библиотек для интенсивных расчётов (часто поточных и использующих спец аппаратуру), которые, обычно, реализуются на ассемблере или Си, — C++ (или аналогичный ООП ЯВУ) будет очень эффективным и оправданным выбором.
От себя добавлю, что если речь идёт о проектах, вроде софта для АЭС — то там так же используются собственные компиляторы, чьё поведение известно и полностью предсказуемо. Для таких систем характерны штучный или мелкосерийный характер производства и огромная стоимость, потому можно себе многое возволить.

Вариант "Да ктож ему столько даст". Это так ситуация, когда вычислительные ресурсы лишь не намного превосходят потребности решаемых задач. То есть запас по времени очень не большой. Типичным примером являются телекоммуникационные системы. Здесь стоимость оборудования играет гораздо более высокую роль, чем для систем управления АЭС или аэропортами, а объёмы производства гораздо выше. Потому ставить оборудование с большим запасом по производительности не рентабельно. В этих условиях софт обычно проще, чем для систем управления АЭС, с точки зрения его логики, но зато возникает ряд других проблем.
Обычно используются компиляторы и инструментарий сторонних производителей. Очень часто это производители железа, поставляющие со своим железом так же компиляторы ЯВУ. Беда в том, что вы не можете наверняка знать, как ведёт себя компилятор. Более того, многие из этих компиляторов весьма здорово отличаются от стандарта (и не в лучшую сторону).
Потому часто работа начинается с детального исследования своиств комилятора. Но и этого мало! Качество компиляторов не особенно высокое и часто оказывается, что в них есть ошибки, иногда достаточно критичные. И вот тут то начинается самое веселье! Вы вынуждены переходить на новую версию компилятора — в середине, а то и в конце проекта и тут выясняется, что вместе с поправленной ошибкой — производетель компилятора переколбасил половину кодогенерации! Что-то у вас было inline — и вдруг перестало! А всё потому, что обнаружив, что inline функции реализованы неверно, производитель компялятора их вообще убрал! И это совершенно реальный случай. И далеко не единственный.
В таких условиях использование любого ЯВУ, со скрытыми фичами — вроде C++ может являть собой огромный риск для всего проекта. Потому в таких случаях предпочитают использовать C, Pascal или уж если и использовать C++, но в режиме процедурного программирования, притом аккуратно отслеживая, что бы не допустить ни в коем случае какую либо из столь полезных фич. Обычно такое использование напоминает C with classes гораздо больше, чем C++. Кстати некоторые производители компиляторов так и выпускают "C++" без шаблонов или инлайн-функций — ведь всё равно клиенты ими не пользуются!

Вариант "впихиваем невпихуемое". Это ситуация когда аппаратные ресурсы используются близко к абсолютному максимуму. Это и есть то самое сверх-жёсткое реальное время. Тут счёт идёт на такты. О языках вроде C++ речи даже близко не идёт. Значительная (иногда большая) часть кода написана на ассемблере, остальное — C или Pascal