S>>И с какой же стороны сборщик мусора в ООП смотрит ??? Каких вещей он упрощает проектирование ??? Если не следование правилу взял отдай рассматривать как проектирование , то да упрощает.
AVK>Возьми шире — подумай об управлением временем жизни объектов вобще.
S>Подумал , больше чем необходимо они жить не должны (или ОС знает скольно нужно жить объекту ??? Так может она и проги сама писать будет ??? ), процесс все равно на мой взгляд должен контролироваться программистом .
Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Здравствуйте, mihailik, Вы писали:
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
M>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
А что делать, если к нему юзер "подключился" и в этом процессе Access'а отчеты разглядывает? Меня это всегда веселило. Никакой GC или подсчет ссылок против юзера не поможет Это, извините, просто bad design.
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Я бы сказал, один из самых ресурсоемких.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
S>Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
M>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Когда тут можно процесс Access'а выключать? И что делать, если к этому Access'у ещё несколько внешниъ программ подключились?
S>А что делать, если к нему юзер "подключился" и в этом процессе Access'а отчеты разглядывает? Меня это всегда веселило. Никакой GC или подсчет ссылок против юзера не поможет Это, извините, просто bad design.
Ну, если юзер — действительно bad design и т.п. А если это сервер без интерфейса? Access "в невидимом виде"?
Это как раз и будет отличной иллюстрацией проблемы циклических ссылок. Какой-нибудь Recordset держит ссылку на ColumnCollection, а ColumnCollection держит ссылку на Recordset. Простой подсчёт ссылок такую круговую поруку не сможет освободить, тут нужно крепко сидеть и крепко комбинировать. Что чревато ошибками, утечками ресурсов.
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
S>Я бы сказал, один из самых ресурсоемких.
На RSDN'е я видел статью о сравнении GC и традиционных heap. Комментарии там хорошо проясняют суть вопроса.
Здравствуйте, mihailik, Вы писали:
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
Однако, побуксовав, с успехом решают К слову, некоторые реализации GC на циклических ссылках тоже буксуют. Например, ActivePerl такой фигней страдал.
M>>Возьми, например, какое-нибудь сложное приложение. Типа там Access. Его извне открыли, получили какие-то объекты. Потом часть объектов уже не нужна, а часть ещё нужна во внешнем коде.
M>Ну, если юзер — действительно bad design и т.п. А если это сервер без интерфейса? Access "в невидимом виде"?
Ну так нефиг примеры некорректные приводить Кстати, отделение "внешних" клиентов от "внутренних" сильно облегчает разрешение циклических ссылок. Так что выделение сервера в отдельный процесс ты зря упомянул
M>Это как раз и будет отличной иллюстрацией проблемы циклических ссылок. Какой-нибудь Recordset держит ссылку на ColumnCollection, а ColumnCollection держит ссылку на Recordset. Простой подсчёт ссылок такую круговую поруку не сможет освободить, тут нужно крепко сидеть и крепко комбинировать. Что чревато ошибками, утечками ресурсов.
Простой — не сможет, более сложный (сильные/слабые ссылки, например, или ведение списка обратных ссылок) — без особых проблем.
M>>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
S>>Я бы сказал, один из самых ресурсоемких.
M>На RSDN'е я видел статью о сравнении GC и традиционных heap. Комментарии там хорошо проясняют суть вопроса.
Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора? Так извини, там ни условий тестирования нет, ни исходников теста. Т.е. сравнивается непонятно что с непонятно чем (например, во время теста могла ни разу не запуститься процедура сборки мусора). А ты обрати внимание вот на что — в многопоточном приложении на время сборки мусора и дефрагментации памяти все потоки приходится останавливать. Либо удваивать объем памяти, потребляемой приложением. Либо не дефрагментировать память. Вот определись сначала, про какой GC ты говоришь, потому будем обсуждать его конкретные недостатки (с достоинствами, вроде, все понятно).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, mihailik, Вы писали:
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
На самом деле циклические ссылки не главно. Главное это то что GC-подобные алгоритмы не требуют явных действий для освобождения объекта непосредственно в месте, где он перестает быть нужен. Т.е. прелесть GC не в том что программисту не надо заботиться об освобождении памяти, прелесть в том что не нужно озабочиваться этим вобще никому, в том числе и рантайму. Главное это обеспечить четкий признак нужности объекта. В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
Причем применение подобных алгоритмов отнюдь не ограничивается управлением памятью. Вот буквально совсем недавно понадобилось хранить часть информации в файлах на диске, а точно отловить момент, когда файл становится ненужен было весьма затруднительно. Применение GC-подобного алгоритма позволило решить задачку весьма просто, хотя конечно ценой небольшой потери производительности и немгновенного удаления ненужных файлов.
S>Я бы сказал, один из самых ресурсоемких.
Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
Здравствуйте, Sergey, Вы писали:
S>Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора?
Здравствуйте, AndrewVK, Вы писали:
S>>Ты имеешь в виду комментарий про сравнение производительности Boehm's GC, Loki::SmallObjectAllocator и непонятно какого хипа общего назначения от непонятно какого компилятора?
AVK>http://www.rsdn.ru/article/?dotnet/GCnet.xml
Угу, как обычно — тестируется однопоточная программа. А про влияние GC на скорость работы многопоточной программы — ни слова.
Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит. Ну или QH из статьи. Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, AndrewVK, Вы писали:
M>>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
AVK>На самом деле циклические ссылки не главно. Главное это то что GC-подобные алгоритмы не требуют явных действий для освобождения объекта непосредственно в месте, где он перестает быть нужен.
И без GC не часто требуется освобождать объект руками. Я вот посчитал ради интереса количество вызовов new/delete в одном из своих проектов — 148 new и 21 delete на 936 kb исходников. Ну не использовать же из-за двух десятков delete GC.
AVK>Т.е. прелесть GC не в том что программисту не надо заботиться об освобождении памяти, прелесть в том что не нужно озабочиваться этим вобще никому, в том числе и рантайму.
Ну-ну. Это только если не считать GC частью рантайма.
AVK> Главное это обеспечить четкий признак нужности объекта.
Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
AVK> В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
Бывает и такое, хотя мне такие ситуации встречались достаточно редко.
AVK>Причем применение подобных алгоритмов отнюдь не ограничивается управлением памятью. Вот буквально совсем недавно понадобилось хранить часть информации в файлах на диске, а точно отловить момент, когда файл становится ненужен было весьма затруднительно. Применение GC-подобного алгоритма позволило решить задачку весьма просто, хотя конечно ценой небольшой потери производительности и немгновенного удаления ненужных файлов.
А я не имею ничего против применения GC-подобных алгоритмов Мне только не нравится, когда GC применят там, где он нафиг не нужен.
S>>Я бы сказал, один из самых ресурсоемких.
AVK>Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
Угу, однако если продукт труда программистов будет сильно тормозить и выжирать всю доступную системе память, то этот самый труд рискует остаться неоплаченным
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит.
Приведи тесты.
S>Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
А вот в некоторых случаях время отклика серверов приложений, написанных на джаве оказывалось заметно лучше чем их же на С++, хотя разброс был повыше. Ну а то что есть моменты, когда GC будет не лучшим решением, с этим вроде бы никто и не спорит.
Здравствуйте, Sergey, Вы писали:
AVK> Главное это обеспечить четкий признак нужности объекта.
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Нет. Ключевое отличие этих самых поинтеров от GC в том что в них надо явно указывать что объект стал не нужен. Пускай это обеспечивает компилятор, но к сожалению компилятор не сможет нам такого гарантировать в распредленной среде. Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет. Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
AVK> В результате связей в программе становится значительно меньше. Это тот самый бенефит, который несколько меняет подходы к проектированию в условиях GC.
S>Бывает и такое, хотя мне такие ситуации встречались достаточно редко.
Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
S>А я не имею ничего против применения GC-подобных алгоритмов Мне только не нравится, когда GC применят там, где он нафиг не нужен.
А где он применяется где он нафик не нужен? К чему собственно притензии?
AVK>Ресурсы это не только процессор. Труд программистов и тестеров это тоже ресурс, причем один из самых дорогостоящих и дефицитных.
S>Угу, однако если продукт труда программистов будет сильно тормозить и выжирать всю доступную системе память, то этот самый труд рискует остаться неоплаченным
Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море. Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Так вроде в Java в свое время отказались от GC по схеме подсчета ссылок, из-за ее медленности (пусть даже пара асмовых команд). Просто там очень много операция с объектами делается и накладные расходы сильно возрастают.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, AndrewVK, Вы писали:
S>>Да и для выделения мелких объектов, если нужна скорость, нет смысла использовать хип MSVC — Loki::SmallObjAllocator рулит.
AVK>Приведи тесты.
Тебе исходники показать или результаты? Исходники не раньше чем завтра, а результаты я и так помню — 1.5 — 2 раза для объектов размером ~ 50 байт.
S>>Так что мой вывод — если нужна скорость или критично минимальное время реакции, GC использовать нельзя.
AVK>А вот в некоторых случаях время отклика серверов приложений, написанных на джаве оказывалось заметно лучше чем их же на С++, хотя разброс был повыше. Ну а то что есть моменты, когда GC будет не лучшим решением, с этим вроде бы никто и не спорит.
Ну вот и замечательно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
S>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
Так вроде в Java в свое время отказались от GC по схеме подсчета ссылок, из-за ее медленности (пусть даже пара асмовых команд). Просто там очень много операция с объектами делается и накладные расходы сильно возрастают.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, AndrewVK, Вы писали:
AVK>> Главное это обеспечить четкий признак нужности объекта.
S>>Насколько я понимаю, в Boehm's GC (и базирующимися на нем Java GC и .Net GC) таким признаком служит размещение адреса объекта в стеке (объект на периметре). Ну и само собой, нужными считаются все объекты, на которые ссылаются объекты, находящиеся на периметре. Почти то же самое делается с помощью смартпойнтеров без особых затрат.
AVK>Нет. Ключевое отличие этих самых поинтеров от GC в том что в них надо явно указывать что объект стал не нужен. Пускай это обеспечивает компилятор, но к сожалению компилятор не сможет нам такого гарантировать в распредленной среде.
В распределенной среде — да, не сможет. И чистый GC тоже не сможет (либо производительность его будет никакая). В обоих случаях нужны дополнительные телодвижения.
AVK> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.
А что, уже есть распределенные реализации GC? Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок? Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.
AVK> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
Сильные/слабые ссылки + переопределение оператора new вполне помогают.
AVK>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде. В компиляторах, например, ему самое место.
AVK>А где он применяется где он нафик не нужен?
Ну например в игрушках.
AVK>К чему собственно притензии?
А претензии собственно я не предъявлял — я просто упомянул пару недостатков GC.
AVK>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.
А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?
AVK>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
M>GC решает проблему циклических ссылок. Более стандартные и типичные технологии на этом здорово буксут.
AVK>На самом деле циклические ссылки не главно.
Циклические ссылки — не главное, но принципиальное преимущество. Остальные уже больше к скорости относятся. AddRef/Release по удобству мало отличается от GC.
Например, в Дельфи можно при желании забивать на освобождение объектов:
var obj : IMyObject;
i : integer;
begin
for i:=0 to 100 do
if Random>0.5
then obj:=TMyObject.Create
end;
Здравствуйте, Sergey, Вы писали:
S>В распределенной среде — да, не сможет. И чистый GC тоже не сможет (либо производительность его будет никакая). В обоих случаях нужны дополнительные телодвижения.
Но согласись что гарантии, даваемые смартпоинтерами даже в случае единственного процесса все таки поменьше, всегда из за какого либо сбоя может не вызваться деструктор смартпоинтера.
AVK> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.
S>А что, уже есть распределенные реализации GC?
Есть, лизинг называется.
S>Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок?
Именно GC-подобный алгоритм. Никаких счетчиков ссылок.
S>Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.
Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.
AVK> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.
S>Сильные/слабые ссылки + переопределение оператора new вполне помогают.
Это все больше и больше гемороя. Уже смартпоинтеры это увеличение объема ручной работы. Причем ты никак не застрахован от того что смартпоинтер будут использовать неверно или вобще не будут использовать. А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.
AVK>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.
S>Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде.
M>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.
Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.
...
M>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.
Я бы сказал, один из самых ресурсоемких.
Заметь, не некоторые, не иногда. А именно все задачи использования компонент внешней программой прекрасно решаются без GC.
В общем у меня сложилось впечатление что основная мысль была в том что можно обойтись без GC практически всегда, а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.
AVK>А где он применяется где он нафик не нужен?
S>Ну например в игрушках.
Много видел игрушек на дотнете? Я пока ни одной, если не считать сапера, который я сам же написал и его порта под WinCE.
AVK>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.
S>А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?
Да все при том. Куча рутинной работы, вроде написания и использования смартпоинтеров со слабыми ссылками или беклогом удобству и скорости разработки не способствуют.
AVK>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.
S>Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.
Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал. Зато перед этим на дельфях страдал от утечек регулярно.
Здравствуйте, mihailik, Вы писали:
M>Циклические ссылки — не главное, но принципиальное преимущество. Остальные уже больше к скорости относятся. AddRef/Release по удобству мало отличается от GC.
Отличается. Ровно в два раза — Release не нужен
M>Например, в Дельфи можно при желании забивать на освобождение объектов:
M>
M>var obj : IMyObject;
M> i : integer;
M>begin
M> for i:=0 to 100 do
M> if Random>0.5
M> then obj:=TMyObject.Create
M>end;
M>
Это, извините, просто bad design.
