Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Чуть-чуть дополню.
SYG>Когда не надо удалять мусор, т.е. когда памяти в системе много, то прога с GC работает еще быстрее чем во вручную-кодированой-проге просто потому что во вручную-кодированой-проге Вы память освобождаете — а это отнимает время (выполнение инструкции delete занимает примерно столько же времени сколько и инструкции new).
Ну это тоже не обязательно, всё зависит от того, как оптимизирован менеджер памяти. Некоторые реализации при обработке delete не вовзращают память системе, а запоминают во внутреннем списке, чтобы при первой необходимости снова вернуть её программе. Тем самым достигается оптимизация и освобождения, и повторного выделения. По сути тоже самое делает и GC...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[6]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, adb, Вы писали:
adb>Это разные равноценные подходы. Не более. Только один предлагает явно высвобождать ресурсы, а второй неявно. При этом, как я уже сказал, во втором случае мы платим прозрачностью кода за удобство написания.
Тут уже был флейм на тему C vs С++, где одной из ключевых тем было как раз то, что освобождение ресурсов в явном виде преподносилось как плюс. Долго переубеждали и доказывали, что это всё-таки (в большинстве случаев) минус, так как основное в программе — это её бизнес-логика, а детали работы — это визуальный шум, который по возможности желательно скрыть... И вот опять 25 только теперь с блоком finally.
Блок finally, при отсутсвии деструкторов — явный шаг назад, по сравнению с C++ То есть наверное есть ситуации, где явное освобождение в finally — предпочтительнее скрытого освобождения в деструкторе, но это скорее исключения, а не правило...
Похоже что проблема не в концепции Garbage Collector, а в желании Microsoft отнять рынок (или хотя бы его часть) у Java, для чего в C# и .NET многое было передрано из Java механически и бездумно.
Деструкторы для размерных типов были бы одним из возможных решений.
Re[5]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Чуть-чуть дополню.
SYG>Когда не надо удалять мусор, т.е. когда памяти в системе много, то прога с GC работает еще быстрее чем во вручную-кодированой-проге просто потому что во вручную-кодированой-проге Вы память освобождаете — а это отнимает время (выполнение инструкции delete занимает примерно столько же времени сколько и инструкции new).
Зато в ручной проге все работает гладко и равномерно без сюрпризов. А в GC-шной котороая которая эксплуатируется в интеснсивном режиме (например интенсивный гейм) сборка мусора все откладвается, откладывается, откладывается и когда наконец все 512 мегофф исчерпаны. Программа говорит геймеру (в самый интересный момент) СТОП и начинает сборку мусора. Что приводит к припадку ярости, разрушениею монитора кувалдой и т.д. и т.п.
Re[6]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Кодт, Вы писали:
К>>Вот если бы он с символьными вычислениями игрался — тут можно было бы задуматься; а так — это всего лишь демонстрация крутизны обероновского оптимизирующего компилятора.
SYG>Вы наверное будете удивлены, но по крайней мере когда я лично присутсвовал при другом его докладе (не в CERN-е, а в Москве), то он рассказывал именно о "символьных" вычислениях. Он вычислял Фейнмановские диаграммы (интегралы) теории возмущений, в огромных количествах. Кстати, хвастался тем что его программа считает эти интегралы в миллион раз быстрее чем Mathematica.
Что, однако не мешает ей предварительно или крупными блоками резервировать память, а потом с ней работать... Тут и правда нужен исходный код...
Re[6]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, S.Yu.Gubanov, Вы писали:
S> Здесь многое зависит от менеджера памяти, но освобождение памяти более долгий процесс, при условии что нужен повторное ее использование. S> на примере менеджера памяти Delphi S>http://www.rsdn.ru/article/Delphi/memmanager.xml
S> процесс удаления значительно сложнее выделения т.к. нужно объединять свободные куски памяти. При этом апишный S> HeapFree раз в 10 медленне дельфевого Dispose
Прелесть ручного распределения в том что критический участок всегда можно соптимизировать. куча — действительно медленная штука из-за своей универсальноссти. Для конкретной ситуации можно написать свой заоптимизированный распределитель и ускорить так что любому ГЦ даже и не снилось.
Приведу еще раз те фрагменты кода котороые показывают дешевизну операций (ручная оптимизация)
// удаление:void free_( void *p ) {
block *pb = (block*)p;
chunk *c = (chunk*)((size_t)p & (size_t)chunk_mask_);
pb->next = c->free;
c->free = pb;
c->used_n--;
}
// распределение:
block* alloc_() {
block *p = cur_->free;
if ( p ) {
cur_->free = p->next;
cur_->used_n++;
return p;
}
// в эту часть входим воистину редко
// .......
}
Более того этот распределитель эксплуатируется фактически в стрессовых условиях, непрерывная круглосуточная работа и большие обьемы выделяемой удаляемой памяти до 500к обьектов (~200Мб)
Любой ГЦ бы просто здох.
Re[4]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, S.Yu.Gubanov, Вы писали:
MN>>2) как ни парадоксально звучит, но существующие реализации языков с GC усложняют процесс освобождение ресурсов.
SYG>Причина этой проблемы кроется совсем в другом. Когда Вы говорите "освобождение ресурсов", то имеете ввиду, что система со сборкой мусора работает поверх обычной древней системы и что Вы вынуждены пользоваться вот таким вот кодом: SYG>
SYG>f := FileOpen('a.txt');
SYG>
SYG>где функция FileOpen — это APIшная функция древней операционки не имеющей сборщика мусора. То есть проблема состоит во взаимодейсвии современных managed систем со старыми unmanaged системами. Такая проблема есть в Java так как Java, являясь виртуальной машиной, всегда работает поверх какой-то другой реальной машины. В Оберон-системах такой проблемы нет потому что там вся операционка написана от начала и до конца в объектно ориентированном стиле учитывающем сборщик мусора (сборщик мусора интегрирован в саму ОСь). Там в самой операционке просто нету таких опасных низкоуровневых функций как OpenFile(), CloseFile(), а значит и нету проблем связанных с Вашим "освобождением ресурсов".
Это позволит нам обойтись без явных вызовов CloseFile(), но, насколько я понял, файл будет закрыт так же "своевременно", как если бы мы поместили CloseFile() в finalize().
SYG>Я уже писал об этом: SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=725451&only=1
SYG>>Это, мягко говоря, немного устаревший способ работы с файлами. Всвязи с появлением ООП, люди уже более десятка лет с файлами работают на более высоком уровне абстракции. Могу вкратце описать как это делается в системе BlackBox от Oberon Microsystems. В этой системе для этой цели используется паттерн проектирования под названием "Carrier-Rider-Mapper". Carrier — это персистентный объект содержащий внутри себя какие-либо данные ....
[поскипан большой объем текста]
Если я верно понял, здесь ты описал классическую схему Файл — Дескрипторы(хэндлы) — Средства форматированного ввода/вывода. И "более выскокий уровень абстракции" заключается в том, что вместо подсчета ссылок Дескрипторов на Файл используется GC. Я не могу классифицировать это изменение по шкале хорошо/плохо, просто предлагаю употреблять поменьше громких слов
Тут рядом топик Насколько быстр HeapAlloc?
Я там про это и веду речь. Но обычно то кучи общие, хотя все узкие места можно (и нужно) оптимизировать.
Но GC при малом количестве живых объектов будет в любом случае самым оптимальным
при этом учитывая интервалы между сбором мусора которые могут быть весьмя продолжительными.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[5]: Сборщик мусора необходим для компонентно ориентирован
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Когда не надо удалять мусор, т.е. когда памяти в системе много, то прога с GC работает еще быстрее чем во вручную-кодированой-проге просто потому что во вручную-кодированой-проге Вы память освобождаете — а это отнимает время (выполнение инструкции delete занимает примерно столько же времени сколько и инструкции new). Шито по воде белыми вилами. Это все очень сильно зависит от менеджера памяти.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Уж послали в "сад", так я и пришёл.
SYG>Сборщик мусора необходим для компонентно ориентированного программирования.
SYG>Вот, вынес в отдельную ветку тему о необходимости сборщика мусора в компонентно ориентированных системах. Более десяти лет назад люди поняли, что полноценные компонентные (модульные) системы невозможны без наличия единого сборщика мусора.
Так... медленнно, по буквам. Компонетная система начинается с определения понятия "компонент", и "среда работы компонента". Она может быть как с GC, так и без GC.
Да, невозможно зафиксировать момент удаления объекта, если он — разделяемый и циклы существования пользователей никак между собой не связаны (к примеру — синглтон). Модуль — разделяемая сущность, поэтому для неё необходим или счётчик ссылок, или "подметатель". Счётчик ссылок в данном случае — дешевле и очевидней, поскольку в таком случае можно отслеживать только моменты создания/удаления объектов, а не весь периметр ссылок на них. Да и сама структура ссылок может быть приведена к простейшей: указателю на область памяти. Причём тут обязательность GC?
Так что, ИМХО, исходный тезис неправомерен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Модуль — разделяемая сущность, поэтому для неё необходим или счётчик ссылок, или "подметатель".
...
ГВ>Так что, ИМХО, исходный тезис неправомерен.
Вы перепутали модули с объектами. Модули создают объекты и отдают эти объекты другим модулям и т.д. Уборка мусора нужна для объектов. А что касается модулей, то они грузятся в систему загрузчиком, динамически линкуются и остаются в памяти пока их явно не выгрузят.
и доказывали, что это всё-таки (в большинстве случаев) минус, так как основное в программе — это её бизнес-логика, а детали работы — это визуальный шум, который по возможности желательно скрыть... 
Шито по воде белыми вилами. Это все очень сильно зависит от менеджера памяти.
