Здравствуйте, 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 становится с одной стороны избыточным, а с другой -- просто опасным.
Поскольку содержит неконтролируемый элемент в себе. Вообщем -- очередная попытка забить шуруп молотком.
