Здравствуйте, 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" эквивалентна поиску ликов?
Ну не понимает, ну и ладно, в конце-то концов. Что мне теперь, каждому Шахтеру простые вещи объяснять? Так что извини, дорогой. Лучше продолжай считать всех идиотами — и тебе так будет проще, и остальным людям тоже .
Обвиняешь меня в намеренном вранье, значит? 
Вот например у процессора Z80 не хватит ресурсов, штоб раскодировать стек протоколов GSM, блин!
Что мне теперь, каждому Шахтеру простые вещи объяснять? Так что извини, дорогой. Лучше продолжай считать всех идиотами — и тебе так будет проще, и остальным людям тоже 