AVC wrote:
> AF> — Аккуратное слежение за выделением и освобождением памяти. > Совершенно невинный пункт. Но у меня уже готово сорваться ехидное: "И > Вы собираетесь организовать это аккуратное слежение на Си++?!
Используя паттерны, которые были для этого разработаны.
> Не лучше ли взять за основу НАДЕЖНЫЙ язык, уступающий Си++ в > производительности всего несколько процентов!? (В случае Оберона.)"
Не лучше, так как часто другой язык имеет еще и другие недостатки.
Скажем, в случае Оберона — марсианский синтаксис и полная
неприспособленность для практической работы. Ну и необходимость GC.
В случае Ады — слишком уж сильная мания преследования. В случае Java —
полная зависимость от GC.
Ну а проценты (даже десятки процентов) производительности сейчас мало
кого волнуют.
Здравствуйте, Cyberax, Вы писали:
>> AF> — Аккуратное слежение за выделением и освобождением памяти. >> Совершенно невинный пункт. Но у меня уже готово сорваться ехидное: "И >> Вы собираетесь организовать это аккуратное слежение на Си++?!
C>Используя паттерны, которые были для этого разработаны.
То есть, все-таки, "вручную".
Понятно.
У соседей-буржуев стирает машина-автомат; а нас — стирает мама!
>> Не лучше ли взять за основу НАДЕЖНЫЙ язык, уступающий Си++ в >> производительности всего несколько процентов!? (В случае Оберона.)"
C>Не лучше, так как часто другой язык имеет еще и другие недостатки.
То есть имеет все недостатки Си++, а вдобавок — еще и другие.
C>Скажем, в случае Оберона — марсианский синтаксис и полная C>неприспособленность для практической работы. Ну и необходимость GC.
Да, уныл марсианский пейзаж: оранжевое небо, оранжевая мама... оранжевый верблюд...
И, опять же, ранит сердце подлый факт существования стиральных машин.
C>В случае Ады — слишком уж сильная мания преследования.
Наверное, военным так положено: не верить ничему и никому, даже самим себе, и бдить!
C> В случае Java — полная зависимость от GC.
Все же, радует, что хотя бы синтаксис у Java — свой, земной.
Но, опять же, — эти стиральные машины...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC wrote:
> C>Используя паттерны, которые были для этого разработаны. > То есть, все-таки, "вручную". > Понятно. > У соседей-буржуев стирает машина-автомат; а нас — стирает мама!
Можно вопрос? Вы пальто, туфли и пиджак тоже в стиральной машине стираете?
> Но, опять же, — эти стиральные машины...
Hint: на многих вещах написано "не для машинной стирки"....
Здравствуйте, Cyberax, Вы писали:
>> C>Используя паттерны, которые были для этого разработаны. >> То есть, все-таки, "вручную". >> Понятно. >> У соседей-буржуев стирает машина-автомат; а у нас — стирает мама!
C>Можно вопрос? Вы пальто, туфли и пиджак тоже в стиральной машине стираете?
>> Но, опять же, — эти стиральные машины...
C>Hint: на многих вещах написано "не для машинной стирки"....
Ответ очень удачный. Мне понравился.
Но мы несколько отвлеклись от темы форума и даже от языкового флейма.
Я сам тут виноват. Но как еще было ответить на смешное утверждение о "марсианском синтаксисе"?
По сути дела хочу сказать, что рассматриваю GC как достоинство современных языков, сильно упрощающее работу со сложными динамическими структурами данных и делающее программы гораздо надежнее.
Если по каким-то причинам GC не подходит для конкретного приложения, всегда можно найти другой способ управления памятью.
Например, заранее выделить пул объектов (хотя бы в виде стека указателей), создаваемых и уничтожаемых в реальном времени.
На крайний случай, можно написать на Обероне свой распределитель памяти для специфических объектов. (В одном модуле придется импортировать SYSTEM. Ничего, переживем. ) Для особых случаев компилятор может предоставить и старую добрую процедуру DISPOSE. (Oakwood guidelines)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> По сути дела хочу сказать, что рассматриваю GC как достоинство современных языков, сильно упрощающее работу со сложными динамическими структурами данных и делающее программы гораздо надежнее.
Мне по этому поводу показались интересными флеймы в comp.lang.c++.moderated: Garbage Collection and C++ Pathology Of Bad Software Architecture
> Если по каким-то причинам GC не подходит для конкретного приложения, всегда можно найти другой способ управления памятью.
Вопрос: какие средства для надежного решения данной задачи предоставляет язык, рассчитанный на наличие GC?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>Можно вопрос? Вы пальто, туфли и пиджак тоже в стиральной машине стираете?
А Вы их стираете вручную?
C>Hint: на многих вещах написано "не для машинной стирки"....
Некоторые машины прекрасно стирают то, на чем написано "не для машинной стирки".
Трурль wrote:
> C>Можно вопрос? Вы пальто, туфли и пиджак тоже в стиральной машине > стираете? > А Вы их стираете вручную?
Туфли я не стираю — я их чищу, а пальто отдаю в чистку — там его
аккуратно стирают руками (раньше пальто/куртки я стирал сам).
> C>Hint: на многих вещах написано "не для машинной стирки".... > Некоторые машины прекрасно стирают то, на чем написано "не для > машинной стирки".
AVC wrote:
> C>Можно вопрос? Вы пальто, туфли и пиджак тоже в стиральной машине > стираете? >>> Но, опять же, — эти стиральные машины... > C>Hint: на многих вещах написано "не для машинной стирки".... > Ответ очень удачный. Мне понравился.
Мне тоже
> Но мы несколько отвлеклись от темы форума и даже от языкового флейма.
А я и не знал, что у этого форума есть тема
> По сути дела хочу сказать, что рассматриваю GC как *достоинство* > современных языков, сильно упрощающее работу со сложными динамическими > структурами данных и делающее программы гораздо надежнее.
Не знаю, я думал также года 3 назад, когда писал на Яве. Сейчас я уже в
этом сомневаюсь — у меня лично было три случая, когда сложность схемы
ручного управления памятью заставляла задуматься о явных ошибках в
дизайне системы.
ИМХО, GC реально нужен в сравнительно небольшой доле приложений — там
где нужно создавать сложные связные структуры с неопределенным временем
жизни (узлы AST в компиляторе и т.п.).
> Если по каким-то причинам GC не подходит для конкретного приложения, > всегда можно найти другой способ управления памятью.
Это не так просто, как кажется. Сейчас реально существует _единственный_
язык, где можно удобно использовать "другие способы управления памятью",
и этот язык называется С++. Большая часть сложности в С++ как раз и
проистекает из этого.
> Например, заранее выделить пул объектов (хотя бы в виде стека > указателей), создаваемых и уничтожаемых в реальном времени. > На крайний случай, можно написать на Обероне свой распределитель > памяти для специфических объектов. (В *одном* модуле придется > импортировать SYSTEM. Ничего, переживем. ) > *Для особых случаев* компилятор может предоставить и старую добрую > процедуру DISPOSE. (Oakwood guidelines)
Проблема-то не в том, чтобы написать аллокатор — всякие пулы для Java и
прочих C# написаны уже по 100 раз. Проблема в том, что нужно задизайнить
язык под возможность ручного управления памятью. Это не так просто —
сейчас это делается для C++/CLI, и уже были найдены куча разных тонких
моментов с исключениями, многотредностью и т.п.
C>Это не так просто, как кажется. Сейчас реально существует _единственный_ C>язык, где можно удобно использовать "другие способы управления памятью", C>и этот язык называется С++. Большая часть сложности в С++ как раз и C>проистекает из этого.
Есть еще D в котором "другие способы управления памятью" использовать также удобно как и в C++.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Cyberax, Вы писали:
C>>Это не так просто, как кажется. Сейчас реально существует _единственный_ C>>язык, где можно удобно использовать "другие способы управления памятью", C>>и этот язык называется С++. Большая часть сложности в С++ как раз и C>>проистекает из этого.
FR>Есть еще D в котором "другие способы управления памятью" использовать также удобно как и в C++.
Есть вообще? Или есть для промышленной разработки?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
FR wrote:
> C>Это не так просто, как кажется. Сейчас реально существует > _единственный_ > C>язык, где можно удобно использовать "другие способы управления > памятью", > C>и этот язык называется С++. Большая часть сложности в С++ как раз и > C>проистекает из этого. > Есть еще D в котором "другие способы управления памятью" использовать > также удобно как и в C++.
Не совсем, я в свое время в их группе новостей показывал места в языке,
из-за которых GC в D нельзя в полном объеме реализовать.
Да и вообще, D все никак закончить нормально не могут.
IT wrote:
> C>Проблема в том, что нужно задизайнить язык под возможность ручного > управления памятью. > Зачем? В смысле, зачем нужно ручное управление памятью?
1. Интероперирование с легаси-кодом. Скрещивание GC и неGC-библиотек —
адское занятие.
2. Не всегда можно мириться с оверхедом по памяти от GC.
3. Скорость, скорость, скорость.
Здравствуйте, Cyberax, Вы писали:
C>1. Интероперирование с легаси-кодом. Скрещивание GC и неGC-библиотек — C>адское занятие.
Да как-то скрещиваем и не потеем.
C>2. Не всегда можно мириться с оверхедом по памяти от GC.
Пожалуй единственный аргумент. Но тогда уж и все ООП можно в лес отправить. С всегда рулит с его плоскими подходами когда речь заходит об экономии памяти.
C>3. Скорость, скорость, скорость.
Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>1. Интероперирование с легаси-кодом. Скрещивание GC и неGC-библиотек — > C>адское занятие. > Да как-то скрещиваем и не потеем.
Ага, конечно. Лично занимался прилаживанием Image Magic к C# — больше
такого не хочется.
Кстати, нам нужна была кроссплатформенная либа на C#, а стандартами
только простенький PInvoke определен.
> C>2. Не всегда можно мириться с оверхедом по памяти от GC. > Пожалуй единственный аргумент. Но тогда уж и все ООП можно в лес > отправить. С всегда рулит с его плоскими подходами когда речь заходит > об экономии памяти.
В С++ я могу без особых проблем (я этим занимался) добиться такого же
расходования памяти, как и в чистом С.
> C>3. Скорость, скорость, скорость. > Что скорость? Ты бы к своей фобии скорости хоть какие пояснения давал.
Все современные и эффективные GC дают паузы при полных циклах сборки,
это не всегда приемлимо (в играх, например). Ну и еще С++ные
автоматические объекты все же быстрее работают, чем GC с короткоживущими
объектами.
Кстати, придумал еще пункт 4:
4. Нежелание мусорить.
Здравствуйте, Cyberax, Вы писали:
C>Все современные и эффективные GC дают паузы при полных циклах сборки, C>это не всегда приемлимо (в играх, например). Ну и еще С++ные C>автоматические объекты все же быстрее работают, чем GC с короткоживущими C>объектами.
Все же повторяя такое количество раз свои заблуждения нужно бы хоть раз попытаться проверить свои слова. А то заучил как "отче наш" фразу про паузы и тормоза и повторяшь ее по сто раз на дню. А тем временем игры спокойно работают на том самом ЖЦ и никаких проблем в упор не видно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>Все современные и эффективные GC дают паузы при полных циклах сборки, > C>это не всегда приемлимо (в играх, например). Ну и еще С++ные > C>автоматические объекты все же быстрее работают, чем GC с > короткоживущими > C>объектами. > Все же повторяя такое количество раз свои заблуждения нужно бы хоть > раз попытаться проверить свои слова. А то заучил как "отче наш" фразу > про паузы и тормоза и повторяшь ее по сто раз на дню.
Хочешь подробно расскажу о внутреннем мире GC в Java? Это к вопросу про
"проверить свои слова"...
Конкурентные GC есть, но они имеют тенденцию пропускать определенную
часть мусора, который постепенно накапливается.
> А тем временем игры спокойно работают на том самом ЖЦ и никаких > проблем в упор не видно.
Насчет "не видят проблем" — это ты, кончено, загнул. Под GC портированы
простенькие Quake2/DOOM, которые на сегодняшних машинах действительно не
тормозят. А вот Ил-2 Штурмовик хоть и не использует Яву для графического
движка, но все равно отжирает кучу памяти.
Здравствуйте, Cyberax, Вы писали:
C>Хочешь подробно расскажу о внутреннем мире GC в Java? Это к вопросу про C>"проверить свои слова"...
Нет. Не хочу. Это вообще глупость так как существуют несколько типв ЖЦ, а их гибриды вообще не счесть. Хочу чтобы ты подтвердил свои слова чем-то практическим или прикратил постоянно высказывать эти домыслы.
C>Конкурентные GC есть, но они имеют тенденцию пропускать определенную C>часть мусора, который постепенно накапливается.
Меня твои теории не интересуют. Я знаю как работает ЖЦ в дотнете. А вот ты явно не сопоставляшь скорости современных процессоров и время которое уходит на сборку мусора. Вот я тебе и предлагаю произвести эксперементы чтобы ошутить эти цифры. Ну, не может человек заметить пдобные задержки. Может быть на задачах реального времени обычные ЖЦ и ведут себя плохо, но для человека это все фигня.
C>Насчет "не видят проблем" — это ты, кончено, загнул. Под GC портированы C>простенькие Quake2/DOOM, которые на сегодняшних машинах действительно не C>тормозят. А вот Ил-2 Штурмовик хоть и не использует Яву для графического C>движка, но все равно отжирает кучу памяти.
А у меня и дум3 отжирает кучу памяти. Но мы же не про память речь ведем? Мы же о торозах. Вот тот же ИЛ2 на моей машине не тормозит. А если и тормозил бы то скорее всго виной тому была бы видюха.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Все же повторяя такое количество раз свои заблуждения нужно бы хоть раз попытаться проверить свои слова. А то заучил как "отче наш" фразу про паузы и тормоза и повторяшь ее по сто раз на дню. А тем временем игры спокойно работают на том самом ЖЦ и никаких проблем в упор не видно.
Я пишу один и тот же класс задач (небольшие утилитки под win32) C++ и С#, и исходя из чистого опыта наблюдаю что все то же но на С# тормозит на порядок , по сравнению с C++.
Причины выяснять нет желания, или память или еще какие ресурсы.
Здравствуйте, Павел Кузнецов, Вы писали:
>> По сути дела хочу сказать, что рассматриваю GC как достоинство современных языков, сильно упрощающее работу со сложными динамическими структурами данных и делающее программы гораздо надежнее.
ПК>Мне по этому поводу показались интересными флеймы в comp.lang.c++.moderated: ПК>Garbage Collection and C++ ПК>Pathology Of Bad Software Architecture
Спасибо за ссылки. И правда, флейм, как правило, интереснее церковного хора.
>> Если по каким-то причинам GC не подходит для конкретного приложения, всегда можно найти другой способ управления памятью.
ПК>Вопрос: какие средства для надежного решения данной задачи предоставляет язык, рассчитанный на наличие GC?
Зависит от понятия "надежности".
В том смысле, в каком его употребляю лично я применительно к языкам программирования — никаких надежных альтернатив GC пока не существует.
Конечно, программист путем героических личных усилий может существенно повысить надежность своих программ.
Самый простой способ — не пользоваться кучей. Заведи себе статические массивы и радуйся. (Самое смешное, что этот дурацкий совет иногда вполне уместен. )
В ситуации жесткого реалтайма есть трудности со временем, но можно надеяться на некоторый избыток памяти. (Или кто-то собирается запускать вместе с такой программой еще сотню других?) Наиболее пригодным мне кажется способ, когда свободные объекты определенного класса помещаются в пул, откуда и выдаются программе по запросу. Пул организован в виде стека указателей на уже отведенные с помощью NEW, но пока не использованные объекты. Память вообще не возвращается. В самом крайнем случае, если требуется (пул исчерпан), с помощью NEW создаются новые объекты. Это не должно требовать много времени, т.к. куча не фрагментирована. Использованный объект возвращается в пул (а не в кучу), если он больше не требуется.
ИМХО, жесткий реалтайм требует специализированных распределителей памяти. GC может тормозить в критические моменты, но то же самое верно в отношении delete (DISPOSE). Если пользоваться стандартным распределителем памяти, куча фрагментируется, что рано или поздно приведет к задержкам времени, родственным задержкам при сборке мусора GC.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, minorlogic, Вы писали:
M>Я пишу один и тот же класс задач (небольшие утилитки под win32) C++ и С#, и исходя из чистого опыта наблюдаю что все то же но на С# тормозит на порядок , по сравнению с C++.
Что забавно, что я тоже пишут сходный класс задач и разницы в скорости не наблюдаю. За то в качестве наблюдаю.
M>Причины выяснять нет желания, или память или еще какие ресурсы.
Правильно. Зачем выяснять причины. Темболее что этот процесс може растроить.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, minorlogic, Вы писали:
M>Ах да ! Извини забыл добавить, чтобы тебе было более доступнее.
M>Твои слова это полная чушь , которую ты повторяешь из поста в пост ... А также полный бред ..
Зато твои очень убедительны, основательны и главное весомы.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AVC, Вы писали:
>>> Если по каким-то причинам GC не подходит для конкретного приложения, всегда можно найти другой способ управления памятью.
ПК>>Вопрос: какие средства для надежного решения данной задачи предоставляет язык, рассчитанный на наличие GC?
AVC>Зависит от понятия "надежности". AVC>В том смысле, в каком его употребляю лично я применительно к языкам программирования — никаких надежных альтернатив GC пока не существует.
Ну, GC, как мы договорились, не подходит.
AVC> Наиболее пригодным мне кажется способ, когда свободные объекты определенного класса помещаются в пул, откуда и выдаются программе по запросу. Пул организован в виде стека указателей на уже отведенные с помощью NEW, но пока не использованные объекты. Память вообще не возвращается. В самом крайнем случае, если требуется (пул исчерпан), с помощью NEW создаются новые объекты. Это не должно требовать много времени, т.к. куча не фрагментирована. Использованный объект возвращается в пул (а не в кучу), если он больше не требуется.
Вот вопрос как раз и был об этом: какие средства язык предоставляет для автоматизации отслеживания ненужности объекта для его последующего возвращения в пул? И если средств автоматизации этого процесса нет, то насколько надежной является работа по сравнению со случаем, когда такие средства есть?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, minorlogic, Вы писали:
M>>Ах да ! Извини забыл добавить, чтобы тебе было более доступнее.
M>>Твои слова это полная чушь , которую ты повторяешь из поста в пост ... А также полный бред ..
VD>Зато твои очень убедительны, основательны и главное весомы.
Настолько весомы что даже заставили тебя улыбнуться , надеюсь и задуматься над стилем написания , а еще лучше мышления.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот вопрос как раз и был об этом: какие средства язык предоставляет для автоматизации отслеживания ненужности объекта для его последующего возвращения в пул? И если средств автоматизации этого процесса нет, то насколько надежной является работа по сравнению со случаем, когда такие средства есть?
ЖЦ и есть пул. Его не особо то имеет смысл оптимизировать.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, minorlogic, Вы писали:
M>Настолько весомы что даже заставили тебя улыбнуться , надеюсь и задуматься над стилем написания , а еще лучше мышления.
В следующий раз за такие намеки получишь по шапке.
Если нам не помогут, то мы тоже никого не пощадим.
применительно к языкам программирования — никаких надежных альтернатив GC пока не существует.
