Здравствуйте, VladD2, Вы писали:
C>>3. Скорость, скорость, скорость.
VD>Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
Ты сам лично много написал программ для таких ОС?
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
IT>Ты сам лично много написал программ для таких ОС?
Писал немного для QNX. И увы, что не много. Просто буржуи подобные проекты сюда дают неохотно, а наши ими почти не занимаются...
Но потребность то всё равно остаётся...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
IT>Ты сам лично много написал программ для таких ОС?
А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"
Как раз ничего личного. Просто мне интересно и более важно мнение людей, которые лично делали то о чём говорят, а не просто теоретизируют на заданную тему.
... << RSDN@Home 1.1.4 stable rev. 510>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"
IT>Как раз ничего личного. Просто мне интересно и более важно мнение людей, которые лично делали то о чём говорят, а не просто теоретизируют на заданную тему.
А, теперь понятно. Да, действительно, их мнение весомее. Но сам факт существования ОС реального времени, имхо, уже доказывает необходимость задач, где скорость очень важна.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
Тут есть только два вопроса.
1. Ты новсти читашь? Тогда почитай вот эту http://www.zdnet.ru/?ID=494076
2. Какое отношение имеет ОС реального времени к бредовым заявлениям о скорости постоянно звучащих на этом форуме? Они все о рельном времени? А почему в качестве примера все время наровят игрушки привести? А ведь нет никаких проблем скачать и движок на шарпе сделанный и игрушку... и позапускать тесты / поиграть.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А, теперь понятно. Да, действительно, их мнение весомее. Но сам факт существования ОС реального времени, имхо, уже доказывает необходимость задач, где скорость очень важна.
Не сочти за переход на твою личноть, но ты сам то подумал что сказал? Какое отношение скорость имеет к требованиям реального времени? В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.
Итого подитожим. Слова про скорость явная чушь. Слова про реалтамй просто попытка прикрыть эту чушь уйдя в сторону.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А, теперь понятно. Да, действительно, их мнение весомее. Но сам факт существования ОС реального времени, имхо, уже доказывает необходимость задач, где скорость очень важна.
VD>Не сочти за переход на твою личноть, но ты сам то подумал что сказал? Какое отношение скорость имеет к требованиям реального времени?
Самое прямое. Без приличной скорости жестких требований по предсказуемости и времени отклика не удовлетворить.
В нормальных задачах реального времени, не говоря уже о жестком реальном времени, вообще нет работы с динамической памяти -- все что нужно для работы выделяется заранее, при раскручивании системы. Более того, часто эта память выделяется не через new, а в виде статических глобальных массивов.
VD> В реалтайм ОС важна не скорость, а предсказуемость. И хотя тут многие думают, что ЖЦ не совместим с реальным временим, но вот тот же Сан думет по другому: http://www.zdnet.ru/?ID=494076 и не только он, что характерно.
Видел я Sun-овские извраты в j2me на STK-шных SIM-картах. Когда размер стека всего 256 байт и никакого GC в принципе. И некоторые C/C++ программисты, которые пытались в этом деле программировать плевались жутко и говорили -- дайте нам обычный C и все станет на порядок проще. И глядя на исходники STK аплетов я с ними соглашался.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
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% случаев оказывалось, что проблема была в яйцах танцоров.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>Бред? Несомненно...
Хочется особо подчеркнуть, что этот бред был написан тобой. И я совершенно не понимаю, откуда ты его вывел.
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, не говоря уже про ассемблер, уделает ее под орех. Как по удобству использования, так и по компантности результирующего кода.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreyFedotov, Вы писали:
VD>>В общем, как я понимаю, ты просто не понимашь сути термина которым оперируешь. AF> Влад, не передёргивай. Я более, чем уверен, что Евгений понимает суть систем РВ так же хорошо как и ты. А разводить демогогию вокруг того, что раз система реального времени должна иметь время отклика не более чем или фиксированное, то давайте поставим время отклика час и тогда у нас все системы будут ОС-РВ, не стоит. Это и так очевидно.
Демагогию тут разводит кто-то другой. Я же замети только то, что вопрос скорости к вопросу о системах реального времени не имеет. Это разные вещи. Именно по этому приводить СРВ в качестве аргумента в разговоре о скорости управляемого кода является той самой демагогией.
E>>>В нормальных задачах реального времени, VD>>О, как! У нас появился еще один термин "нормальные задачи реального времени". AF>На большее чем прицепиться к словам терпения не хватило?
Не просто радуюсь с примеров той самой... Вместо аргументов "громкие слова".
AF>Всё это хорошо тогда, когда у тебя есть хотя бы 20-30% свободных временных ресурсов для работы. А их часто просто нет. Кроме того, приведённый алгоритм несчадно жрёт память. А её тоже может не быть
Всего может не быть. Но какое это отношение имеет к ЖЦ?
AF> А зачем тогда сборщик мусора? И какой прок от языков, построенных вокруг него?
Это ко мне вопросы? Это же не я говрю о том что в СВР память нельзя занимать?
AF> Он просто превращается в ненужный рудимент.
Это без разницы. Главно, что его никак нельзя привратить в контраргумент при таких условиях.
AF> В системах жёсткого реального времени могут быть опасны даже такие фичи C++ как dynamic_cast — так как последний требует линейного времени работы (в зависимости от глубины типов), что явным образом не видно.
Жить вообще опасно.
AF>Да, понятно что и на одной ноге можно мастерски научиться танцевать при желании. Только вот зачем?
Вот и меня это интересует. Давай спросим об этом у поклонников С++.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AF> Я слежу за новостями. Влад, Ты сам что-нибудь под ОС реального времени писал? Ты под железо (не PC/Mac/Workstation), а под DSP или 16 bit CPU писал, с жёсткими ограничениями на время выполения? Ты знаешь, какие там требования или ограничения?
Писал, под ДОС. А ты на JavaRT?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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.
Когда я писал о 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
Здравствуйте, 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++, но подозреваю, что писать можно и нужно на языке, наиболее оптимальном для решения задачи. Кстати я неоднократно писал о самых разных языках, применяемых в СРВ, включая функциональные языки и даже Оберон.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, A.Lokotkov, Вы писали:
VD>Ссылки очень интересные. Особенно jrt. А не мог бы ты про это дело статейку написать? Мы бы ее с удовольствием ее напечатали и разместили бы на сайте.
Мне кажется, направленность rsdn.ru несколько не соответствует теме. Попробуем как-нибудь написать, но не очень скоро, поскольку есть много сырца, наработок и мыслей, а времени собрать все это до кучи нет, увы.
Здравствуйте, VladD2, Вы писали:
AF>> Зато приходилось иметь дело с 8, 16 и 32 битными контроллерами, а так же кучей DSP. Так там, если задача критичная (по отношению требуемое для её решения времени к гарнтированному времени отклика), неудобен был даже C++, Проще и лучше было писать на C, а в некоторых случаях на ассемблере. Поскольку подобных экспериментов с каждым из этих языков было проделано множество и не только мной — опыт достаточно хороший для того, что бы на его основе делать выводы про переспективы применения в данных областях той или иной технологии. Так вот JavaRT там как корове ярмо — по тем же причинам, по которым там частенько выступал в таком же качестве C++.
VD>То есть предлагашь развить тему производительности управляемого кода уже даже не на СВР, а на программирование котроллеров?
Так большинство СРВ делаются вовсе не на x86 архитектуре!
VD>Может уже хватит этого фарса? Какое отношение котроллеры имеют к данному воросу?
К какому именно вопросу? О применимости GC в неких абстрактных СРВ? В абстарктных СРВ? А как быть на счёт конкретных, реально существующих систем?
Большинство СРВ написано на достаточно специфичном железе, с совсем иными характеристиками, чем обычные PC. Иногда производительнее и с большими ресурасами, но гораздо чаще — на более медленном и экзотическом, с гораздо меньшим объёмом памяти.
В СРВ с резервом по ресурсам GC применим и успешно применяется, что хорошо известно. А что же до других — более дешёвых систем — то там он не подходит, по целому ряду причин, которые тут уже неоднократно упоминались.
VD>Ну, а предпочтение С вместо С++ это вообще странно выглядит. Языки то обратно совместимы. Я еще понял бы если бы ты о С99 говорил. Пиши себе на подмножестве С++ не вызывающем рантаймтых операций...
Иногда так и делают. Иногда на C++ на столько бессмысленно писать для данной области, что кроме компилятора C производитель вообще ничего больше не выпускает (это чаще всего бывает с DSP или 8-16 битными однокристалками). Но C++ без ООП и шаблонов — это уже не C++, а скорее C. Что собственно я и имел в виду.
Здравствуйте, AndreyFedotov, Вы писали:
Ш>>Но должен заметить, что в России делают и передовые разработки. Так что не всё так плохо. AF> Делают. И это вселяет оптимизм. Вопрос лишь в отношении числа этих разработок к числу разработок под обычные ПК. По-моему оно таки уступает тому что есть на западе.
Да нет, грустно все на самом деле. Мало очень таких разработок. Работая на западного дядю, набираешся всяких полезных знаний, опыта и навыков, но все это оказывается совершенно не применимым в нашей стране. Вот и у нас в институте идет постоянная утечка мозгов на запад...
Здравствуйте, A.Lokotkov, Вы писали:
AL>Мне кажется, направленность rsdn.ru несколько не соответствует теме.
Тема интересная. У нас народ любознательный.
AL> Попробуем как-нибудь написать, но не очень скоро, поскольку есть много сырца, наработок и мыслей, а времени собрать все это до кучи нет, увы.
Если что поможем чем сможем.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
C>>>3. Скорость, скорость, скорость.
VD>>Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
Влад, это не "фобия". Фобия — это боязнь. А то, о чем ты хотел сказать, называется "мания".
AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
GC мне напоминает Windows со всякими автоматическими апдейтами, особенно в конторах с централизованным управлением. Тут надо срочно глюк исправить, а оно говорит — "знать ни чего не знаю, мне надо сейчас все перегрузить, у тебя, парень 4 минуты, время пошло...". И занимает это иногда минут по 15. Или как в начале фильма "Office Space" — надо срочно выключить и свалить, а оно Reindexing..., Synchronizing... и т.д. MS Outlook — вообще анегдот. Ему не хватает тех самых 4-х минут, что нам отвели админы на сохранение данных. В результате перезагрузка его просто срубает в самый интересный момент.
То же самое с GC — надо срочно ответить на прерывание, а оно начинает мусор подметать. А ракета тем временем уже пошла на Бобруйск. В чем бедные бобры провинились перед GC?!
Вот Влад тут размахивает игрушками, сделанными на dot-net — дескать ничего не тормозит. Верю. Более того, верю в то, что в общем и целом, система управления памятью с GC получается более эффективной за счет автоматического и постоянного поддержания кучи в порядке.
Но игрушки — это не системы реального времени.
Как уже было сказано, дело не в эффективности а в предсказуемости. В большинстве современных приложений (в том чмисле и игрушках) предсказуемость действительно не важна и GC действительно автоматизирует очень много чего.
Но есть так же случаи, где она важна. И я категорически против того, чтобы кто-то там начинал подметать мусор в самый критический момент. Задач, где подобных "критических моментов" просто нет — подавляющее большинство. Задач, где они есть — очень мало. Но тем не менее, они существуют, вне зависимости от мнений.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, VladD2, Вы писали:
C>>>3. Скорость, скорость, скорость.
VD>>Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
Известная проблема и известный аргумент. Да, на данный момент платформы Java/.NET не способны дать даже soft-realtime гарантий. Тем не менее, вообще GC реального времени существют. В настоящее время единственная промышленная платформа с GC, обеспечивающая soft-realtime гарантии — это Erlang/OTP.
Также, ведутся работы над инкрементальными soft-realtime сборщиками мусора для Java и .NET. Решение этой проблемы — вопрос времени, проблема решаема. Вот некоторые ссылки — в гугле их много на эту тему.
Я хотел бы разбраться в понятиях, что есть СРВ. По-моему это система с предсказуемым временем отклика. Если я прав то дискусия разведенная на тему: ".НЕТ+ГС тормоз, следовательно СРВ на нем сторить низя" является глупостью. И не надо ее дальше продолжать в таком духе.
Сам я сомниваюсь что ГС (в том виде, какой он есть сейчас под .НЕТ) сможет дать гарантированное время отклика, т.е. всегда не дольше Н (в разумных пределах, пример с Н=1часу не приводить, т.к. это явно не приемлемо, обосновывать почему не буду). Но если существую системы управления памятью по .НЕТ с грантированным временем отклика (это про что писал Влад), то на .НЕТ можно писать СРВ.
Вопрос в том, что .НЕТ не будет работать на ДСП-процессорах или микрокотролерах поднимаить не имеет смысла, т.к. там важна оптимизация кода под конкретный процессор, а эту работу никто компилятору не доверит. Сам имею небольшой опыт оптимизаии под ДСП СПАРК-хххх (вроде так звался) и х86. Так по х86 оптимизировать (по конвеиры) задача тривиальная, а вот у ДСП заморочек выше крыши, и если там их не выпонить, а написать протсто код на асемблере, то получается очень даже тормозная прога. А вот если писать на .НЕТ СРВ работающую на "солидной" плтаформе, то ппроизойдет снижение стоимости ПО, и повышение стоимости железа, т.к. .НЕТ априори тормознее нативного кода. Но есть подозрение (читай уверен на 100%) что снижение цены на ПО окупить рост цены на железки.
ЗЫ. Еще раз для всех: СРВ — не обязательно быстрая система, это система гарантировонно дающая ответ чрез определенное время и все. Все оптимизации идут на снижение стоимостижелеза и не всегда оправданы (оправданы только при массовм производстве — читатя контролеры для бытовой техники например).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, VladD2, Вы писали:
C>>>>3. Скорость, скорость, скорость.
VD>>>Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
AF>>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
G>Известная проблема и известный аргумент. Да, на данный момент платформы Java/.NET не способны дать даже soft-realtime гарантий. Тем не менее, вообще GC реального времени существют. В настоящее время единственная промышленная платформа с GC, обеспечивающая soft-realtime гарантии — это Erlang/OTP.
Согласен. Как раз об этом регулярно и напоминал в своих постах. Как и о успешном применении функциональных языков (со встроенными GC).
G>Также, ведутся работы над инкрементальными soft-realtime сборщиками мусора для Java и .NET. Решение этой проблемы — вопрос времени, проблема решаема. Вот некоторые ссылки — в гугле их много на эту тему.
G>Вот это работает уже сейчас в IBM Java, хотя пауза, конечно, несколько велика для soft-realtime. G>http://www-128.ibm.com/developerworks/ibm/library/i-incrcomp/
G>А вот это — "теоретики" со своими прототипами. G>http://www.usenix.org/publications/library/proceedings/vm04/wips/goh.pdf
G>Короче, проблема есть, но не является фундаментальной проблемой технологии.
Спасибо за линки. Кстати, думаю, что проблема всё-таки является фундаментальной, поскольку как ни крути, а GC всё-таки достаточно медленная технология по сравнению со спец-распеределителями, которые обычно применяют в СРВ и дают достаточно большое время задержки. Но! Поскольку производительность систем постоянно растёт, кроме того есть наработки по аппаратному решению задачи GC — то думаю, что для крупных систем (хотя бы масштаба ПК) это достаточно скоро будет не критично, как сейчас не критичны задержки времени на вызов виртуальных методов. Так что будущее, подозреваю, за GC и подобными технологиями.
Но это всё относится к системам "мягкого" реального времени. Всегда будут оставаться системы жёсткого и сверхжёсткого реального времени и для них я думаю ещё очень долго основной технологией будут оставаться языки уровня Cи, максимум C++, со вставками на ассемблере. А то и вовсе ассемблер.
Здравствуйте, McSeem2, Вы писали:
MS>Влад, это не "фобия". Фобия — это боязнь. А то, о чем ты хотел сказать, называется "мания".
Вы мне льстите, Киса... (с)
MS>Вот Влад тут размахивает игрушками,
Надо было добавить "кстати, где он?".
MS> сделанными на dot-net — дескать ничего не тормозит. Верю. Более того, верю в то, что в общем и целом, система управления памятью с GC получается более эффективной за счет автоматического и постоянного поддержания кучи в порядке.
MS>Но игрушки — это не системы реального времени.
Поехала по новой. Ну, нет у меня задач где требовалось бы реальное время. Думаю, у тебя и у 99% посетителей этого сайте тоже нет таких жадач. У многих даже небыло никогда. А у многих и не появится. Сейчас даже реалтаймные девайсы вроде DVD-писалок стали работать на не раелтайм ОС. Добавили пару метров буфера, чтобы можно было дорожку закэшировать и все. А те кто фирмварю для этих кнтроллеров пишут пусть и возятся с чем хотят.
Если бы мне пришлось разработывать СВР я бы тоже попытался бы туже JavaRT приспособить или еще что-то. А уж если бы вариантов не осталось, то тогда велкам в мир багов на ровном месте.
Короче, мне достаточно того, что в большинстве задач ЖЦ более чем приемлем.
Более того я даже не буду спорить, что если я напрягусь, то в кокретной задаче уделаю любую автоматику, ну если не в разы, то на серьезные проценты. Вот только это можно сделать, ну, раз, ну, два. На "слабо" или просто в порыве прилива энергии. А дальще это уже получается мазохим. А мазохизм я как-то не очень люблю. Уж лучше содизм или вымогательство (ну, например, памяти из клиентов ).
MS>Как уже было сказано, дело не в эффективности а в предсказуемости. В большинстве современных приложений (в том чмисле и игрушках) предсказуемость действительно не важна и GC действительно автоматизирует очень много чего.
В коем-то веке мы с тобой сошлись во мнеии. Чую подвох... буду читать дальше.
MS>Но есть так же случаи, где она важна. И я категорически против того, чтобы кто-то там начинал подметать мусор в самый критический момент. Задач, где подобных "критических моментов" просто нет — подавляющее большинство. Задач, где они есть — очень мало. Но тем не менее, они существуют, вне зависимости от мнений.
Полностью согласен. Насколько я понял в РВ-расширениях для Явы кроме предсказуемого ЖЦ и т.п. вводятся некий АПИ позволяющий запретить вызов ЖЦ в особо ответственные моменты или даже пометить некий код как выделяющий память только на определенное время. Казалось бы ручное управление как в С++? Ан нет. Это все же автоматика. Все же компилятор или другая тулза сможет определить, что код нарушает семантику используя память вделенную в блоке помеченном как выделющей память на время. Ну, и приостановить ЖЦ не значит от него отказаться.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Известная проблема и известный аргумент. Да, на данный момент платформы Java/.NET не способны дать даже soft-realtime гарантий.
The specification will extend the JavaTM Platform with an industry-standard set of extensions that enables the construction of systems that exhibit real-time behavior. It will bring advantages of the Java Platform -- binary portability, dynamic code loading, tool support, safety, security, and simplicity -- to an important industry segment: real-time systems. This extension targets both "hard real-time" and "soft real-time" systems.
Здравствуйте, AndreyFedotov, Вы писали:
VD>>То есть предлагашь развить тему производительности управляемого кода уже даже не на СВР, а на программирование котроллеров? AF>Так большинство СРВ делаются вовсе не на x86 архитектуре!
Т.е. продолжашь. Ну, тогда продолжай.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Поехала по новой. Ну, нет у меня задач где требовалось бы реальное время. Думаю, у тебя и у 99% посетителей этого сайте тоже нет таких жадач. У многих даже небыло никогда. А у многих и не появится. Сейчас даже реалтаймные девайсы вроде DVD-писалок стали работать на не раелтайм ОС. Добавили пару метров буфера, чтобы можно было дорожку закэшировать и все. А те кто фирмварю для этих кнтроллеров пишут пусть и возятся с чем хотят.
Да я вижу, что нет. Возьмем тот же Янус — это система откровенно нереального времени... Он запускается медленнее, чем "The Bat!" и "Opera" вместе взятые... Да даже студия 2003 запускается на 500Mhz быстрее, чем рсдн@дом на 1600Mhz. И не надо мне говорить, что работаю я в музее
А говорите, нет задач с реальным временем... Хотя у меня есть надежда, что он просто корявенько сделан
Здравствуйте, ansi, Вы писали:
A>Да я вижу, что нет. Возьмем тот же Янус — это система откровенно нереального времени... Он запускается медленнее, чем "The Bat!" и "Opera" вместе взятые... Да даже студия 2003 запускается на 500Mhz быстрее, чем рсдн@дом на 1600Mhz. И не надо мне говорить, что работаю я в музее
Ты бы лучше не брал примеры без основательного анализа. А то так и будешь в просак попадать. В закгрузке Януса основное время уходит на чтение БД через Jet который ни к управляему коду, ни к GC отношение не имеет.
A>А говорите, нет задач с реальным временем... Хотя у меня есть надежда, что он просто корявенько сделан
Ну, надейся. Кто же тебе помешает, то?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
Т>Можно, я вместо Сергея? Вот эта штука работает подhard-realtime ОС со сборкой мусора.
А где написано про hard-realtime?
LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, Gaperton, Вы писали:
Т>>Можно, я вместо Сергея? Вот эта штука работает подhard-realtime ОС со сборкой мусора.
E>А где написано про hard-realtime?
E>LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
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.
The phrase "real-time" does not directly relate to how fast the program responds, even though many people believe that real-time means real-fast. This is a direct fall-out from the fact that it is easier to meet deadlines with a fast system. However, many operating systems now run on powerful hardware and are "fast", but that speed does not necessarily imply "determinism". Determinism is more important than average speed for real-time systems.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Трурль, Вы писали:
Т>>>Здравствуйте, Gaperton, Вы писали:
Т>>>Можно, я вместо Сергея? Вот эта штука работает подhard-realtime ОС со сборкой мусора.
E>>А где написано про hard-realtime? Т>
E>>LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
Я сейчас вряд ли смогу найти точное определение терминов "мягкое реальное время" (soft-realtime) и "жесткое реальное время" (hard-realtime), но на пальцах:
— в жестком реальном времени превышение времени отклика является катострофическим;
— в мягком реальном времени превышение времени отклика приводит к тому, что результаты просто являются неактуальными и должны быть проигнорированы.
Как легко догадаться, на жесткость времени влияет темп работы -- чем он меньше, тем сложнее обеспечивать требования жесткого времени. Поэтому, если бы LOTraffic было сказано, что они работают с темпом 1000 опросов в секунду, то было бы понятно, что это похоже на жесткое время.
Еще одним фактором, обеспечивающим жесткость является объем работы, который нужно выполнить за единицу времени (шаг, строб или другой термин). Может оказаться так, что при большом объеме работы (много вычислений или много операций ввода/вывода) обеспечение даже невысокого темпа (порядка нескольких десятков миллисекунд) будет очень непростым делом. Но я здесь не увидел подобных симптомов, а темп в ~26 миллисекунд особо высоким не назовешь.
Ну и, наконец, еще один критерий -- это критичность неудовлетворения временным интервалам. Т.е., насколько критично в LOTraffic не попадание в эти 26 миллисекунд? Они что, с помошью LOTraffic машинами скорой помощи управляют? Или это больше информационно-измерительная система? Вот и поэтому критерию мне кажется, что называть ее hard realtime вряд ли возможно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, eao197, Вы писали:
E>>>Здравствуйте, Трурль, Вы писали:
Т>>>>Здравствуйте, Gaperton, Вы писали:
Т>>>>Можно, я вместо Сергея? Вот эта штука работает подhard-realtime ОС со сборкой мусора.
E>>>А где написано про hard-realtime? Т>>
E>>>LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
E>Я сейчас вряд ли смогу найти точное определение терминов "мягкое реальное время" (soft-realtime) и "жесткое реальное время" (hard-realtime), но на пальцах: E>- в жестком реальном времени превышение времени отклика является катострофическим; E>- в мягком реальном времени превышение времени отклика приводит к тому, что результаты просто являются неактуальными и должны быть проигнорированы.
E>Как легко догадаться, на жесткость времени влияет темп работы -- чем он меньше, тем сложнее обеспечивать требования жесткого времени. Поэтому, если бы LOTraffic было сказано, что они работают с темпом 1000 опросов в секунду, то было бы понятно, что это похоже на жесткое время.
E>Еще одним фактором, обеспечивающим жесткость является объем работы, который нужно выполнить за единицу времени (шаг, строб или другой термин). Может оказаться так, что при большом объеме работы (много вычислений или много операций ввода/вывода) обеспечение даже невысокого темпа (порядка нескольких десятков миллисекунд) будет очень непростым делом. Но я здесь не увидел подобных симптомов, а темп в ~26 миллисекунд особо высоким не назовешь.
E>Ну и, наконец, еще один критерий -- это критичность неудовлетворения временным интервалам. Т.е., насколько критично в LOTraffic не попадание в эти 26 миллисекунд? Они что, с помошью LOTraffic машинами скорой помощи управляют? Или это больше информационно-измерительная система? Вот и поэтому критерию мне кажется, что называть ее hard realtime вряд ли возможно.
А причем тут скорость. Сорость можно поднять поставив более мощное железо.
Здравствуйте, wraithik, Вы писали:
W>А причем тут скорость. Сорость можно поднять поставив более мощное железо.
Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи.
Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа.
Здравствуйте, wraithik, Вы писали:
E>>Я сейчас вряд ли смогу найти точное определение терминов "мягкое реальное время" (soft-realtime) и "жесткое реальное время" (hard-realtime), но на пальцах: E>>- в жестком реальном времени превышение времени отклика является катострофическим; E>>- в мягком реальном времени превышение времени отклика приводит к тому, что результаты просто являются неактуальными и должны быть проигнорированы.
E>>Как легко догадаться, на жесткость времени влияет темп работы -- чем он меньше, тем сложнее обеспечивать требования жесткого времени. Поэтому, если бы LOTraffic было сказано, что они работают с темпом 1000 опросов в секунду, то было бы понятно, что это похоже на жесткое время.
E>>Еще одним фактором, обеспечивающим жесткость является объем работы, который нужно выполнить за единицу времени (шаг, строб или другой термин). Может оказаться так, что при большом объеме работы (много вычислений или много операций ввода/вывода) обеспечение даже невысокого темпа (порядка нескольких десятков миллисекунд) будет очень непростым делом. Но я здесь не увидел подобных симптомов, а темп в ~26 миллисекунд особо высоким не назовешь.
E>>Ну и, наконец, еще один критерий -- это критичность неудовлетворения временным интервалам. Т.е., насколько критично в LOTraffic не попадание в эти 26 миллисекунд? Они что, с помошью LOTraffic машинами скорой помощи управляют? Или это больше информационно-измерительная система? Вот и поэтому критерию мне кажется, что называть ее hard realtime вряд ли возможно.
W>А причем тут скорость. Сорость можно поднять поставив более мощное железо.
Вот и я думаю, причем здесь скорость? Я хочу понять, почему Труль обозвал LOTraffic системой жесткого реального времени.
А заменить железо далеко не всегда возможно, кстати.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну и, наконец, еще один критерий -- это критичность неудовлетворения временным интервалам. Т.е., насколько критично в LOTraffic не попадание в эти 26 миллисекунд? Они что, с помошью LOTraffic машинами скорой помощи управляют? Или это больше информационно-измерительная система? Вот и поэтому критерию мне кажется, что называть ее hard realtime вряд ли возможно.
Согласен. LOTraffic вряд ли можно назвать hard realtime системой. Но я писал об XO/2, которая у ей внутре.
Просто не нашел сразу продходящего примера применения.
Вот ее еще в роботах используют.
Что касается скорости. Почему-то всю информацию об XO/2 с сайта удалили.
Но некоторое представление можно получить по ее предшественницеXOberon.
The kernel schedules tasks with 10KHz rate, with an overhead of less than 1 percent on a PowerPC 604 hardware. This allows response times which are a factor 4 faster than any other industry operating system running on the same hardware. Moreover, the size of the complete XOberon operating system (core and network servers and clients), is less than 512 KB ROM and needs 1.5 MB RAM on the target.
For example, the Hexaglide milling machine, is being run on a PowerPC604@100Mhz, with the following hard real-time tasks, among others (system maintenance or not relevant):
PD-controller and velocity observer: period 300 microsecs; 130 fp-multiply, 120 fp-add
Path-planner: period 300 microsecs; 110 fp-multiply, 100 fp-add
Dynamic pre-controller: period 2.5 ms; 1720 fp-multiply, 1750 fp-add
Adaptation of dynamic parameters: period 10 ms, 400 fp-multiply, 380 fp-add
Data miner, watchdog, security processes ...
The system is loaded up to the 89.8 percent by the hard real-time processes. The scheduler has a lot to do and schedules the 19 application and system tasks with a 5.5 percent overhead.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, wraithik, Вы писали:
W>>А причем тут скорость. Сорость можно поднять поставив более мощное железо.
AF>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа.
Говорили. В результате Ericsson-овская железка AXD301 выпущена и работает (тормозной Erlang), потому что предыдущая попытка сделать то же на плюсах провалилась. Вообще — все успешные продукты Ericsson за последние 10 лет сделаны на Erlang. При этом Erlang очень нетороплив по сравнению с С++.
Здравствуйте, Трурль, Вы писали:
Т>Что касается скорости. Почему-то всю информацию об XO/2 с сайта удалили.
Наверное, уже не так все хорошо, по сравнению с конкурентами?
Т>Но некоторое представление можно получить по ее предшественницеXOberon.
Т>
For example, the Hexaglide milling machine, is being run on a PowerPC604@100Mhz, with the following hard real-time tasks, among others (system maintenance or not relevant):
Т>
Т>PD-controller and velocity observer: period 300 microsecs; 130 fp-multiply, 120 fp-add
Т>Path-planner: period 300 microsecs; 110 fp-multiply, 100 fp-add
Т>Dynamic pre-controller: period 2.5 ms; 1720 fp-multiply, 1750 fp-add
Т>Adaptation of dynamic parameters: period 10 ms, 400 fp-multiply, 380 fp-add
Т>Data miner, watchdog, security processes ...
Т>
Осталось показать исходники выделенных компонент и доказать, что там GC используется как самой задачей, так и операционкой.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
AF>>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа.
G>Говорили. В результате Ericsson-овская железка AXD301 выпущена и работает (тормозной Erlang), потому что предыдущая попытка сделать то же на плюсах провалилась. Вообще — все успешные продукты Ericsson за последние 10 лет сделаны на Erlang. При этом Erlang очень нетороплив по сравнению с С++.
А вот и нет. Ты же сам доказывал, что в контексте этой железки и решаемых задач Erlang отнюдь не медленнее, чем C++, более того, он даже лучше подходит для задач такого рода. То есть было найдено более эффективное решение. Вот и всё. Что же до железа — так в этом классе систем его стоимость не так критична, как для отдельных цифровых радиприёмников например.
Тут же было сделано заявление без указания контекста его применимости.
Здравствуйте, eao197, Вы писали:
E>Осталось показать исходники выделенных компонент и доказать, что там GC используется как самой задачей, так и операционкой.
А какая разница, кто использует GC?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Осталось показать исходники выделенных компонент и доказать, что там GC используется как самой задачей, так и операционкой. Т>А какая разница, кто использует GC?
Большая. Я думаю, что Евгений имел в виду ситуацию, когда компонент при запуске хапает память целиком, а потом лишь использует её, вообще не возвращая системе — эдакий спец-распределитель памяти. Тут вообще не задействован GC. И он и не нужен.
Здравствуйте, AndreyFedotov, Вы писали:
Т>>А какая разница, кто использует GC? AF>Большая. Я думаю, что Евгений имел в виду ситуацию, когда компонент при запуске хапает память целиком, а потом лишь использует её, вообще не возвращая системе — эдакий спец-распределитель памяти. Тут вообще не задействован GC. И он и не нужен.
Даже если какой-то компонент так и поступает (хотя смысла в этом нет ), это не мешает любому другому в это же время запустить сборку мусора.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, AndreyFedotov, Вы писали:
Т>>>А какая разница, кто использует GC? AF>>Большая. Я думаю, что Евгений имел в виду ситуацию, когда компонент при запуске хапает память целиком, а потом лишь использует её, вообще не возвращая системе — эдакий спец-распределитель памяти. Тут вообще не задействован GC. И он и не нужен.
Т>Даже если какой-то компонент так и поступает (хотя смысла в этом нет ), это не мешает любому другому в это же время запустить сборку мусора.
Конечно. Но, скорее всего, что этот другой будет работать на менее низком приоритете. И не факт, что сама OC активно использует GC.
И не факт, что при темпе в 300 микросекунд кто-то еще будет работать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Конечно. Но, скорее всего, что этот другой будет работать на менее низком приоритете. И не факт, что сама OC активно использует GC. E>И не факт, что при темпе в 300 микросекунд кто-то еще будет работать.
Резюме. Не факт, что сборка мусора мешает реалтаймовости.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Конечно. Но, скорее всего, что этот другой будет работать на менее низком приоритете. И не факт, что сама OC активно использует GC. E>>И не факт, что при темпе в 300 микросекунд кто-то еще будет работать.
Т>Резюме. Не факт, что сборка мусора мешает реалтаймовости.
Не факт, что это верное резюме
Если серьезно, то мягкому реальному времени при достаточности вычислительных ресурсов наверняка не помешает.
При жестком реальном времени и органиченности ресурсов необходимость, полезность и ...как бы это цензурно обозвать... нейтральность (т.е. чтобы ничему не мешало) GC нужно доказывать.
Т.е. возвращаемся к тому, с чего начали.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
A>>Да я вижу, что нет. Возьмем тот же Янус — это система откровенно нереального времени... Он запускается медленнее, чем "The Bat!" и "Opera" вместе взятые... Да даже студия 2003 запускается на 500Mhz быстрее, чем рсдн@дом на 1600Mhz. И не надо мне говорить, что работаю я в музее
VD>Ты бы лучше не брал примеры без основательного анализа. А то так и будешь в просак попадать.
Забавно, я уже "впросаке" сижу, так сказать. Причем, оказывается и не в первый раз... Поаккуратнее, Влад.
VD>В закгрузке Януса основное время уходит на чтение БД через Jet который ни к управляему коду, ни к GC отношение не имеет.
Вообще-то моя реплика была направлена на "Ну, нет у меня задач где требовалось бы реальное время.".
A>>А говорите, нет задач с реальным временем... Хотя у меня есть надежда, что он просто корявенько сделан
VD>Ну, надейся. Кто же тебе помешает, то?
Здравствуйте, eao197, Вы писали:
E>Т.е. возвращаемся к тому, с чего начали.
Угу. Представьте, что я заявляю "C++ пригоден разве что для open-source поделок, а для серьезной коммерческой разработки нужен читстый C". Естественно, мне начнут тыкать в нос виндовс с офисом и т.п. А я невозмутимо буду отвечать: "А где гарантии, что там используются классы, шаблоны и прочие плюсовые навороты"?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Т.е. возвращаемся к тому, с чего начали.
Т>Угу. Представьте, что я заявляю "C++ пригоден разве что для open-source поделок, а для серьезной коммерческой разработки нужен читстый C". Естественно, мне начнут тыкать в нос виндовс с офисом и т.п. А я невозмутимо буду отвечать: "А где гарантии, что там используются классы, шаблоны и прочие плюсовые навороты"?
Во-первых, говоря про СРВ я подчеркивал, что говорю про то, что видел.
Про то, что Windows и значительная часть офиса была написана на C++, да еще и с MFC так же давно известно. Если не веришь, попробуй удалить у себя все MFC-шные dll-ки.
Ну и я сам лично видел, что в Credits у Adobe Reader 7 был указан Boost.
Так что очевидные вещи доказывать, обычно не нужно. А вот GC и реальное время -- это далеко не очевидная, имхо, вещь.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Есть две крайности. Одна — верить во всё подряд, другая не верить во всё подряд. Есть так же собственный опыт и здравый смысл.
И когда опыт и здравый смысл показывают, что нечто весма сомнительно — естественно возникают вопросы.
То, что в системах мягкого реального времени сборщик мусора, хоть и достаточно специфический применять можно, это факт, так как он там применяется достаточно успешно. Точно так же пока представить себе применение сборщика мусора в системах жёсткого реального времени со временем реакции порядка микросекунд так же трудно. Это следует из тривиального расчёта — если у нас 1 мкс — это при частоте процессора в 4 ГГц — всего 4000 интсрукций, что для сборки мусора маловато, а ведь ещё нужно делать полезную работу. Ну а если вспомнить, что в производительные СРВ из соображений надёжности часто ставятся не самые быстрые по тактовой частоте процессоры — то ситуация ещё усугубится.
AF>...бывают так же ОС реального времени, так вот для них GC...
А еще бывают [или можно придумать] алгоритмы не требующие [интенсивного или никакого вообще] динамического распределения памяти.
Особенно легко придумывать такие алгоритмы на языках с полноценными value-типами (Oberonы например), тут .NET, и в особенности Java, не совсем адекватны из-за отсутсвия в них полноценных value-типов. Я уже приводил здесь на RSDN пример когда в процедуре был нужен временный массив для вычислений. Поскольку в .NET и Java, нет value-массивов, то этот массив надо либо создавать при момощи new при каждой активации процедуры, либо создать один раз заранее (в стольки экземплярах, сколько может быть одновременно вызвано этих процедур) и хранить их неопределенное количество времени (отнимая память, засоряя дизайн,..). Так вот разница в скорости между этими случаями была шесть раз (в .NET)! Так много — это потому, что было много потоков, каждый вызывал эту процедуру, на тот момент времени когда надо было удалять не нужный более массив он оказывался уже в последнем поколении GC, ведь за время работы процедуры одного потока, другие потоки создавали свои массивы при этом иногда вызывался GC отправляющий пока еще используемые объекты в следующее поколение. В языке программирования с полноценными value-типами можно просто бесплатно создавать временные объекты просто на стеке при каждой активации процедуры не напрягая почем зря GC, при этом даже пользуясь вкусностями навроде динамического полиморфизма (в .NET для struct динамического полиморфизма нет так как нет наследования от struct, а в Java нет даже самого struct).
Здравствуйте, eao197, Вы писали:
E>Про то, что Windows и значительная часть офиса была написана на C++, да еще и с MFC так же давно известно. Если не веришь, попробуй удалить у себя все MFC-шные dll-ки.
Ну, Windows без MFC у меня работает. А офис, не факт, что эта часть значительная и что она реально используется
E>Ну и я сам лично видел, что в Credits у Adobe Reader 7 был указан Boost.
Мало, что там кто-то в Credits напишет.
E>Так что очевидные вещи доказывать, обычно не нужно. А вот GC и реальное время -- это далеко не очевидная, имхо, вещь.
Почему-то этот тезис о невозможности использования GC в реальном времени выдвигается как очевидный. А ведь его надо доказывать. Вместо этого, предлагается его опровергнуть.
Я привел пример ОС реального времени, в которой управление динамической памятью производится только посредством сборки мусора. Возражения по сути сводятся к "не факт, что динамическая память реально используется". Доказать, что она используется на самом деле, не имея исходников, я не могу. Но зачем было бы выбирать такую ОС и не использовать ее возможностей.
Сергей Губанов wrote:
> Особенно легко придумывать такие алгоритмы на языках с полноценными > value-типами (Oberonы например), тут .NET, и в особенности Java, не > совсем адекватны из-за отсутсвия в них полноценных value-типов.
Оберон тоже. Единственный популярный язык с проработанной семантикой
value-типов — это С++.
Например: где там в Обероне копирующий конструктор или как перегрузить
оператор присваивания? Как использовать custom memory management
(критически важная фича) для определенных типов?
Здравствуйте, Трурль, Вы писали:
E>>Так что очевидные вещи доказывать, обычно не нужно. А вот GC и реальное время -- это далеко не очевидная, имхо, вещь.
Т>Почему-то этот тезис о невозможности использования GC в реальном времени выдвигается как очевидный. А ведь его надо доказывать. Вместо этого, предлагается его опровергнуть.
Насколько я помню данную ветку, против допустимости использования GC в системах мягкого реального времени здесь давно не возражают.
Основные и, имхо, обоснованные сомнения приводятся по поводу жесткого реального времени.
Т>Я привел пример ОС реального времени, в которой управление динамической памятью производится только посредством сборки мусора.
И где про это можно почитать? О том, что на XOberon и XO/2 в задачах жесткого реального времени используется GC?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF>То, что в системах мягкого реального времени сборщик мусора, хоть и достаточно специфический применять можно, это факт, так как он там применяется достаточно успешно. Точно так же пока представить себе применение сборщика мусора в системах жёсткого реального времени со временем реакции порядка микросекунд так же трудно. Это следует из тривиального расчёта — если у нас 1 мкс — это при частоте процессора в 4 ГГц — всего 4000 интсрукций, что для сборки мусора маловато, а ведь ещё нужно делать полезную работу. Ну а если вспомнить, что в производительные СРВ из соображений надёжности часто ставятся не самые быстрые по тактовой частоте процессоры — то ситуация ещё усугубится.
Если требуется время реакции 1 мкс и при этом события возникают достаточно часто, а их обработка нетривиальна, то налицо описанная Вами ситуация "впихиваем невпихуемое". Но, вообще говоря, некоторый "излишек" времени может иметь место и в ситуации "да кто ж ему столько даст", не говоря уж о варианте "что нам стоит дом построить". Необязательно ведь впихивать всю сборку мусора в ту самую микросекунду.
Собственно, граница проводится не по признаку "жесткое/мягкое/никакое реальное время", а скорее по признаку "много/мало/очень мало вычислительных ресурсов.
Здравствуйте, Трурль, Вы писали:
Т>Собственно, граница проводится не по признаку "жесткое/мягкое/никакое реальное время", а скорее по признаку "много/мало/очень мало вычислительных ресурсов.
Просто так, к сведению: ресурсов на борту может быть достаточно, а вот запаздывающие ответы от периферийного устройства могут запросто превратить жесткое реальное время в никакое.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, AndreyFedotov, Вы писали:
AF>>То, что в системах мягкого реального времени сборщик мусора, хоть и достаточно специфический применять можно, это факт, так как он там применяется достаточно успешно. Точно так же пока представить себе применение сборщика мусора в системах жёсткого реального времени со временем реакции порядка микросекунд так же трудно. Это следует из тривиального расчёта — если у нас 1 мкс — это при частоте процессора в 4 ГГц — всего 4000 интсрукций, что для сборки мусора маловато, а ведь ещё нужно делать полезную работу. Ну а если вспомнить, что в производительные СРВ из соображений надёжности часто ставятся не самые быстрые по тактовой частоте процессоры — то ситуация ещё усугубится.
Т>Если требуется время реакции 1 мкс и при этом события возникают достаточно часто, а их обработка нетривиальна, то налицо описанная Вами ситуация "впихиваем невпихуемое". Но, вообще говоря, некоторый "излишек" времени может иметь место и в ситуации "да кто ж ему столько даст", не говоря уж о варианте "что нам стоит дом построить". Необязательно ведь впихивать всю сборку мусора в ту самую микросекунду. Т>Собственно, граница проводится не по признаку "жесткое/мягкое/никакое реальное время", а скорее по признаку "много/мало/очень мало вычислительных ресурсов.
Согласен. именно об этом я и писал. Естественно мы находимся в контексте современного уровня развития технологии, так что примерно можем оценивать границы производительности того или иного железа, требуемый объём операций и времена, за которые возможно провести вычисления. Вполне возможно, что лет через сто микросекунда будет считаться мягким реальным временем и там прекрасно будет работаь GC. Для этого требуется всего лишь повысить тактовую частоту раз в 20-100.
Здравствуйте, Сергей Губанов, Вы писали:
AF>>...бывают так же ОС реального времени, так вот для них GC...
СГ>А еще бывают [или можно придумать] алгоритмы не требующие [интенсивного или никакого вообще] динамического распределения памяти.
Бывают.
Про успешное применение Оберона в системах мягкого реального времени я уже несколько раз упоминал. Например здесь
. Вопрос же применимости более высокоуровневых языков чем C/Pascal/C++ в системах жёсткого реального времени, с временами отклика порядка микросекунд вызывает у меня (и не только у меня) большие сомнения, в силу не прозрачности поведения кода написанного на этих языках (и даже на C++), в таком временном масштабе.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Вполне возможно, что лет через сто микросекунда будет считаться мягким реальным временем и там прекрасно будет работаь GC.
Вот эта привязка к цифрам мне не нравится. В настоящее время микросекунда (а также милисекунда или секунда) может считаться мягким реальным временем, а может и жестким.
Здравствуйте, eao197, Вы писали:
E>А где написано про hard-realtime? E>
E>LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
Хоть кол на голове теши. Понятие hard-realtime никакого отношения к времени допустимой задержки не имеет! Оно определят фатальность превышения этого времени.
В общем, может LOTraffic и не "хард", но твои слова этого никак не опровергают.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А где написано про hard-realtime? E>>
E>>LOTraffic's real-time software system coupled with state-of-the-art laser ranging technology is able to scan and sample the environment 38 times per second.
VD>Хоть кол на голове теши. Понятие hard-realtime никакого отношения к времени допустимой задержки не имеет! Оно определят фатальность превышения этого времени.
VD>В общем, может LOTraffic и не "хард", но твои слова этого никак не опровергают.
Так же как нигде, кроме слов Труля, не было заявлено, что LOTraffic является hard realtime системой.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Так же как нигде, кроме слов Труля, не было заявлено, что LOTraffic является hard realtime системой.
Т>И даже Трурль такого не говорил.
Извини, зарапортовался
А где, кстати, можно прочитать, что XO/2 или XOberon используют сборку мусора в hard realtime режимах?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Вполне возможно, что лет через сто микросекунда будет считаться мягким реальным временем и там прекрасно будет работаь GC.
Т>Вот эта привязка к цифрам мне не нравится. В настоящее время микросекунда (а также милисекунда или секунда) может считаться мягким реальным временем, а может и жестким.
Мягкое или жёсткое реальное время определяется совсем другими критериями. Просто оба термина используются двояко (особенно в контексте форума):
Жёсткое реальное время (формально) — это реакция должна быть ганантированно выдана в течение заданного промежутка времени (вариант — строго по истечению заданного промежутка времени)
Мягкое реальное время — реакция может несистематически превышать гарантированное время отклика.
Есть и два других значения:
Жёсткое реальное время — это жёсткое реальное время в формальном смысле + времена реакции порядка микросекунд или же такая вычислительная нагрузка, которая на пределе (очень хорошо оптимизированная) укладывается в заданное время
Мягкое реальное время так же понимается как реальное время при котором для того, что бы выдать отклик ресурсов хватает с большим запасом.
Здравствуйте, eao197, Вы писали:
E>Так же как нигде, кроме слов Труля, не было заявлено, что LOTraffic является hard realtime системой.
Согласен. Но опровергать не вполне корректные заявления отровенно не логичными высказываниями точно не стоит.
E>И мне интересно, с чем именно вот здесь ты не согласен: Re[5]: GC и системы реального времени
Как легко догадаться, на жесткость времени влияет темп работы -- чем он меньше, тем сложнее обеспечивать требования жесткого времени. Поэтому, если бы LOTraffic было сказано, что они работают с темпом 1000 опросов в секунду, то было бы понятно, что это похоже на жесткое время.
Вообще рассуждени о темпе и т.п. звучат откровенно раздражающими после того как даже ты сам написал:
— в жестком реальном времени превышение времени отклика является катострофическим;
— в мягком реальном времени превышение времени отклика приводит к тому, что результаты просто являются неактуальными и должны быть проигнорированы.
Я уже устал повторяться.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
? А то я не очень понял, за что минус.
VD>Все начиная с: VD>
Как легко догадаться, на жесткость времени влияет темп работы -- чем он меньше, тем сложнее обеспечивать требования жесткого времени. Поэтому, если бы LOTraffic было сказано, что они работают с темпом 1000 опросов в секунду, то было бы понятно, что это похоже на жесткое время.
Да уж.
Как ты думаешь, гарантированно выдавать результат перемножения двух матриц 1000x1000 из комплексных чисел с темпом 50Hz и 500Hz одинаково просто? На одном и том же железе?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Как ты думаешь, гарантированно выдавать результат перемножения двух матриц 1000x1000 из комплексных чисел с темпом 50Hz и 500Hz одинаково просто? На одном и том же железе?
Сложность тут не имеет никакого значения. Ты еще не забыл что тут осбуждается? Или хочется еще раз сменить тему?
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кажется, причина разногласий становится понятной. Говоря "жесткое" я подразумевал
Жёсткое реальное время (формально) — это реакция должна быть ганантированно выдана в течение заданного промежутка времени (вариант — строго по истечению заданного промежутка времени)
Вы же и eao197 использовали другую трактовку
Жёсткое реальное время — это жёсткое реальное время в формальном смысле + времена реакции порядка микросекунд или же такая вычислительная нагрузка, которая на пределе (очень хорошо оптимизированная) укладывается в заданное время
Понятно, что во втором случае использование сборки мусора более проблематично.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, AndreyFedotov, Вы писали:
Т>Кажется, причина разногласий становится понятной. Говоря "жесткое" я подразумевал Т>
Жёсткое реальное время (формально) — это реакция должна быть ганантированно выдана в течение заданного промежутка времени (вариант — строго по истечению заданного промежутка времени)
Т>Вы же и eao197 использовали другую трактовку Т>
Жёсткое реальное время — это жёсткое реальное время в формальном смысле + времена реакции порядка микросекунд или же такая вычислительная нагрузка, которая на пределе (очень хорошо оптимизированная) укладывается в заданное время
Т>Понятно, что во втором случае использование сборки мусора более проблематично.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Как ты думаешь, гарантированно выдавать результат перемножения двух матриц 1000x1000 из комплексных чисел с темпом 50Hz и 500Hz одинаково просто? На одном и том же железе?
VD>Сложность тут не имеет никакого значения. Ты еще не забыл что тут осбуждается? Или хочется еще раз сменить тему?
Влад, по моему тему хочется сменить тебе. Одним полушарием ты понимаешь, что если между двумя прерываниями идёт 100 тактов (вот уж реальное время — дальше некуда), то за это время собрать мусор абсолютно не реально. А другим полушарием при этом веруешь что сборщик мусора лучше, чем его отсутствие, ибо таков твой опыт при написании достаточно сложного и вероятно производительного софта
Но это же просто разные области...
Здравствуйте, VladD2, Вы писали:
A>>Вообще-то моя реплика была направлена на "Ну, нет у меня задач где требовалось бы реальное время.".
VD>И гед в Янусе необходимость в релном времени? Или ты еще один кто не понимает смысла этого термина?
А я вот чувствую необходимость в этом "реальном времени", потому как сейчас оно охренеть какое "нереальное". Меня, да и, наверное, многих, не устраивает его время отклика.
Вообще, Влад, немного с юмором посмотри и поймешь, что я хотел сказать.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Sonata Arctica — Revontulet";
Здравствуйте, eao197, Вы писали:
E>А где, кстати, можно прочитать, что XO/2 или XOberon используют сборку мусора в hard realtime режимах?
Прочитать не так то просто. Они убрали со своего сайта всю информацию.
Насколько я помню, все процессы в XO/2 делятся на "задачи" (управляемые по deadline) и "нити" (управляемые приоритетами без временных гарантий). Куча – одна на всех и управляется сборщиком мусора, работающим в фоновом режиме.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>А где, кстати, можно прочитать, что XO/2 или XOberon используют сборку мусора в hard realtime режимах?
Т>Прочитать не так то просто. Они убрали со своего сайта всю информацию. Т>Насколько я помню, все процессы в XO/2 делятся на "задачи" (управляемые по deadline) и "нити" (управляемые приоритетами без временных гарантий). Куча – одна на всех и управляется сборщиком мусора, работающим в фоновом режиме.
Я потому и спрашивал, что ни по XO/2, ни по XOberon технической информации с ходу не нашел.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ansi, Вы писали:
A>А я вот чувствую необходимость в этом "реальном времени", потому как сейчас оно охренеть какое "нереальное". Меня, да и, наверное, многих, не устраивает его время отклика.
Ты в очередной раз уводишь тему разговора. В Янусе никогда не будет реального времени так как он работает на ОС не поддерживающей это самое реальное время и на аналогичном фрэймворке. И это положение вещей не изменится даже если он будет визуально летать как трофейный мессер.
A>Вообще, Влад, немного с юмором посмотри и поймешь, что я хотел сказать.
Я не понимаю такого юмора. Да и судя по отсуствию смайликов никто не понимает. А вот в серьез похоже кое-кто твои слова принимает.
ЗЫ
Что же до тормозов Януса, то как я уже не раз говорил в том есть две причины. Одна — это джет. Вторая это очень уж разная квалификация программистов. Которые, порой, выбирают не адекватные решения. Сейчас ИТ работает над версией для MSSQL. Думаю, что после того как переход закончится и как будет время мы оптимизируем работу с БД и тормоза уйдут в прошлое.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
E>>Так что очевидные вещи доказывать, обычно не нужно. А вот GC и реальное время -- это далеко не очевидная, имхо, вещь.
Т>Почему-то этот тезис о невозможности использования GC в реальном времени выдвигается как очевидный. А ведь его надо доказывать. Вместо этого, предлагается его опровергнуть.
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote:
>> Т>Почему-то этот тезис о невозможности использования GC в реальном >> времени выдвигается как очевидный. А ведь его надо доказывать. Вместо >> этого, предлагается его опровергнуть. >> Флейма развели, как дети малые. Google: hard real-time garbage >> collection >> <http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=DVXA,DVXA:2005-20,DVXA:en&q=hard+real%2Dtime+garbage+collection> >> Вопросы есть? Вопросов нет. И все, нечего спорить.
C>В первой же ссылке написано, что требуется достаточно большой оверхед по C>памяти...
Цитирую Трурля. "Почему-то этот тезис о невозможности использования GC в реальном
времени выдвигается как очевидный."
Возможно применять GC для систем hard-realtime? Да, возможно.
Есть на эту тему работы? Есть, множество, как теоретических так и практических.
Влияет ли "оверхэд по памяти" и прочие подобные характеристики на принципиальную возможность применения GC в hard-realtime? Нет, не влияет, и работающие реализации тому живой пример.
Здравствуйте, Gaperton, Вы писали:
G>Возможно применять GC для систем hard-realtime? Да, возможно.
Если под hard-real time понимать системы жёсткого реального времени со временем реакции более миллисекунд (на процессорах класса PIV/PowerPC), то это вполне возможно, о чём и писали неоднократно.
G>Есть на эту тему работы? Есть, множество, как теоретических так и практических. G>Влияет ли "оверхэд по памяти" и прочие подобные характеристики на принципиальную возможность применения GC в hard-realtime? Нет, не влияет, и работающие реализации тому живой пример.
2·winc·Pmax = 2·80·6 = 960 instructions of garbage collector work per allocation of one block. But this improvement in worst-case performance comes at a high cost in average-case performance, ignoring the actual memory usage of the application.
Furthermore, if the application exceeds the limit on the amount of reachable memory only slightly, the system might fail to recycle sufficient memory.
Добавлю, что пример достаточно простенький, далеко не самый напряжный, притом пример выделения памяти. И уже 1000 инструкций, что при работе с памятью выливается в ещё большее количество таков То есть при частоте в 1 ГГц только на выделение блока памяти уйдёт 1 мкс. Вот теперь и оцените время реакции...
Из описанного выше очевидно, что использование GC можно начинать (при современных процессорах) при времени реакции свыше 100 мкс (1..4 x 10^5 инструкций), по мере развития процессоров эта планка будет опускаться
Gaperton wrote:
> C>В первой же ссылке написано, что требуется достаточно большой > оверхед по > C>памяти... > Цитирую Трурля. "Почему-то этот тезис о *невозможности *использования > GC в реальном > времени выдвигается как очевидный." > Возможно применять GC для систем hard-realtime? Да, возможно.
Возможно ли прямо сейчас запустить человека на Марс? Возможно.
Практично? Нет, не практично.
> Есть на эту тему работы? Есть, множество, как теоретических так и > практических. > Влияет ли "оверхэд по памяти" и прочие подобные характеристики на > принципиальную возможность применения GC в hard-realtime? *Нет, не > влияет, и работающие реализации тому живой пример.*
Да, но не стоит забывать о практичности — в некоторых случаях (типа
_постоянной_ активности мусорогенерирующего кода) оверхед может
оказаться слишком большим, чтобы быть практичным.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Gaperton, Вы писали:
G>>Возможно применять GC для систем hard-realtime? Да, возможно. AF> Если под hard-real time понимать системы жёсткого реального времени со временем реакции более миллисекунд (на процессорах класса PIV/PowerPC), то это вполне возможно, о чём и писали неоднократно.
Под hard-realtime понимается только 100% гарантированное время реакции. И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования. С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта:
1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога.
2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Здравствуйте, Gaperton, Вы писали:
G>Под hard-realtime понимается только 100% гарантированное время реакции.
Это только формальное определение. G>И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования.
А вот и нет. Любой инженер знает какая гиганская разница 1 МГц или 1 ТГц Это совершенно разные технологии...
Потому и разница во времени не существенна лишь до некоторого предела. 10 мс это 1-4x10^7 тактов, а 10 нс это всего 10-40 тактов
G>С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта: G>1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога. G>2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
G>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Это всё теория — модель. Притом модель не учитывающая множество факторов.
Да, теоретически всё выглядит просто, пока времена переключения на интервал и минимальный интервал, который можно выделить умещаются в заданный интервал времени. Но ведь дальше возникают другие вопросы — например сколько вычислительных ресурсов тратит та или иная технология (если сборка мусора будет потреблять половину ресурсов — то кому она нужна)? Каков резерв по времени на выполнение задач?
В теории очень красиво "Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования", а на практике начиная с некоторой частоты стоимость оборудования начинает расти по экспоненте.
Потому сторонникам применения GC в hard real time — стоит понимать — о каких конкретно системах идёт речь — контекст применимости предлагаемой технологии. Смешно то, что с Вами согласны и подробно описывают этот контекст.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Gaperton, Вы писали:
G>>>Возможно применять GC для систем hard-realtime? Да, возможно. AF>> Если под hard-real time понимать системы жёсткого реального времени со временем реакции более миллисекунд (на процессорах класса PIV/PowerPC), то это вполне возможно, о чём и писали неоднократно.
G>Под hard-realtime понимается только 100% гарантированное время реакции. И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно,
Это не просто важно, а принципиально важно, поскольку отталкиваясь от этих цифр выбирается стратегия решения задачи.
Вплоть до изготовления FPGA или даже специализированной микросхемы.
G>эти аспекты определяются свойствами задачи и оборудования. С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта: G>1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога. G>2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
G>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Здравствуйте, Шахтер, Вы писали:
Ш>Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
G>>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Ш>А может, мы просто лучше понимаем предмет?
Пока больше похоже на то, что вы не отдаете себе отчета в том, что говорите. Что вы хотите сказать — понятно, но фактически говорите вы совершеннейшую ерунду (и еще упираетесь). Тезис "не нужен GC в real-time системах" общий (следить надо за тем, что говоришь), и поэтому опровергается единственным контрпримером.
Я его в очередной раз приведу — самый производительный и надежный в мире (на момент выпуска) ATM softswitch/media gateway AXD301 является soft-realtime системой и создан на платформе Erlang/OTP, где пямятью управляет GC реального времени. Разработка обошлась в четверо дешевле чем аналогичная попытка на С++, и в отличии от последней завершилась успехом.
В компании Ericsson вам в ответ на рассуждения в духе "не нужен GC в real-time системах" рассмеются в лицо. Ваше же разделение на "настоящий" и якобы "не настоящий" рилтайм — выдумка. То, что в микроконтроллерах глупо применять GC, это и ежу понятно, и не надо делать вид, что вы единственные в мире, кто это понимает.
Здравствуйте, Шахтер, Вы писали:
Ш>Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
Ш>А может, мы просто лучше понимаем предмет?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Шахтер, Вы писали:
Ш>>Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
G>>>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Ш>>А может, мы просто лучше понимаем предмет? G>но фактически говорите вы совершеннейшую ерунду (и еще упираетесь). Тезис "не нужен GC в real-time системах" общий (следить надо за тем, что говоришь), и поэтому опровергается единственным контрпримером.
Золотые слова
G>Я его в очередной раз приведу — самый производительный и надежный в мире (на момент выпуска) ATM softswitch/media gateway AXD301 является soft-realtime системой и создан на платформе Erlang/OTP, где пямятью управляет GC реального времени. Разработка обошлась в четверо дешевле чем аналогичная попытка на С++, и в отличии от последней завершилась успехом.
Да, об этом говорили уже раз двадцать.
G>В компании Ericsson вам в ответ на рассуждения в духе "не нужен GC в real-time системах" рассмеются в лицо. Ваше же разделение на "настоящий" и якобы "не настоящий" рилтайм — выдумка. То, что в микроконтроллерах глупо применять GC, это и ежу понятно, и не надо делать вид, что вы единственные в мире, кто это понимает.
Вот и я не понимаю о чём мы спорим? Вроде бы все согласились с тем, что есть системы реального времени, в том числе и жёсткого РВ, где GC успешно применяется. Так же все понимают, что есть определённые ограничения на применения GC в СРВ и в тех системах, которые выходят за рамки этих ограничений — GC не применим. Вроде бы и с этим все согласны — даже Влад, а это само по себе многово значит...
Так о чём спор то? Я ещё понимаю, если бы мы посчитали, сколько ресурсов требует тот или иной GC и соответственно определили бы границы применимости (в том числе и применимость GC на микроконтроллерах, где он прекрасно применяется...) Кстати можно было бы определить требования к железу для применения Java или C# в СРВ
Так нет же, все понимают, что имеется в виду, но вместо того, что бы сотрудничать с огромным наслаждением цепляются к словам и делают друг-другу комплименты... Или в этом и заключается смысл общения на форуме?
Здравствуйте, AndreyFedotov, Вы писали:
AF> Так нет же, все понимают, что имеется в виду, но вместо того, что бы сотрудничать с огромным наслаждением цепляются к словам и делают друг-другу комплименты... Или в этом и заключается смысл общения на форуме?
Конечно, я понимаю, что имеется в виду. Вот Шахтер, например, пишет: "А может, мы просто лучше понимаем предмет?" Он имеет в виду, что у него длиннее, или я неправ? И вот что забавно, ему вы ставите оценку "супер!", из чего я заключаю, что вы с ним согласны . Теперь давайте вернемся к вопросу — ну и в чем у нас заключается истинный смысл общения на форуме?
Здравствуйте, Gaperton, Вы писали:
G>>>Возможно применять GC для систем hard-realtime? Да, возможно. AF>> Если под hard-real time понимать системы жёсткого реального времени со временем реакции более миллисекунд (на процессорах класса PIV/PowerPC), то это вполне возможно, о чём и писали неоднократно.
G>Под hard-realtime понимается только 100% гарантированное время реакции. И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования. С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта: G>1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога. G>2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
G>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Не совсем так. Под требования hard-realtime попадает еще и приоритетность. Т.е. при появлении более приоритетного прерывания или выхода из спячки более приоритетного процесса/нити должно быть гарантировано переключение на этот более высокоприоритетный процесс с заданной задержкой. И вот здесь к GC возникает еще один вопрос:
3) Можно ли прервать процедуру GC более высокоприоритетной задачей за гарантированное время? Причем так, чтобы прервавшая GC задача не уснула затем из-за того, что не может выделить себе память, чисткой которой занимался GC?
Здравствуйте, Gaperton, Вы писали:
G>Цитирую Трурля. "Почему-то этот тезис о невозможности использования GC в реальном G>времени выдвигается как очевидный."
Просто для составления объективного мнения: тебе самому приходилось разрабатывать системы реального времени? И если да, и это не секретная информация, то с каким темпом и на каком железе (по мощности) там шла работа.
По поводу следующих твоих тезисов я позволю себе несколько аналогий.
G>Возможно применять GC для систем hard-realtime? Да, возможно.
Возможно ли применять ассемблер для написания программ? Да, возможно.
G>Есть на эту тему работы? Есть, множество, как теоретических так и практических.
Тоже самое по отношению к ассемблеру.
G>Влияет ли "оверхэд по памяти" и прочие подобные характеристики на принципиальную возможность применения GC в hard-realtime? Нет, не влияет, и работающие реализации тому живой пример.
Влияет ли "оверхэд по трудозатратам" и прочие подобные характеристики на принципиальную возможность применения ассемблера для разработки ПО. Нет, не влияет, и работающие реализацию тому живой пример.
Только почему же сейчас 99.9% процента ПО разрабатывается не на ассемблере?
Я это к тому, что от единичных опытов к повсеместному применению, да еще в жестких условиях, очень длинный путь. Я согласен с тем, что с развитием технологий GC будет проникать в real-time все больше и больше. Тем не менее, по моему скромному мнению, до обыденного, повсеместного использования GC в real-time (особенно в жестком real-time) еще не скоро.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Так нет же, все понимают, что имеется в виду, но вместо того, что бы сотрудничать с огромным наслаждением цепляются к словам и делают друг-другу комплименты... Или в этом и заключается смысл общения на форуме?
G>Конечно, я понимаю, что имеется в виду. Вот Шахтер, например, пишет: "А может, мы просто лучше понимаем предмет?" Он имеет в виду, что у него длиннее, или я неправ? И вот что забавно, ему вы ставите оценку "супер!", из чего я заключаю, что вы с ним согласны . Теперь давайте вернемся к вопросу — ну и в чем у нас заключается истинный смысл общения на форуме?
О да. Шахтёр крепкий мужик и я соответсвенно был в восторге именно от этой части его послания.
И разумеется я совершенно не обратил внимание на первую — содержательную часть.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Цитирую Трурля. "Почему-то этот тезис о невозможности использования GC в реальном G>>времени выдвигается как очевидный."
E>Просто для составления объективного мнения: тебе самому приходилось разрабатывать системы реального времени? И если да, и это не секретная информация, то с каким темпом и на каком железе (по мощности) там шла работа.
Только soft-realtime. Автоматические торговые системы, время реакции — чем быстрее тем лучше, обычно речь идет о миллисекундах и их десятках. Железо обычное. В добавок, в общих чертах знаком с техникой программирования микроконтроллеров, разработкой планировщиков задач для операционных систем реального времени, и с soft-realtime платформой Erlang. Кстати, а почему вы спрашивате? Давеча вы в ответ на такой вопрос сказали:
А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"
E>По поводу следующих твоих тезисов я позволю себе несколько аналогий. G>>Возможно применять GC для систем hard-realtime? Да, возможно. E>Возможно ли применять ассемблер для написания программ? Да, возможно.
Гхм . Без обид, но ты это в серьез, или хочешь разрядить обстановку? Ты хорошо над аналогией подумал-то? Если ты автоматическое управление памятью сравниваешь с программированием на ассемблере, то работе без GC, надо полагать, соответствует программирование посредством перетыкания перемычек, да?
Твоя аналогия некорректна, поскольку наличие GC упрощает разработку, в то время как программирование на ассемблере ее усложняет. Замечу, что заставляя разъяснять тебе такую элементарщину, ты ставишь меня в неудобное положение. Я теперь не знаю, что и думать.
E>Я это к тому, что от единичных опытов к повсеместному применению, да еще в жестких условиях, очень длинный путь. Я согласен с тем, что с развитием технологий GC будет проникать в real-time все больше и больше. Тем не менее, по моему скромному мнению, до обыденного, повсеместного использования GC в real-time (особенно в жестком real-time) еще не скоро.
Ага. Один-два года. Столько надо подождать, когда утвердят JSR для hard-realtime, на который ссылался Влад, и появятся реализации. И все. JFYI, факт наличия hard-realtime JSR автоматически означает наличие инициативной группы из нескольких крупных производителей hard real-time решений, и об их намерении в скором времени задействовать эту технологию, поскольку они чувствуют потребность в ней.
E>Кстати, ты высказался о том, что мы здесь флейм развели. А вот конкретно по вот этому моему высказыванию
В тех системах реального времени, с которыми я сталкивался, память не освобождалась и не перевыделялась.
Это, очевидно, были достаточно простые системы. В любой операционной системе реального времени приложения могут выделять память динамически. Даже в твоем приложении — дальше ты описываешь устройство встроенного в программу специализированного хип-манагера. "Нет смысла применять malloc/free, потому что у нас эти вызовы называются по другому и мы сами управляем своим собственным хипом".
Нет смысла здесь применять malloc/free или GC потому, что при смене указателя буфера не оказываются свободными -- вот ведь в чем фокус.
И еще по поводу использования динамически выделяемой/освобождаемой памяти в задачах реального времени. На знаю, как ситуация будет обстоять сейчас, с развитием lock-free алгоритмов, но раньше вызов malloc/free (new/delete) блокировал mutex... итд, итп, etc...
Процедуры malloc/free в современных аллокаторах занимают несколько машинных инструкций. Техника называется slab-allocator. Можно и подождать, никто не умрет. Это раз.
В Erlang/OTP у потоков нет разделяемой памяти, они обмениваются сообщениями. Это два, просто намек на тему, как по разному может быть устроен рантайм. Например — так, что проблема о которой ты говоришь, в принципе не стоит.
...А ведь ОСРВ как раз отличаются от ОС общего назначения тем, что они очень строго гарантируют приоритетность задач и очень малое время переключения на задачи с более высокими приоритетами. И вот в такую тонкую кухню запустить GC, который живет по свои законам и, мягко говоря, плюет на весь остальной процесс и его приоритеты?..
Знаешь, QNX-у и VxWorks-у хуже не станет от того, что в каком-то процессе у них real-time GC крутиццо. Им на это плевать с высокой колокольни, они за своей тонкой кухней этого просто не заметят.
Извини, теперь у меня к тебе вопрос. Для составления объективного мнения. Ты хоть что-нибудь про GC для real-time читал? Может быть, хотя бы одну работу на эту тему? Хотя бы по одной ссылке, что тебе давали, ходил? Или до всего, так сказать, своим умом дошел?
Здравствуйте, Gaperton, Вы писали:
E>>Просто для составления объективного мнения: тебе самому приходилось разрабатывать системы реального времени? И если да, и это не секретная информация, то с каким темпом и на каком железе (по мощности) там шла работа.
G>Только soft-realtime. Автоматические торговые системы, время реакции — чем быстрее тем лучше, обычно речь идет о миллисекундах и их десятках. Железо обычное. В добавок, в общих чертах знаком с техникой программирования микроконтроллеров, разработкой планировщиков задач для операционных систем реального времени, и с soft-realtime платформой Erlang. Кстати, а почему вы спрашивате? Давеча вы в ответ на такой вопрос сказали: G>
G>А почему такой переход на личности сразу? Типа: "Cам писал? Нет! Вот и не говори ничего"
Ну, если ты нашел эту цитату, то должен был узнать, чем там все закончилось. Для менее искушенных читалей я приведу и ответ Игоря Ткачева, который показался мне очень адекватным:
Как раз ничего личного. Просто мне интересно и более важно мнение людей, которые лично делали то о чём говорят, а не просто теоретизируют на заданную тему.
Именно с таких позиций я и спрашивал о твоем опыте.
Я, кстати, так же не имел опыта работы с real-time меньше десятка миллисекунд. Правда тогда речь шла о машинах класса AMD k6-350.
В основном это были задачи мягкого реального времени, но была и парочка с жестким временем (именно в смысле гарантированности).
Тем не менее, поскольку приходилось заниматься созданием SCADA инструмента, то представление о том, что такое мягкое время, что такое жесткое время, что значит приоритетность и т.п. пришлось уразуметь. Но за прошедшие с того времени пять лет я мог много чего позабыть.
E>>По поводу следующих твоих тезисов я позволю себе несколько аналогий. G>>>Возможно применять GC для систем hard-realtime? Да, возможно. E>>Возможно ли применять ассемблер для написания программ? Да, возможно. G>Гхм . Без обид, но ты это в серьез, или хочешь разрядить обстановку?
Имено что бы обстановку разрядить.
А то там у вас с Шахтером чуть разборки не начались.
Кстати, если продолжить юмористическую ноту, то чем бы вы мерялись, если бы за никами eao197, Шахтер или Gaperton девушка скрывалась? Что бы тогда сравнивали? Длину с глубиной или ширину с толщиной?
E>>Я это к тому, что от единичных опытов к повсеместному применению, да еще в жестких условиях, очень длинный путь. Я согласен с тем, что с развитием технологий GC будет проникать в real-time все больше и больше. Тем не менее, по моему скромному мнению, до обыденного, повсеместного использования GC в real-time (особенно в жестком real-time) еще не скоро.
G>Ага. Один-два года. Столько надо подождать, когда утвердят JSR для hard-realtime, на который ссылался Влад, и появятся реализации. И все. JFYI, факт наличия hard-realtime JSR автоматически означает наличие инициативной группы из нескольких крупных производителей hard real-time решений, и об их намерении в скором времени задействовать эту технологию, поскольку они чувствуют потребность в ней.
Может я сейчас еще раз одну неудачную аналогию приведу, но вот языки со сборкой мусора давно в ходу. Даже Java уже десять лет. И при этом повсеместного засилья GC нет. Как программировали требовательные к скорости и ресурсоемкости решения на C/C++, так и программируют. И те кто это делает (и я, в частности) плюет на GC с большой колокольни. И особой потребности не испытывают. Потому что в оплату трудоемкости получают предсказуемость.
Мне тут недавно знакомые интересную байку разсказали. Установили одному крупному заказчику Java-решение (все как полагается, EJB от WebLogic, 14 серверов от Sun). Да только узлы кластера стали подвисать ни с того, ни с сего. И ни Sun-овцы, ни WebLogic-овцы, ни разработчики ничего понять не могут (а там все по взрослому было, реальных спецов вызывали). И кончилось все тем, что в это приложение встроили принудительный запуск GC по таймеру. После этого ни одного зависания.
E>>Кстати, ты высказался о том, что мы здесь флейм развели. А вот конкретно по вот этому моему высказыванию
у тебя есть возражения?
G>Прокомментирую по поводу содержательной части.
G>
G>В тех системах реального времени, с которыми я сталкивался, память не освобождалась и не перевыделялась.
G>Это, очевидно, были достаточно простые системы.
Для меня это было не очевидно. Пять или шесть процессов. Несколько типов заявок, для каждой из которых должен выбираться свой процесс. Сетевой обмен. Большие математические расчеты. Подключенные через PCI спецвычислители. В общем не просто было.
G> В любой операционной системе реального времени приложения могут выделять память динамически. Даже в твоем приложении — дальше ты описываешь устройство встроенного в программу специализированного хип-манагера. "Нет смысла применять malloc/free, потому что у нас эти вызовы называются по другому и мы сами управляем своим собственным хипом".
Принципиальный момент в том, что не было у нас ни хип-менеджера, ни своих аналогов malloc/free. Было понятие текущего рабочего буфера у каждого рабочего процесса. А менеджер процессов, который расписание их работы в зависимости от поступающих заявок составлял, просто циклически заменял рабочие буфера.
G>
G>И еще по поводу использования динамически выделяемой/освобождаемой памяти в задачах реального времени. На знаю, как ситуация будет обстоять сейчас, с развитием lock-free алгоритмов, но раньше вызов malloc/free (new/delete) блокировал mutex... итд, итп, etc...
G>Процедуры malloc/free в современных аллокаторах занимают несколько машинных инструкций. Техника называется slab-allocator. Можно и подождать, никто не умрет. Это раз.
Был у меня один такой раз. В системе мягкого реального времени. Иногда нить с высоким приоритетом почему-то останавливалась, а работу продолжала нить с менее низким приоритетом. Чем, естественно, портила всю картину происходящего. Потом оказалось, что все дело было в третьей нити, с еще более низким приоритетом, которая успевала в new зайти, а затем прерывалась высокоприоритетным прерыванием.
G>В Erlang/OTP у потоков нет разделяемой памяти, они обмениваются сообщениями. Это два, просто намек на тему, как по разному может быть устроен рантайм. Например — так, что проблема о которой ты говоришь, в принципе не стоит.
Ну и ради бога. Но если мы говорим о системах, в которых Erlang-а просто нет, а есть один лишь malloc/free (new/delete), который к тому же память у ОС запрашивает, то будет то, о чем я и говорил.
G>
G>...А ведь ОСРВ как раз отличаются от ОС общего назначения тем, что они очень строго гарантируют приоритетность задач и очень малое время переключения на задачи с более высокими приоритетами. И вот в такую тонкую кухню запустить GC, который живет по свои законам и, мягко говоря, плюет на весь остальной процесс и его приоритеты?..
G>Знаешь, QNX-у и VxWorks-у хуже не станет от того, что в каком-то процессе у них real-time GC крутиццо. Им на это плевать с высокой колокольни, они за своей тонкой кухней этого просто не заметят.
Пусть так. Но вот что делать тому процессу, у которого GC крутится? Что, если это ему высокоприоритетное прерывание адресуется? Что ему со своим GC делать?
G>Извини, теперь у меня к тебе вопрос. Для составления объективного мнения. Ты хоть что-нибудь про GC для real-time читал? Может быть, хотя бы одну работу на эту тему? Хотя бы по одной ссылке, что тебе давали, ходил?
По тем, что в начале развития темы давали ходил. Про XO/2 (или это был XOberon) читал. По последним сходил, скачал пару PDF, но пока не было времеми прочитать внимательно (мы тут с ПК в соседней теме более актуальную для меня сейчас тему обсуждаем -- Re[17]: Checked exceptions... зло или добро?
-- те ссылки, которые там Паша дает для меня более приоритетны сейчас). И вообще, чукча не читатель -- чукча писатель
G> Или до всего, так сказать, своим умом дошел?
А своим уже нельзя?
На самом деле нет. Это все в памяти отложилось в далеких 90-х годах, когда я у более старших товарищей выяснял, почему они в своих задачах работают с заранее выделенными буферами, а не пользуют new/delete по необходимости.
Так что я не то, чтобы ортодоксальный противник GC в real-time. Просто скепсиса во мне много. А все, что сторонники GC делают -- так это ссылки на что-то приводят. А вот на пальцах объяснить, как же это все будет работать... Чтобы без чтения 20-страничного англицкого документа понять можно было. Вот бы чего увидеть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Шахтер, Вы писали:
Ш>>Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
G>>>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Я же не сказал -- нельзя. Я сказал -- не нужно. Конечно, если очень хочется, то можно, но зачем? По приколу?
Ш>>А может, мы просто лучше понимаем предмет? G>Пока больше похоже на то, что вы не отдаете себе отчета в том, что говорите. Что вы хотите сказать — понятно, но фактически говорите вы совершеннейшую ерунду (и еще упираетесь). Тезис "не нужен GC в real-time системах" общий (следить надо за тем, что говоришь), и поэтому опровергается единственным контрпримером.
G>Я его в очередной раз приведу — самый производительный и надежный в мире (на момент выпуска) ATM softswitch/media gateway AXD301 является soft-realtime системой и создан на платформе Erlang/OTP, где пямятью управляет GC реального времени. Разработка обошлась в четверо дешевле чем аналогичная попытка на С++, и в отличии от последней завершилась успехом.
Это не контрпример. Это набор утверждений, в справедливости которых ещё надо убедится, поскольку они сильно смахивают на рекламные лозунги.
Но даже если принять это всё за чистую монету, то выводы из этих фактов можно сделать совсем другие -- программисты Ericsson просто оказались не готовы к использованию C++, и выбрали платформу попроще и попонятнее для них. Но чудес на свете не бывает и за всё надо платить. Какую цену в смысле производительности они заплатили -- я не знаю. И без детального анализа данного изделия это сказать невозможно.
G>В компании Ericsson вам в ответ на рассуждения в духе "не нужен GC в real-time системах" рассмеются в лицо.
Да хоть в яйца. Не надо пытаться давить на меня авторитетом компании. Я хорошо знаю изнанку крупных компаний, и что они скрывают за рекламными лозунгами.
Говорят, если знать как и из чего делают колбасу, то есть её становиться стрёмно.
G>Ваше же разделение на "настоящий" и якобы "не настоящий" рилтайм — выдумка.
Да нет, это не выдумка. Установим время реакции 1 год -- и тогда все системы можно будет обозвать как хард-рилтаймовые.
Определение рилтаймовой системы, как системы с требованием уложится в заданное време реакции не точно. Я бы даже сказал, вводящее в заблуждение.
Более точное определениею -- это система, требующая тщательного планирования использования такого ресурса, как время.
Программирование как работа в значительной степени -- это планирование, в том числе и планирование использование ресурсов.
Рилтаймовые системы -- это такие системы, в которых наиболее ценным ресурсом является время. Иногда не посто ценным, а критическим.
Поэтому в таких системах при их разработке необходимо тщательно планировать время жизни тех или иных объектов (если вести разговор в терминах объектно-ориентированного программирования). Соответственно, применение GC становится с одной стороны избыточным, а с другой -- просто опасным.
Поскольку содержит неконтролируемый элемент в себе. Вообщем -- очередная попытка забить шуруп молотком.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Шахтер, Вы писали:
Ш>>Важно не летать из Москвы в Питер через Вашингтон. Не нужен GC в real-time системах. Не в абстрактных, а в реальных. Да и вообще в программировании он нужен только для ограниченного круга задач, которые к задачам, решаемым при разработке real-time систем имеют касательное отношение.
Ш>>А может, мы просто лучше понимаем предмет?
AL>http://www.aicas.com/publications.html
Чтобы долго не разводить дискуссию на тему -- самый лучший способ добиться гарантированного времени отклика, это использовать такие технологии программирования. которые обеспечивают более высокую производитьность результирующего кода. И не использовать тех приёмов и конструкций, добиться от которых хорошей производительности трудно или невозможно в силу их природы. Т.е. заниматься рилтаймом на Яве можно конечно, но это забивание шурупа молотком. Тем более, что как язык Ява значительно уступает С++ в выразительной силе -- нет ради чего стоит прилагать усилия.
Здравствуйте, Шахтер, Вы писали:
AL>>Здравствуйте, Шахтер, Вы писали:
AL>>http://www.aicas.com/publications.html
Ш>Чтобы долго не разводить дискуссию на тему -- самый лучший способ добиться гарантированного времени отклика, это использовать такие технологии программирования. которые обеспечивают более высокую производитьность результирующего кода. И не использовать тех приёмов и конструкций, добиться от которых хорошей производительности трудно или невозможно в силу их природы. Т.е. заниматься рилтаймом на Яве можно конечно, но это забивание шурупа молотком. Тем более, что как язык Ява значительно уступает С++ в выразительной силе -- нет ради чего стоит прилагать усилия.
Об отношении понятий "производительность" и "timeliness" говорилось выше, думаю, не стоит повторяться. Следуя же Вашей логике, разработка встраиваемого ПО РВ должна выполняться в машинных кодах (а лучше на VHDL для больших матриц) строго под конкретную задачу и под конкретное железо без малейших попыток использовать существующие ОСРВ. Знаете, во что выливается корректная реализация, скажем, алгоритма Priority Inheritance (весьма популярный buzzword) в ОСРВ? Айкасовский GC с его гарантированными 150 мкс будет выглядеть феррари против запорожца.
E>Мне тут недавно знакомые интересную байку разсказали. Установили одному крупному заказчику Java-решение (все как полагается, EJB от WebLogic, 14 серверов от Sun). Да только узлы кластера стали подвисать ни с того, ни с сего. И ни Sun-овцы, ни WebLogic-овцы, ни разработчики ничего понять не могут (а там все по взрослому было, реальных спецов вызывали). И кончилось все тем, что в это приложение встроили принудительный запуск GC по таймеру. После этого ни одного зависания.
Чуть-чуть офтоп
То, что ты описал, от того, что GC почти нельзя из самой программы порулить. Например, в VW ST существует возможность подключать свои политики, которые в зависимости от определённых условий будут вызывать разные сборщики мусора.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Об отношении понятий "производительность" и "timeliness" говорилось выше, думаю, не стоит повторяться. Следуя же Вашей логике, разработка встраиваемого ПО РВ должна выполняться в машинных кодах (а лучше на VHDL для больших матриц) строго под конкретную задачу и под конкретное железо без малейших попыток использовать существующие ОСРВ. Знаете, во что выливается корректная реализация, скажем, алгоритма Priority Inheritance (весьма популярный buzzword) в ОСРВ? Айкасовский GC с его гарантированными 150 мкс будет выглядеть феррари против запорожца.
Александр, я вижу, что с айкасовским GC знаком. А этот GC метод finalize() у убираемых объектов вызывает?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, A.Lokotkov, Вы писали:
E>Александр, я вижу, что с айкасовским GC знаком. А этот GC метод finalize() у убираемых объектов вызывает?
Знаком пока только по материалам. Финализаторы вызываются только у объектов, созданных в ScopedMemory, -- памяти для объектов с ограниченным временем жизни. Realtime-потоки при этом могут вытеснять GC. При этом rt-потоки, по идее, должны оперировать объектами с неограниченным временем жизни (распределенными в ImmortalMemory). Это отвечает практическим нуждам. Однако эту систему, конечно же, легко завалить, как и любую другую, не имеющую координационного слоя.
Здравствуйте, Шахтер, Вы писали:
Ш>Это не контрпример. Это набор утверждений, в справедливости которых ещё надо убедится, поскольку они сильно смахивают на рекламные лозунги.
Ну конечно. Все вокруг врут, а ты один тут правду говоришь. Обвиняешь меня в намеренном вранье, значит? За базар отвечать готов, или это у нас "как бы не считается"?
Ш>Но даже если принять это всё за чистую монету, то выводы из этих фактов можно сделать совсем другие -- программисты Ericsson просто оказались не готовы к использованию C++, и выбрали платформу попроще и попонятнее для них.
А может, у них всегда работали прекрасные инженеры, и Эриксон всегда являлся одной из самых открытых для технологических инноваций компаний? Может, Эрикссон уже 40+ лет выпускает телекоммуникационное оборудование? Может, они финансировали в 80-х специальную программу исследований на тему "как свойства языка влияют на надежность и стоимость создания телекомовских приложений"? Может, исследовательская группа сформулировала набор требований к языку нового поколения и сделала его прототип? Может, опытные инженеры из продакшн группы сочли этот язык очень более подходящим для задач телекома, и дали отмашку на разработку платформы?
Короче, может, ты не самый умный, и вокруг совсем не идиоты?
Ш>Но чудес на свете не бывает и за всё надо платить. Какую цену в смысле производительности они заплатили -- я не знаю. И без детального анализа данного изделия это сказать невозможно.
Ничего вы не знаете. Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
Поэтому этим людям я верю на слово (да им и соврать-то не дадут — враз репутацию потеряют), а вот принимать в серьез вас у меня оснований нет.
Ш>Поскольку содержит неконтролируемый элемент в себе. Вообщем -- очередная попытка забить шуруп молотком.
JFYI — инкрементальные GC не содержат в себе "неконтроллируемого элемента". Лучше бы вместо того, чтоб флеймить, занялся бы RTFM-ом на тему incremental GC и real-time GC.
Здравствуйте, Gaperton, Вы писали:
G>Ничего вы не знаете. Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
G>Поэтому этим людям я верю на слово (да им и соврать-то не дадут — враз репутацию потеряют), а вот принимать в серьез вас у меня оснований нет.
Разрешите вставить свои пять копеек.
Вот ты пишешь:
Я его в очередной раз приведу — самый производительный и надежный в мире (на момент выпуска) ATM softswitch/media gateway AXD301 является soft-realtime системой и создан на платформе Erlang/OTP, где пямятью управляет GC реального времени. Разработка обошлась в четверо дешевле чем аналогичная попытка на С++, и в отличии от последней завершилась успехом.
Просто меня смущает, что тебе возражают, в основном по поводу hard real-time, а ты в пример приводишь soft real-time систему с GC.
Ну и еще хочется спросить, а в Ericsson кроме AXD301 еще что-нибудь realtime-мовое на Erlang-е замутили?
Я знаю, что они пытались свой Parlay шлюз продвигать, часть которого работала на отдельных машинах под какой-то ОСРВ. Вот интересно, на чем он написан? У тебя случайно ссылок готовых нет?
/Я без ерничества и ехидства спрашиваю. Просто подумалось, что за последние пять лет, что я real-time не занимаюсь, ситуация могла сильно изменится. Мне интересно, насколько именно./
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Под hard-realtime понимается только 100% гарантированное время реакции. И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования. С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта: G>1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога. G>2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
G>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
Почему ответ на оба вопроса — можно? На конкретной железке, с конкретными минимальными интервалами и с конкретными прикладными алгоритмами ответ на второй вопрос никак не гарантируется.
Здравствуйте, Gaperton, Вы писали:
G>Ну конечно. Все вокруг врут, а ты один тут правду говоришь. Обвиняешь меня в намеренном вранье, значит? За базар отвечать готов, или это у нас "как бы не считается"?
Ш>>Но даже если принять это всё за чистую монету, то выводы из этих фактов можно сделать совсем другие -- программисты Ericsson просто оказались не готовы к использованию C++, и выбрали платформу попроще и попонятнее для них.
G>А может, у них всегда работали прекрасные инженеры, и Эриксон всегда являлся одной из самых открытых для технологических инноваций компаний? Может, Эрикссон уже 40+ лет выпускает телекоммуникационное оборудование? Может, они финансировали в 80-х специальную программу исследований на тему "как свойства языка влияют на надежность и стоимость создания телекомовских приложений"? Может, исследовательская группа сформулировала набор требований к языку нового поколения и сделала его прототип? Может, опытные инженеры из продакшн группы сочли этот язык очень более подходящим для задач телекома, и дали отмашку на разработку платформы?
blah-blah-blah...
Теперь посмотрим внимательней, о чем речь. Итак — телекоммуникационное оборудование. Основной задачей их приблуды — это управление пакетами данных. Это специфика №1, весьма важная. Из этой специфики вытекает другая специфика — необходимо наличие приличного объема ООП для кеширования пакетов. В свете рассматриваемого предмета — это еще более важная специфика, ибо для их условий — оверхед по памяти — не вопрос. (Интересно, сколько там ООП в их железке?)
Специфика №3 — основная функциональность (внутренняя) этой приблуды — выделять место под пакеты и затем освобождать. Причем, размер пакетов заранее не известен.
Специфика №4 — для телекоммуникационного оборудования гораздо важнее время реакции принимающей стороны. Прошу обратить на это внимание, ибо это напрямую связанно со спецификой №3 и характером работы GC как такового.
Специфика №5 — использование языка высокого уровня для "прикладной" логики. Вери велл... А на чем, извините, там написана "сердцевина" их приблуды — тот самый GC?
Собственно, ничего нового. Я сам не раз пропагандировал идею реализации технически сложных и низкоуровневых моментов на С/С++, а в качестве "клея", т.е. языка, выполняющего прикладной функционал — любой простой и подходящий, да хоть тот же VB.
--------
Скажу, что несоклько лет разрабатывал именно коммуникационное оборудование. Только оно разное бывает. В нашем случае у нас динамическое выделение памяти происходило крайне редко, в моменты инициализации связи. А потом использовались предвыделенные буферы под пакеты фиксированной длины. Собственно, на железках тех времен ни о каком GC не могло быть и речи, да и вообще не могло быть речи о постоянном динамическом выделении памяти, все алгоритмы вылизывались буквально до каждого такта.
Если сейчас мощности железок, а главное — стоимость этих железок позволяют писать хоть на VB + GC... Ну что ж... Значит спецы будут требоваться все меньше и меньше.
G>Короче, может, ты не самый умный, и вокруг совсем не идиоты?
Ш>>Но чудес на свете не бывает и за всё надо платить. Какую цену в смысле производительности они заплатили -- я не знаю. И без детального анализа данного изделия это сказать невозможно.
Ну заплатили, понятное дело. Просто эта цена падает год от года. Когда-то вопрос наличия лишнего метра статической памяти на свиче мог стоить лишние 20 баксов себестоимости. А последние лет несколько и динамическая по быстродействию и потреблению не уступает, к тому же — дешевле грязи. А всякие способы подключения по многобитным шинам позволяют напрямую загонять в нее данные прямо с адаптера волокна, уже успевает отрабатывать. Так что...
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Шахтер, Вы писали:
Ш>>Это не контрпример. Это набор утверждений, в справедливости которых ещё надо убедится, поскольку они сильно смахивают на рекламные лозунги.
G>Ну конечно. Все вокруг врут, а ты один тут правду говоришь. Обвиняешь меня в намеренном вранье, значит?
Я не обвиняю тебя в намеренном вранье -- я всего лишь тактично пытаюсь указать на контрпродуктивность ссылок на авторитеты.
G>Короче, может, ты не самый умный, и вокруг совсем не идиоты?
Скажем так. Я очень умный, а идиотов вокруг действительно хватает.
G>Ничего вы не знаете.
Да ну? Отвечаешь?
Вот свежий пример, что может скрываться за широко известной маркой. здесь
G>Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
Да? Я вот занимаюсь телекомом, но их имена не знаю. Как там? Чтобы опровергнуть общее утверждение достаточно одного контрпримера?
G>Поэтому этим людям я верю на слово (да им и соврать-то не дадут — враз репутацию потеряют), а вот принимать в серьез вас у меня оснований нет.
А у меня другой подход. Trust nobody, Mr. Malder.
Ш>>Поскольку содержит неконтролируемый элемент в себе. Вообщем -- очередная попытка забить шуруп молотком. G>JFYI — инкрементальные GC не содержат в себе "неконтроллируемого элемента". Лучше бы вместо того, чтоб флеймить, занялся бы RTFM-ом на тему incremental GC и real-time GC.
Вот когда мне действительно понадобиться в моей работе GC -- я им займусь. Но пока какой-либо необходимости привлекать GC я не встречал.
И ни одного аргумента, чем это мне может быть полезно, я пока не услышал.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Шахтер, Вы писали:
AL>>>Здравствуйте, Шахтер, Вы писали:
AL>>>http://www.aicas.com/publications.html
Ш>>Чтобы долго не разводить дискуссию на тему -- самый лучший способ добиться гарантированного времени отклика, это использовать такие технологии программирования. которые обеспечивают более высокую производитьность результирующего кода. И не использовать тех приёмов и конструкций, добиться от которых хорошей производительности трудно или невозможно в силу их природы. Т.е. заниматься рилтаймом на Яве можно конечно, но это забивание шурупа молотком. Тем более, что как язык Ява значительно уступает С++ в выразительной силе -- нет ради чего стоит прилагать усилия.
AL>Об отношении понятий "производительность" и "timeliness" говорилось выше, думаю, не стоит повторяться. Следуя же Вашей логике, разработка встраиваемого ПО РВ должна выполняться в машинных кодах (а лучше на VHDL для больших матриц) строго под конкретную задачу и под конкретное железо без малейших попыток использовать существующие ОСРВ.
Бывает, что ничего другого и невозможно сделать.
AL>Знаете, во что выливается корректная реализация, скажем, алгоритма Priority Inheritance (весьма популярный buzzword) в ОСРВ?
Знаю. Вот у меня на борде с vxWorks -- фактически ни во что. Разница в пределах погрешности измерения.
AL>Айкасовский GC с его гарантированными 150 мкс будет выглядеть феррари против запорожца.
А это уже дешёвая демагогия -- сравнение венерианского яблочного сока с марсианским пургеном.
Здравствуйте, Шахтер, Вы писали:
AL>>Здравствуйте, Шахтер, Вы писали:
AL>>>>Здравствуйте, Шахтер, Вы писали:
AL>>Знаете, во что выливается корректная реализация, скажем, алгоритма Priority Inheritance (весьма популярный buzzword) в ОСРВ?
Ш>Знаю. Вот у меня на борде с vxWorks -- фактически ни во что. Разница в пределах погрешности измерения.
В VxWorks, qnx, rtlinux и прочих коммерческих и полукоммерческих ОС реализации PIP некорректная. Почему?
Корректная реализация при каждом захвате мьютекса предполагает обход всего графа нитей(процессов)-блокировок (в том числе на вводе-выводе и передаче сообщений) и подъем приоритета нитям, стоящим в цепочках блокировок. Освобождение мьютекса -- также весьма нетривиальная операция, ибо нужно правильно восстановить приоритеты вздрюченным нитям при освобождении какого-либо мьютекса (исходные ставить нельзя!). А изменение приоритета нескольким нитям выливается в несколько перетрясок priority queue. Первый итог: разработчики коммерческих и некоммерческих ОСРВ реализуют наивный (или чуть сложнее) алгоритм PIP, делающий использование PIP опасным. Второй итог: в корретной реализации PIP время захвата и освобождения мьютекса становится величиной, зависящей от того, что наваял прикладной программист. Хотели гарантированную латентность -- получили недетерминизм. Общий итог: ОСРВ sucks, ибо зазря кушают кучу тиков процессора, -- пишем руками на asm-е под голую железку. Это практически дословное утверждение одного из наших заказчиков-партнеров, с которыми мы вместе работаем над довольно ответственной системой.
Здравствуйте, Шахтер, Вы писали:
G>>Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
Ш>Да? Я вот занимаюсь телекомом, но их имена не знаю. Как там? Чтобы опровергнуть общее утверждение достаточно одного контрпримера?
Trust nobody, Mr. Malder, гришь? (*потирает руки*) Ну и как, спрашивается, я могу тебе доверять, что ты телекомом занимаешься — тем более, что ты даже не знаешь кто такие Joe Armstrong и Ulf Wiger?
А хочешь узнать-то? Это, в общем, стоит затраченных усилий, даже если телекомом не заниматься Почитай вот это Making reliable distributed systems in the presence of sodware errors.
G>>Поэтому этим людям я верю на слово (да им и соврать-то не дадут — враз репутацию потеряют), а вот принимать в серьез вас у меня оснований нет.
Ш>А у меня другой подход. Trust nobody, Mr. Malder.
В твоем подходе осталось одно слабое место — он не доведен до логического конца. Problem is that you trust yourself too much. "Холтаф, вы в контрразведке не первый год, и давно пора бы уже понять, что доверять нельзя никому. Даже себе. Мне — можно".
Ш>>>Поскольку содержит неконтролируемый элемент в себе. Вообщем -- очередная попытка забить шуруп молотком. G>>JFYI — инкрементальные GC не содержат в себе "неконтроллируемого элемента". Лучше бы вместо того, чтоб флеймить, занялся бы RTFM-ом на тему incremental GC и real-time GC.
Ш>Вот когда мне действительно понадобиться в моей работе GC -- я им займусь. Но пока какой-либо необходимости привлекать GC я не встречал.
Необходимости — нет, как нет необходимости писать на языках высокого уровня. Достаточно умный инженер все на ассемблере напишет, ну или в крайнем случае на С, а всякие там С++ — это для дураков и лентяев.
Ш>И ни одного аргумента, чем это мне может быть полезно, я пока не услышал.
Батенька, проще писать с ним. Проще. За овнершип полиси следить не надо. Этим и полезно. Я без проблем могу следить за овнершипом, у меня в С++ программах за три года один мемори лик был. Но знаешь, у меня есть много чем интересным заняться, кроме отслеживания овнершип полиси. И я с радостью с этим расстанусь при первой возможности это сделать.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>Под hard-realtime понимается только 100% гарантированное время реакции. И все. Какое это время — 10 мс или 10 нс — с точки зрения определения совершенно неважно, эти аспекты определяются свойствами задачи и оборудования. С тем, что GC дает некоторый оверхед в смысле пиковых нагрузок, не спорит никто, это очевидно. И это не важно — здесь главное не в том, что оверхед есть, а важы два аспекта: G>>1) Можно ли разбить процедуру GC на интервалы, гарантированно не превышающие заданного порога. G>>2) Можно ли при этом гарантировать, что нельзя выделять память быстрее, чем она освобождается.
G>>На оба вопроса ответ: можно. Все. С чем вы (не вы лично, а вся ваша группа оппонентов) спорите и что хотите доказать, я не понимаю. С моей точки зрения, вы жонглируете терминами и некорректно ставите вопрос.
V>Почему ответ на оба вопроса — можно? На конкретной железке, с конкретными минимальными интервалами и с конкретными прикладными алгоритмами ответ на второй вопрос никак не гарантируется.
Любопытно, почему вы закрываете глаза на тот факт, что и безо всякого GC на конкретной железке с конкретными минимальными интервалами может точно также не хватить ресурсов уложиться в требуемый интервал. Эту глубокую мысль надо обязательно развить (а то мужики-то не знают, блин, тупые все вокруг!), и построить на ней аргументацию того, что real-time задачи вообще не решаются на современном железе.
Вы, наверное, мне возразите, что real-time задачи решать можно? А я вас спрошу (недоуменно так, так же как и вы меня): а почему? Вот например у процессора Z80 не хватит ресурсов, штоб раскодировать стек протоколов GSM, блин!
Я надеюсь, намек понятен? Может перестанем фигней заниматься?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Шахтер, Вы писали:
G>>>Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
Ш>>Да? Я вот занимаюсь телекомом, но их имена не знаю. Как там? Чтобы опровергнуть общее утверждение достаточно одного контрпримера?
G>Trust nobody, Mr. Malder, гришь? (*потирает руки*) Ну и как, спрашивается, я могу тебе доверять, что ты телекомом занимаешься — тем более, что ты даже не знаешь кто такие Joe Armstrong и Ulf Wiger?
Кому ты веришь на слово, а кому нет -- твоя личная проблема. Меня она не волнует.
А твоя наивная вера в то что все должны знать этих двух господ -- умиляет.
G>А хочешь узнать-то?
Зуб даёшь, что мне этот текст покажется интересным?
Ш>>И ни одного аргумента, чем это мне может быть полезно, я пока не услышал. G>Батенька, проще писать с ним. Проще. За овнершип полиси следить не надо.
Слежка за овнершип полиси на C++ легко автоматизируется.
Здравствуйте, AndreyFedotov, Вы писали:
AF>О да. Шахтёр крепкий мужик и я соответсвенно был в восторге именно от этой части его послания.
Эта часть в простонародье называется демагогией и переходом на личности.
AF>И разумеется я совершенно не обратил внимание на первую — содержательную часть.
Причем как минимум раза два подряд.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Шахтер, Вы писали:
G>>>Если хочется, я подавлю на вас авторитетом таких людей как Joe Armstrong и Ulf Wiger — инженеров, которые создавали этот AXD301. Эти люди широко известны в сообществе — те, кто занимается телекомом, их знают по именам. Они заслужили себе уважение и доверие своей работой, а не форумной болтовней.
Ш>>Да? Я вот занимаюсь телекомом, но их имена не знаю. Как там? Чтобы опровергнуть общее утверждение достаточно одного контрпримера?
G>Trust nobody, Mr. Malder, гришь? (*потирает руки*) Ну и как, спрашивается, я могу тебе доверять, что ты телекомом занимаешься — тем более, что ты даже не знаешь кто такие Joe Armstrong и Ulf Wiger?
G>А хочешь узнать-то? Это, в общем, стоит затраченных усилий, даже если телекомом не заниматься Почитай вот это Making reliable distributed systems in the presence of sodware errors.
Пробежался. Автор -- редкостный идиот. Не удивительно, что я его не знаю.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Шахтер, Вы писали:
AL>>>Здравствуйте, Шахтер, Вы писали:
AL>>>>>Здравствуйте, Шахтер, Вы писали:
AL>>>Знаете, во что выливается корректная реализация, скажем, алгоритма Priority Inheritance (весьма популярный buzzword) в ОСРВ?
Ш>>Знаю. Вот у меня на борде с vxWorks -- фактически ни во что. Разница в пределах погрешности измерения.
AL>В VxWorks, qnx, rtlinux и прочих коммерческих и полукоммерческих ОС реализации PIP некорректная. Почему?
Она такая, какая есть -- исходя из того, что это РТОС, а не JavaVM. Если она лично вам чем-то не нравиться, это не значит, что она некорректная.
Она вполне себя оправдывает на практике.
Точно также можно предьявлять притензии к тому, как реализована целочисленная арифметика, например.
Хотите полноценно использовать инструмент -- изучите его свойства как следует и пользуйтесь с умом.
AL>...Второй итог: в корретной реализации PIP время захвата и освобождения мьютекса становится величиной, зависящей от того, что наваял прикладной программист.
Вот если следовать подходу, который тут Gaperton рекламирует -- нет разделяемых ресурсов, всё через очереди сообщений, то проблемы вообще не возникает -- из-за отсутствия вложенных блокировок.
AL>Общий итог: ОСРВ sucks, ибо зазря кушают кучу тиков процессора, -- пишем руками на asm-е под голую железку. Это практически дословное утверждение одного из наших заказчиков-партнеров, с которыми мы вместе работаем над довольно ответственной системой.
Вот, вот -- типичная демагогия. Система плохая, потому что черезжопие, которое наши орлы напроектировали жрет слишком много системных ресурсов.
Мне жаль вашу ответственную систему.
AL>Насчет дешевой демагогии, думаю, Вы погорячились.
Здравствуйте, Gaperton, Вы писали:
G>Вы, наверное, мне возразите, что real-time задачи решать можно? А я вас спрошу (недоуменно так, так же как и вы меня): а почему? Вот например у процессора Z80 не хватит ресурсов, штоб раскодировать стек протоколов GSM, блин!
Z80 стоит 80 центов. Их легко можно поставить и 2 и 3. А ещё проще заменить на процессор с ценой в $2-8 и производительностью в 8-50 раз выше. Потому стоимость решения, которое потребляет в 10 раз больше ресурсов чем Z80 — будет в районе от $2 до $10 — что совершенно приемлемо для большинства областей, хотя при этом достаточно применений, где критично именно $0.8, а $2 уже много.
А вот попробуй заменить его на процессор или систему с произоводительностью в 1000000 раз выше? Сколько в такой системе будет стоить применение технологии, которая упростит программирование, но потребует в 10 раз больше ресурсов? Ты всё ещё уверен, что GC всегда себя оправдывает?
G>Я надеюсь, намек понятен? Может перестанем фигней заниматься?
Вот именно! Ты бы ещё на реле или радиолампе свои выкладки основывал.
Абсолютно очевидно, что в идеальной системе, с бесконечно высокой производительностью и объёмом памяти GC лучше, чем традиционная работа с памятью через кучу. И врядли здесь найдётся хоть кто-то кто станет с этим спорить
А вот в реальной системе всё очень зависит от того, чем именно эта система отличается от идеальной — каковы её ограничения, относительно решаемой задачи. Вот исходя из этого — по комплексу параметров из которых половина, если не больше вообще не относятся прямо к разработке ПО (такие как стоимость оборудования или проблемы теплоотвода) и определяется что более выгодно в данном конкретном случае. Это может оказаться и GC, а может и ассемблер.
Здравствуйте, Шахтер, Вы писали:
G>>А хочешь узнать-то? Это, в общем, стоит затраченных усилий, даже если телекомом не заниматься Почитай вот это Making reliable distributed systems in the presence of sodware errors.
Ш>Пробежался. Автор -- редкостный идиот. Не удивительно, что я его не знаю.
Yes!!! Ну конечно это не удивительно. Ты вообще много чего не знаешь.
Ш>>>И ни одного аргумента, чем это мне может быть полезно, я пока не услышал. G>>Батенька, проще писать с ним. Проще. За овнершип полиси следить не надо. Ш>Слежка за овнершип полиси на C++ легко автоматизируется.
Какой ты все-таки умный, если твоим словам верить, Шахтер, аж дух захватывает! Но я последую твоему совету, и им верить не буду. А давай ты для разнообразия хотя бы разок мешки поворочаешь, Mr. Malder?
Расскажи, как ты легко напишешь автоматический проверяльщик для ownership policy принятой в COM. На вход — прога. На выход — список методов, где нарушаются соглашения о подсчете ссылок для input и output параметров. И циклические ссылки отлови.
Но проверяльщик для COM — это ерунда. Самое интересное, конечно, это "следильщик", который будет следить за выполнением ownership policy на этапе дизайна моей аппликухи, когда у меня кода еще не написано, и все в голове. Шахтер не в курсе, что об ownership policy надо в основном на этапе дизайна думать, а то потом сильно поздно будет? Шахтер не понимает, что все мемори лики статически найти невозможно, а задача "отслеживания ownership policy" эквивалентна поиску ликов?
Ну не понимает, ну и ладно, в конце-то концов. Что мне теперь, каждому Шахтеру простые вещи объяснять? Так что извини, дорогой. Лучше продолжай считать всех идиотами — и тебе так будет проще, и остальным людям тоже .
Здравствуйте, Gaperton, Вы писали:
G>Какой ты все-таки умный, если твоим словам верить, Шахтер, аж дух захватывает! Но я последую твоему совету, и им верить не буду. А давай ты для разнообразия хотя бы разок мешки поворочаешь, Mr. Malder?
...
G>Ну не понимает, ну и ладно, в конце-то концов. Что мне теперь, каждому Шахтеру простые вещи объяснять? Так что извини, дорогой. Лучше продолжай считать всех идиотами — и тебе так будет проще, и остальным людям тоже .
Большая просьба к обоим — сбавить тон дискуссии, а то он уже зашкаливает. От того что вам удастся поддеть собеседника правыми вы не станете.
Здравствуйте, Gaperton, Вы писали:
G>Любопытно, почему вы закрываете глаза на тот факт, что и безо всякого GC на конкретной железке с конкретными минимальными интервалами может точно также не хватить ресурсов уложиться в требуемый интервал.
Потому как это не так. Существуют блочные распределители памяти, которые выделяют память чуть быстрее чем GC, а освобождают с той же скоростью, что и выделяют (для однопоточного аллокатора — даже быстрее, чем выделяют), т.е. на порядки быстрее GC. К тому же, в каждом конкретном случае мы можем использовать конкретный наиболее эффективный прием.
Просто GC — это решение общего случая работы с памятью, и тебе, как программисту, не обязательно думать — что и как происходит. А в случае собственных аллокаторов, организация работы с динамической памятью является частью разработки.
G>Эту глубокую мысль надо обязательно развить (а то мужики-то не знают, блин, тупые все вокруг!), и построить на ней аргументацию того, что real-time задачи вообще не решаются на современном железе.
Ерничать некрасиво, да еще так абстрактно. Все рассуждения можно производить только в сравнительной степени, а не абсолютной. Например, блочный аллокатор может потребовать в среднем 30 инструкций для выделения и 15 для освобождения памяти, и эта величина почти не зависит от кол-ва объектов. А в GC эти цифры от 500 для выделения и сотен тысяч или миллионов тактов для освобождения. Этих лишних тактов у нас может просто и не быть при максимальной загрузке системы.
G>Вы, наверное, мне возразите, что real-time задачи решать можно? А я вас спрошу (недоуменно так, так же как и вы меня): а почему? Вот например у процессора Z80 не хватит ресурсов, штоб раскодировать стек протоколов GSM, блин!
Ну да, нужен проц в 10 раз дороже. Иногда мы не можем позволить себе проц в 10 раз дороже, особенно если и так изначально на дорогой ориентировались.
Здравствуйте, AndreyFedotov, Вы писали: AF>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа.
Не надо ему ничего говорить. Руководитель, который считает центы в железе, неизбежно вскоре применит свои коммуникативные скиллы для хождения около супермаркета в костюме куриного окорочка с 9 до 17 пять дней в неделю.
Потому, что надо считать доллары в софте.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AndreyFedotov, Вы писали: AF>>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа. S>Не надо ему ничего говорить. Руководитель, который считает центы в железе, неизбежно вскоре применит свои коммуникативные скиллы для хождения около супермаркета в костюме куриного окорочка с 9 до 17 пять дней в неделю. S>Потому, что надо считать доллары в софте.
это утверждение неверно для общего случая.
например у нас есть проект где стоимость железа такова, что можно пяток очень хороших программеров посадить год вылизывать код.
и так и делается. иначе как объяснить заказчику, что он должен потратить еще очень много $$$ потому что наши программисты не в состоянии написать оптимальный код.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AndreyFedotov, Вы писали: AF>>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа. S>Не надо ему ничего говорить. Руководитель, который считает центы в железе, неизбежно вскоре применит свои коммуникативные скиллы для хождения около супермаркета в костюме куриного окорочка с 9 до 17 пять дней в неделю. S>Потому, что надо считать доллары в софте.
Вы уверены что это всегда так?
Во-первых про центы я и не говорил — такое бывает, но редко. Разница в $0,8 и $2 — это уже доллары.
Во-вторых далеко не всегда стоимость софта составляет большую часть системы. Возьмите к примеру сетевой концентратор.
В-третьих есть множество применений, где софт относительно простой, пишется один раз и затем лишь тиражируется. Наручные часы например. Их стоимость около $3. Вы уверены что для них тоже не важна разница в несколько десятков центов?
1 цент разницы при партии в 1000000 штук — это уже $10000, а при норме прибыли в 3% (типичной для запада), общая прибыль от партии будет $3 * 1000000 * 3% = $90000. Вы по прежнему уверены что цент в железе не важен?
В-четвёртых далеко не всегда вопрос исчерпывается только лишь ценой единственного компонента. Например один процессор можно поставить на двухслойную плату, а второй — только на четырёх слойную, и при разнице в цене платы в 1,5 раза дополнительное увеличение цены. К тому же есть ещё габариты, энергопотребление, рабочий диапазон температур, сроки поставок и т.д. и т.п. Часто выбирается худшая комплектация, но с гарантированными сроками поставок. И каждый из этих факторов может легко перевесить даже очень значительное увеличение стоимости софта.
Резюме: В любой области имеет смысл выделять факторы, влияющие на себестоимость, оценивать степень влияния и делать выбор исходя из этого.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Влад, бывают так же ОС реального времени, так вот для них GC, по крайней мере в том виде, в котором он есть в C# или Java — не приемлем. А в том виде в котором он приемлем — его скорость гораздо ниже.
Я специально не останавливался на различиях между ОС «мягкого» и
«жесткого» реального времени по той простой причине, что различия эти
носят чисто количественный характер и сводятся к различиям в скоростях
реакции и времени восстановления системы. И, кстати, было бы более
правильно называть их системами «медленного» и «быстрого» реального времени.
Я не вчитывался в остальные части статьи, но вот рассуждения автора в части "миф шестой"
с реальностью никак не связаны.
динамическое распределение памяти кучи, обеспечивая экономию этого достаточно критичного
ресурса, приводит к проблеме, известной как фрагментация памяти, когда свободная память
разбивается на малые фрагменты, разделенные занятыми участками, что приводит, в конечном
итоге, к невозможности выделения участка памяти необходимого (большого) размера, хотя
общий объем свободной памяти остается достаточно большим.
Пока все в порядке: проблема сформулирована верно.
И опять же, бытует ошибочное мнение, что в рассматриваемых двух классах ОС эта проблема
решается по-разному:
This fragmentation problem can be solved by so-called “garbage collection” (defragmentation)
software. <...>
<...>
Как же тогда решается эта проблема на уровне ОС? Если речь идет о современных мощных
процессорах с аппаратной поддержкой страничной памяти, то очень «просто»: система
распределяет память программам страницами фиксированного размера (например, 4KB),
а аппаратура адресации процессора обеспечивает «связывание» этих страниц в непрерывное
виртуальное адресное пространство программы. При этом обеспечивается независимость от
физического размещения страниц в физической RAM.
А вот здесь автор уже говорит о чем-то, к делу никак не относящемуся. А именно:
для программы проблему представляет фрагментация логического адресного пространства, а
не физического. Соответственно, страничная память к проблеме фрагментации логического
адресного пространства вообще никак не относится.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AndreyFedotov, Вы писали: AF>>Конечно. Ты это руководителю фирмы, который каждый цент в железе считает скажи. AF>>Что его программистам лень думать как работает ПО и как работать с памятью, а посему он должен удвоить мощность процессора, а заодно и утроить себестоимость железа. S>Не надо ему ничего говорить. Руководитель, который считает центы в железе, неизбежно вскоре применит свои коммуникативные скиллы для хождения около супермаркета в костюме куриного окорочка с 9 до 17 пять дней в неделю. S>Потому, что надо считать доллары в софте.
Не, Синклер, тут все очень просто. Смотри: себестоимость железа — переменные издержки, которые для компании пропорциональны объемам продаж. Т.е. ты от них не избавишься увеличив продажи, понимаешь? Себестоимость софта не зависит от объемов продаж, и является таким образом постоянными издержками. При большой партии не слишком дорогих маленьких железок у тебя как раз получится ситуация, что дешевле напрячь программеров, чем впихнуть на плату лишнюю микросхему или транзистор.
Теперь имей в виду, что сократить издержки на 10% — это для компании выгоднее, чем увеличить продажи на те же самые 10%. Вот все и встает на свои места — есть в жизни ситуации, когда это так.
Есть только один нюанс, делающий забавным такую аргументацию на "серьезно форуме настоящих программистов" — повторюсь, это правило работает для больших партий дешевых железок. Ну, модемов там, АОНов, например, или пультов дистанционного управления, и слабо работает, например, для ATM-свитчей высокой произвоительности или мэйнфреймов, которые конечно тоже железки, но тираж у них совсем не тот . А взять встраиваемые системы в космических аппаратах (в штучном экземпляре ), так там вообще другая арифметика.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А вот здесь автор уже говорит о чем-то, к делу никак не относящемуся. А именно: ПК>для программы проблему представляет фрагментация логического адресного пространства, а ПК>не физического. Соответственно, страничная память к проблеме фрагментации логического ПК>адресного пространства вообще никак не относится.
А почему это не представить это дело так: создаётся аппаратный комплекс и RTOS для него. Процессор этого комплекса умеет работать с виртуальными и физическими адресами памяти. RTOS предоставляет функциональность для работы с памятью, она же умеет вирутально "дефрагментировать" пямять (манипулируя таблицами виртуальных адресов). Такая система позволит улучшить эффективность хипа и продлить время его безотказной работы (но не решить проблему с дефрагментацией).
Например, нужно выделить кусок объёма 8 кб, в то время как хип в физическом пространстве адресов представлен таким образом:
Здравствуйте, ArtDenis, Вы писали:
AD>RTOS в этом случае выделяет для приложения 2-ю и 4-ю страницы и ставит в соотвествие им непрерывный участок памяти в виртуалной области.
Читай внимательно, что Паша написал — фрагментируется виртуальное адресное пространство. Перемапливать физическую память современные процессоры и ОС научились еще очень давно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Читай внимательно, что Паша написал — фрагментируется виртуальное адресное пространство. Перемапливать физическую память современные процессоры и ОС научились еще очень давно.
Я знаю. Я же написал, что проблему с дефрагментацией это не решает, но зато увеличивает эффективность работы менеджера памяти.
Здравствуйте, ArtDenis, Вы писали:
AD>Я знаю. Я же написал, что проблему с дефрагментацией это не решает, но зато увеличивает эффективность работы менеджера памяти.
За счет чего? И чем это отличается от того, что реализовано в Windows?
Здравствуйте, ArtDenis, Вы писали:
AD>...(но не решить проблему с дефрагментацией).
Наверное можно и ее решить. Вот смотрите. Пусть у нас машина будет не 32 разрядная, а 64 разрядная. У нас тогда есть 2^64 битов виртуальной памяти, т.е. прорва. Нам столько много в жизни не истратить. Так пусть менеждер памяти при очередном вызове NEW() выделяет всё новую и новую виртуальныю память (каждый раз со всё большим и большим адресом). Когда старые участки виртуальной памяти становятся более не нужными, тогда менеджер управления памятью пусть те физические страницы памяти ассоциированные с теми виртуальными адресами — освобождает, так что реальная физическая память будет доступна для повторного использования, а виртуальная память — нет, ну и не надо ведь ее и так много = 2^64, всё равно всю не исчерпаешь.
Здравствуйте, AndrewVK, Вы писали:
AVK>За счет чего?
За счёт того, что вероятность ситуации, когда невозможно выделить блок из-за фрагментации памяти в системах с виртуальной страничной памятью меньше, чем таже самая вероятность в системах без виртуальной памяти. Эта вероятность меньше, т.к. размер адресного пространства виртуальной памяти может быть больше, чем физической. Поэтому OS может эффективно изымать из работы пустые участки виртуальной памяти, которые создают фрагментацию и перебрасывать их например в те диапазоны адресов, которые доступны в витруальной памяти.
Например, после некоторого времени работы программы память фрагментировлась следующим образом:
(free — память, освободившаяся по запросу приложения, BUSY — память выделенная по запросу приложения (и частично или полностю занятая), unused — неиспользуемая страница памяти в виртуальном пространстве)
Задача: при размере страницы 4 кб, выделить 16 кб памяти.
Представим себе, что в данный момент занята вся физическая память (у нас всего 10 страниц). Что делать? Всё очень просто. Нужно перебрость страницы 2, 1, 0 и 6 в другую область витруальной памяти:
Теперь можно выделить память в этом непрерывном участке. Причём эффективность метода растёт с уменьшением размера страницы.
AVK>И чем это отличается от того, что реализовано в Windows?
В том, что в Windows существует системный хип и хип приложения. И их совместная работа не всегда эффективна. Например, хип приложения не всегда может эффективно освобождать память так, чтобы OS выгрузила освобождёные страницы.
В приведённом аримере менеджер памяти OS и приложения совмещён в одном флаконе
Здравствуйте, ArtDenis, Вы писали:
AD>Теперь можно выделить память в этом непрерывном участке. Причём эффективность метода растёт с уменьшением размера страницы.
Вот и я про тоже. Надо чтобы аппаратно можно было ассоцировать/деассоциировать физические страницы с виртуальной памятью причем любого физического размера и с точностью до байта. А размер виртуального пространства может быть очень велик 2^64 для 64 разрядных или 2^256 для 256 разрядных — так что всю виртуальную память никогда не израсходуешь (не успеешь).
Здравствуйте, Сергей Губанов, Вы писали:
AD>>...(но не решить проблему с дефрагментацией). СГ>Наверное можно и ее решить. Вот смотрите. ...
Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, Сергей Губанов, Вы писали:
AD>>>...(но не решить проблему с дефрагментацией). СГ>>Наверное можно и ее решить. Вот смотрите. ...
AD>Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
Угу. Надо иметь такое железо, что б оно физические страницы могло приклеивать/отклеивать по произвольному виртуальному адресу и произвольного размера с точностью до байта.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот и я про тоже. Надо чтобы аппаратно можно было ассоцировать/деассоциировать физические страницы с виртуальной памятью причем любого физического размера и с точностью до байта.
Ага, тогда таблица соответствия виртуальных и физических адресов будет иметь размер
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, ArtDenis, Вы писали:
AD>>Теперь можно выделить память в этом непрерывном участке. Причём эффективность метода растёт с уменьшением размера страницы.
СГ>Вот и я про тоже. Надо чтобы аппаратно можно было ассоцировать/деассоциировать физические страницы с виртуальной памятью причем любого физического размера и с точностью до байта. А размер виртуального пространства может быть очень велик 2^64 для 64 разрядных или 2^256 для 256 разрядных — так что всю виртуальную память никогда не израсходуешь (не успеешь).
Для описания виртуальной памяти в 512 мегабайт нужно минимум 1 мегабайт реальной памяти (на 64 битной машине), причем памяти, которая не свопируется. Это вообще говоря довольно серьезная проблема и ее пытаются решить путем увеличения размера страниц, а ты предлагаешь их уменьшать. Если уменьшать, то большая часть памяти будет протухать, храня в себе бесчисленные малополезные таблицы страниц.
Здравствуйте, vdimas, Вы писали:
V>Ерничать некрасиво, да еще так абстрактно. Все рассуждения можно производить только в сравнительной степени, а не абсолютной. Например, блочный аллокатор может потребовать в среднем 30 инструкций для выделения и 15 для освобождения памяти, и эта величина почти не зависит от кол-ва объектов. А в GC эти цифры от 500 для выделения и сотен тысяч или миллионов тактов для освобождения. Этих лишних тактов у нас может просто и не быть при максимальной загрузке системы.
Не нужно преувеличивать. В простом копирующем сборщике мусора выделение памяти происходит практически мгновенно, а процесс чистки занимает времени примерно порядка занятой памяти. Если считать, что занята постоянно 1/8 памяти, а средний размер объекта 128 байт, то цикл выделение-освобождение в среднем на один объект займет несколько тысяч инструкций. Это не блочный аллокатор, естественно, но зато можно выделять память для объектов произвольного размера.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, vdimas, Вы писали:
V>>Ерничать некрасиво, да еще так абстрактно. Все рассуждения можно производить только в сравнительной степени, а не абсолютной. Например, блочный аллокатор может потребовать в среднем 30 инструкций для выделения и 15 для освобождения памяти, и эта величина почти не зависит от кол-ва объектов. А в GC эти цифры от 500 для выделения и сотен тысяч или миллионов тактов для освобождения. Этих лишних тактов у нас может просто и не быть при максимальной загрузке системы.
Q>Не нужно преувеличивать. В простом копирующем сборщике мусора выделение памяти происходит практически мгновенно, а процесс чистки занимает времени примерно порядка занятой памяти. Если считать, что занята постоянно 1/8 памяти, а средний размер объекта 128 байт, то цикл выделение-освобождение в среднем на один объект займет несколько тысяч инструкций. Это не блочный аллокатор, естественно, но зато можно выделять память для объектов произвольного размера.
Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций...
Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, ArtDenis, Вы писали:
AD>>Здравствуйте, Сергей Губанов, Вы писали:
AD>>>>...(но не решить проблему с дефрагментацией). СГ>>>Наверное можно и ее решить. Вот смотрите. ...
AD>>Тут стоит говорить только об эффективности, но не о решении проблемы. Существует вероятность ситуации, когда будут заняты все физические страницы при мнинимальном эффективном использовнии каждой страницы. В этом случае без полноценной дефрагментации не обойтись.
СГ>Угу. Надо иметь такое железо, что б оно физические страницы могло приклеивать/отклеивать по произвольному виртуальному адресу и произвольного размера с точностью до байта.
Ты подумай сначала, сколько памяти потребуется такому железу, что бы склеивать страницы памяти... И кому оно такое будет надо?
Здравствуйте, AndreyFedotov, Вы писали:
AF>Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций... AF>Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Ну так ведь речь шла о самом простом и универсальном GC. Кто мне мешает сделать "блочный" GC с эффективной реализацией value типов? В этом случае память будет выделяться также быстро как и руками, а осовобождаться будет лишь с небольшим оверхедом, вызванным теоретическими многочисленными ссылками на некоторые объекты. Думаю, реально для любой специфической задачи создать GC, который затормозит программу не более, чем на 10%.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Да, это так. Вопрос в том, допустимо ли тратить эти несколько тысяч инструкций... AF>>Для процессора с частотой в 10 Мгц это порядка 0.1-1 миллисекунды на единственный объект, что вообще-то довольно много и в некоторых задачах недопустимо.
Q>Ну так ведь речь шла о самом простом и универсальном GC. Кто мне мешает сделать "блочный" GC с эффективной реализацией value типов? В этом случае память будет выделяться также быстро как и руками, а осовобождаться будет лишь с небольшим оверхедом, вызванным теоретическими многочисленными ссылками на некоторые объекты. Думаю, реально для любой специфической задачи создать GC, который затормозит программу не более, чем на 10%.
Это теоретически. На практике действительно идёт большая работа над алгоритмами, которые позволяют достичь предсказуемости работы GC, а так же осуществления сборки мусора мелкими порциями и есть даже некоторые успехи в этой области. В переспективе это действительно позволяет использовать GC и основанные на нём технологии во всё новых и новых областях, в том числе и некоторых из тех, где раньше это было сложно себе представить.
Однако замечу — что GC всё ещё остаётся достаточно дорогой (в смысле ресурсов и по сравнению с Heap или статическим распределением памяти) и по-прежнему хватает применений, где по этой причине использование GC мало реально.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Это теоретически. На практике действительно идёт большая работа над алгоритмами, которые позволяют достичь предсказуемости работы GC, а так же осуществления сборки мусора мелкими порциями и есть даже некоторые успехи в этой области. В переспективе это действительно позволяет использовать GC и основанные на нём технологии во всё новых и новых областях, в том числе и некоторых из тех, где раньше это было сложно себе представить. AF> Однако замечу — что GC всё ещё остаётся достаточно дорогой (в смысле ресурсов и по сравнению с Heap или статическим распределением памяти) и по-прежнему хватает применений, где по этой причине использование GC мало реально.
Хотелось бы добавить, что ещё остались области где до сих пор используется голый асм вместо C, голый CmixAsm вместо C+RTOS со статическим распределением памяти, в рунете есть места где вам на чистом русском языке с примерами из жизни объяснят всё насчёт оверхеда в критических приложениях
Если нам не помогут, то мы тоже никого не пощадим.
Понятие hard-realtime никакого отношения к времени допустимой задержки не имеет! Оно определят фатальность превышения этого времени.
Вот например у процессора Z80 не хватит ресурсов, штоб раскодировать стек протоколов GSM, блин!
