А так ли нужен сборщик мусора?

← →
Alkid (2009-01-02 19:17) [160]

> oxffff © (02.01.09 15:26) [156]
> При вызове сборщиком мусора финализатора, код финализатора
> может содержать time consuming операции. Для единичных объектов
> это может не являться проблемой.

Не являюсь экспертом по тому, как в .NET работает GC, но, ЕМНИП, финализаторы там исполняются в отдельном потоке *после* цикла сборки мусора, который требует останова всех рабочих потоков.

← →
oxffff © (2009-01-02 23:08) [161]

> boa_kaa © (02.01.09 17:55) [158]
>
> > oxffff © (02.01.09 15:26) [156]
>
> А когда вызывается TForm.Free разве не останавливается выполнение?

Других потоков? Нет. Речь шла о них.

>
>
> А если контролов много и пошли по цепочке?
> А описанную проблему с остановкой мне приходилось реально
> видеть только на Mono. Причем богом затертой версии.
>
> Не понимаю, что ты хочешь доказать? Что сборщик - это мировое
> зло? Давай это объясним разработчикам The Bat!, которые
> за собой столько мусора оставляют...
>
>
> > Все это наводит на простые мысли, что определенного круга
>
> > задач программист должен использовать другую логику освобождения
>
> а я тебе уже устал об этом говорить
>
> Для всего есть одно объяснение: не умеешь - не берись

Ты снова продолжаешь считать себя экспертом.
Если продолжаешь себя им считать тогда тебе вопрос
В .NET есть понятие controlled mutability pointer.
Какие инструкции его генерируют, чем он отличается от простого managed pointer и самое главное для чего его ввели.
Ответишь, тогда я хотя бы буду считать что твои знания не меньше моих.
Но экспертом я себя не считаю.

← →
oxffff © (2009-01-02 23:27) [162]

> Alkid (02.01.09 19:17) [160]

Да так и есть. Однако сам этот поток имеет приоритет более высокий, чем рабочие потоки. Поэтому косвенно влияет на квант рабочим потокам.
Также этом поток может быть остановле входом состояние ожидания финализатором. Ну и тут Microsoft позаботился.
Но!!!
Однако сам процесс входа в состояние останова и дефрагментация может болезненно ударить по отклику приложения. Естественно речь идет не о GUI приложениях.

P.S. Но самое интересное, что освобождая некий ресурс в finalizator нужно хорошенько подумать и не выйдет ли это боком.

← →
boa_kaa © (2009-01-03 00:35) [163]

> oxffff © (02.01.09 23:08) [161]

> Ты снова продолжаешь считать себя экспертом.

где это было написано?
это ссылка на Рихтера произвела такой фурор?
за что же ты его так не любишь?

> Если продолжаешь себя им считать тогда тебе вопрос
> В .NET есть понятие controlled mutability pointer.
> Какие инструкции его генерируют, чем он отличается от простого
> managed pointer и самое главное для чего его ввели.

вот тебе встречный вопрос: какое отношение они имеют к теме?
просто ты про них знаешь и решил поумничать?
почитай вот тут: http://www.litera.ru/stixiya/authors/griboedov/
кстати, приколов с упаковкой вообще масса
и если любая сложность на тебя влияет так, что ты начинаешь орать "масдай", то сходи в баньке попарься, успокоительного глотни, в позе лотоса посиди

> Ответишь, тогда я хотя бы буду считать что твои знания не
> меньше моих.

ты серьезно думаешь, что в противном случае я расстроюсь?

> Но экспертом я себя не считаю.

и я тебя тоже не считаю
потому что если бы был, то не нападал бы в стиле детского сада "а вот докажи"

← →
oxffff © (2009-01-03 00:58) [164]

> boa_kaa © (03.01.09 00:35) [163]
>
> > oxffff © (02.01.09 23:08) [161]
>
> > Ты снова продолжаешь считать себя экспертом.
>
> где это было написано?
> это ссылка на Рихтера произвела такой фурор?
> за что же ты его так не любишь?
>

Ты продолжаешь доказывать, что GC это решение на все случаи жизни.
Я тебе привожу особености устройства работы(я не называю это недостатками) GC, которые могут создать проблемы для определенной части приложений.
Я читаю не только Рихтера.
Но и более детальное материалы:

1. ECMA-335.
2. Expert .NET 2.0 IL Assembler (Serge Lidin)
3. Design and Implementation of Generics for the
.NET Common Language Runtime (Andrew Kennedy Don Syme)

Ты хоть про такие слышал?

> > Если продолжаешь себя им считать тогда тебе вопрос
> > В .NET есть понятие controlled mutability pointer.
> > Какие инструкции его генерируют, чем он отличается от
> простого
> > managed pointer и самое главное для чего его ввели.
>
> вот тебе встречный вопрос: какое отношение они имеют к теме?
> просто ты про них знаешь и решил поумничать?

Да я про них знаю и не только про них.
Я тебя уже намекал, что твои заявления не подкреплены хотя бы примерами, твоими рассуждениями. А являются другой формой "сам дурак".
Это не серьезно. Продемострируй свою правоту в доказательной форме.

> почитай вот тут: http://www.litera.ru/stixiya/authors/griboedov/
> кстати, приколов с упаковкой вообще масса
> и если любая сложность на тебя влияет так, что ты начинаешь
> орать "масдай", то сходи в баньке попарься, успокоительного
> глотни, в позе лотоса посиди
>
> > Ответишь, тогда я хотя бы буду считать что твои знания
> не
> > меньше моих.
>
> ты серьезно думаешь, что в противном случае я расстроюсь?
>

Расстраиваться не нужно. Нужно взять и прочитать.

1. ECMA-335.
2. Expert .NET 2.0 IL Assembler (Serge Lidin)
3. Design and Implementation of Generics for the
.NET Common Language Runtime (Andrew Kennedy Don Syme)

>
> > Но экспертом я себя не считаю.
>
> и я тебя тоже не считаю
> потому что если бы был, то не нападал бы в стиле детского
> сада "а вот докажи"

Я от тебя все жду, что ты хоть подкрепишь свои слова "сам дурак" хотя бы техническими рассуждениями с конкретикой работы, что позволит нам (всем) сделать вывод, что существуют реализовать работу с GC так, чтобы использовать срезу с GC как решение для промышеленного оборудования.

← →
oxffff © (2009-01-03 01:00) [165]

> существуют реализовать работу с GC так, чтобы использовать
> срезу с GC как решение для промышеленного оборудования.
>

существуют способы реализовать работу с GC так, чтобы использовать
среду с GC как решение для промышеленного оборудования.

← →
Игорь Шевченко © (2009-01-03 01:10) [166]

oxffff © (03.01.09 00:58) [164]

У меня вопрос - ты, собственно, что пытаешься доказать ?
Что "GC может создать проблемы для определенной части приложений" ?

Ну и хрен бы с ними, с этими проблемами и с определенной частью приложений - гораздо больше проблем создадут кривые руки программистов, а сборщик мусора упрощает процесс программирования вообще, вне зависимости от кривизны рук - я тут уже приводил ссылку на Джоэла Спольски и приводил еще одного автора - Эрика Рэймонда, которые считают, что чем меньше строк в коде при прочих равных условиях, тем он лучше со всех сторон.

Грубо говоря, код вида

var Foo: TBar; begin Foo := TBar.Create; ..... end;

лучше чем

var Foo: TBar; begin Foo := TBar.Create; try ..... finally Foo.Free; end; end;

Лучше значит - проще, понятней, сопровождабельнее.

А вся остальная заумь типа Expert .NET 2.0 IL Assembler - это для яйцеголовых, то есть, для ничтожной части программистов, которым по-настоящему нужно вникать во все эти дебри в узком кругу ограниченных задач.

← →
oxffff © (2009-01-03 01:21) [167]

> Игорь Шевченко © (03.01.09 01:10) [166]
> oxffff © (03.01.09 00:58) [164]
>
> У меня вопрос - ты, собственно, что пытаешься доказать ?
>

Я пытаюсь продемострировать, что работа GC может создать трудности для определенной части приложений.
Сам Рихтер например рекомендует отказаться от использования finalizators насколько это возможно.
И признает что правильный с точки зрения логики кода финализатора может оказаться не таким уж и правильным с точки зрения его работы.

← →
oxffff © (2009-01-03 01:27) [168]

> А вся остальная заумь типа Expert .NET 2.0 IL Assembler
> - это для яйцеголовых, то есть, для ничтожной части программистов,
> которым по-настоящему нужно вникать во все эти дебри в
> узком кругу ограниченных задач.

Проблема больше даже не в этом, а в том, что у .NET большая библиотека на все случаи жизни, которой пользуется программист .NET (.ТПУ).
И ее код вылизывается в Microsoft большой бандой людей. В том числе и информацией из bug list. Поэтому ошибки при программировании под .NET в этой части менее заметны.

← →
oxffff © (2009-01-03 01:36) [169]

> Поэтому ошибки при программировании под .NET в этой части
> менее заметны.

Однако шаблон IDiposable который предлагают в качестве способа детерминированой финализации, может создать не меньше проблем, если
не четко следовать инструкции по этому шаблону. Достаточно закоментировать выделенную строку и можно отгрести в первого взгляда "непонятные ошибки"

// Allow your Dispose method to be called multiple times,
// but throw an exception if the object has been disposed.
// Whenever you do something with this class,
// check to see if it has been disposed.
public void DoSomething()
{
if(this.disposed) {
throw new ObjectDisposedException();
}

А в том, что немаленькая часть программистов .ТПУ не всегда соблюдает правила, я более чем уверен.

← →
oxffff © (2009-01-03 01:37) [170]

> .ТПУ

.ПТУ.

← →
oxffff © (2009-01-03 01:39) [171]

> Достаточно закоментировать выделенную строку и можно отгрести
> в первого взгляда "непонятные ошибки"

Имеется ввиду не конкретно исключение ObjectDisposedException.

← →
Johnmen © (2009-01-03 01:42) [172]

> oxffff ©

Эк тебя припёрло...:)
А стОит ли?

← →
Игорь Шевченко © (2009-01-03 01:43) [173]

oxffff © (03.01.09 01:21) [167]

> Я пытаюсь продемострировать, что работа GC может создать
> трудности для определенной части приложений.

Для какой части приложений, если не затруднит ?

Написано довольно много кода на скриптовых языках, где управление памятью автоматическое, написано еще больше кода на Java, где используется сборщик мусора - как все эти приложения работают, если GC создает трудности и Рихтер рекомендует ?

Я понимаю, что тонкости вполне могут вылезать в определенные моменты в не менее определенных приложениях - однако, куда девать тот самый написанный работающий код ? :)

← →
oxffff © (2009-01-03 01:46) [174]

> Johnmen © (03.01.09 01:42) [172]
>
> > oxffff ©
>
> Эк тебя припёрло...:)
> А стОит ли?

Я закончил делать уже на вчера ремонт, подумал нужно срочно помыться, лечь пораньше спать и завтра(уже сегодня) встать пораньше, чтобы доштукатурить стену, вставить дверь, доделать проводку. Но залез на любимый форум. И понеслась. :)

← →
Johnmen © (2009-01-03 01:47) [175]

> Игорь Шевченко ©

Bujhm? lfdfq kexit ghj k.,bvsq keyysq nhfrnjh xnj-kb///

← →
boa_kaa © (2009-01-03 01:48) [176]

> Я от тебя все жду, что ты хоть подкрепишь свои слова "сам
> дурак" хотя бы техническими рассуждениями с конкретикой
> работы, что позволит нам (всем) сделать вывод, что существуют
> реализовать работу с GC так, чтобы использовать срезу с
> GC как решение для промышеленного оборудования.

ты либо не читаешь, что я пишу, либо не не понимаешь, либо игнорируешь
во всех трех случаях идешь лесом, ибо достал
кстати, дураком я тебя не считаю

← →
Johnmen © (2009-01-03 01:49) [177]

> oxffff © (03.01.09 01:46) [174]

Вот правильный ты человек. И зачем тебе эти смещения? :)

← →
Johnmen © (2009-01-03 01:50) [178]

> boa_kaa © (03.01.09 01:48) [176]
> кстати, дураком я тебя не считаю

Этот реверанс может не помочь...:)))

← →
Германн © (2009-01-03 01:50) [179]

Ещё один холивар, однако.
Давайте все вернёмся на С и на Pascal. Самые ярые противники "встроенных механизмов" могут вернуться на ASM.
Вот только "кривые руки" исправить нереально.

← →
oxffff © (2009-01-03 01:53) [180]

> Игорь Шевченко © (03.01.09 01:43) [173]
> oxffff © (03.01.09 01:21) [167]
>
>
> > Я пытаюсь продемострировать, что работа GC может создать
>
> > трудности для определенной части приложений.
>

Для критичных с точки зрения отклика приложений. Например я уже написал выше. Система распознавания изображений.

>
> Для какой части приложений, если не затруднит ?
>
> Написано довольно много кода на скриптовых языках, где управление
> памятью автоматическое, написано еще больше кода на Java,
> где используется сборщик мусора - как все эти приложения
> работают, если GC создает трудности и Рихтер рекомендует
> ?

В том то и проблема, что отловить ошибки становится все трудней, а стандартная библиотека пишется таким образом, чтобы не генерировать исключения, а возвращать коды. Однако, если в native Delphi приложении можно сравнительно быстро получить AV по мертвому объекту, если не проверять коды возврата, то с GC молучить такой AV никогда, поскольку объект жив и совершенно ничего что его состояние мертвое.
Вот так и работают с неуловимыми ошибками.

>
> Я понимаю, что тонкости вполне могут вылезать в определенные
> моменты в не менее определенных приложениях - однако, куда
> девать тот самый написанный работающий код ? :)

Вот так и работают с неуловимыми ошибками.

← →
Johnmen © (2009-01-03 01:54) [181]

> Германн © (03.01.09 01:50) [179]
> Вот только "кривые руки" исправить нереально.

Да и не стОит.
Аминь...

← →
Eraser © (2009-01-03 02:03) [182]

> [179] Германн © (03.01.09 01:50)

бОльшая часть софта написана как раз криворукими программистами, зачастую программированием занимающимися по совместительству. это не т.н. коробочный софт (хотя есть и исключения), а специализированный софт, разработанный для какой-то конкретной предметной области для какого-то конкретного предприятия.
так что еще как реально исправить кривые руки, GC этому сильно способствует, за что ему и спасибо. по крайней мере утечек нет, в отличие от программ на Делфи. знали бы вы сколько народа пишет тот самый софт на обычном делфи, даже не подозревая, что нужно вызывать какие-то деструкторы.. и ничего, софт работает. ну вешает систему раз в день - эт мелочи. приходят на форум делфи-мастер и спрашивают как написать программу, которая перезапускает компьютер раз в день )
написать хоть как-то работающее реальное приложение на asm кривыми руками проблемотично.

← →
oxffff © (2009-01-03 02:05) [183]

> boa_kaa © (03.01.09 01:48) [176]
>
> > Я от тебя все жду, что ты хоть подкрепишь свои слова "сам
>
> > дурак" хотя бы техническими рассуждениями с конкретикой
>
> > работы, что позволит нам (всем) сделать вывод, что существуют
>
> > реализовать работу с GC так, чтобы использовать срезу
> с
> > GC как решение для промышеленного оборудования.
>
> ты либо не читаешь, что я пишу, либо не не понимаешь, либо
> игнорируешь
> во всех трех случаях идешь лесом, ибо достал

Последняя строка наиболее доказательная часть твоего утверждения.
Жаль что тратил на тебя время.

> кстати, дураком я тебя не считаю

Без комментариев.

← →
Германн © (2009-01-03 02:13) [184]

> Eraser © (03.01.09 02:03) [182]
>
> > [179] Германн © (03.01.09 01:50)
>
> бОльшая часть софта написана как раз криворукими программистами,
> зачастую программированием занимающимися по совместительству.
> это не т.н. коробочный софт (хотя есть и исключения), а
> специализированный софт, разработанный для какой-то конкретной
> предметной области для какого-то конкретного предприятия.
>

Вот вот. И сколько я затратил времени и нервов, чтобы эти ЗЧ ака криворукие программисты, пользовались чем-то, что реально помогло бы исправить или хотя бы минимизировать их криворукость!
Ну например. Я настоял чтобы контора наша купила Эврику. Контора купила. Но вот заставить этих ЗЧ её использовать так и не удалось! Посему наша техподдержка до сих пор порою встаёт на уши получая от пользователей "доморощенные" сообщения об ошибках.

← →
XentaAbsenta © (2009-01-03 03:40) [185]

Игорь Шевченко © (03.01.09 01:10) [166]
Когда делфи дорастёт до объектов на стеке - тогда приведённый тобой код будет абсолютно бессмысленным, а сейчас я бы предпочёл истинно стековые объекты в C#.
И Джоел Спольски - не такой уж авторитет, многие о нём даже не слышали, и при этом немного потеряли. Кривые руки - это проблема криворуких, и GC тут ничем помочь не может.

← →
XentaAbsenta © (2009-01-03 03:56) [186]

oxffff © (03.01.09 01:36) [169]

> Однако шаблон IDiposable который предлагают в качестве способа
> детерминированой финализации, может создать не меньше проблем
>....

+1

← →
Игорь Шевченко © (2009-01-03 13:38) [187]

oxffff © (03.01.09 01:53) [180]

> Для критичных с точки зрения отклика приложений.

Их надо обязательно писать на .Net ? Месье понимает толк в извращениях...

> Например я уже написал выше. Система распознавания изображений.

Сколько не видел систем распознавания изображений, нигде минимизация времени отклика не ставилась во главу угла.
Опять я что-то не то видел.

← →
Игорь Шевченко © (2009-01-03 13:39) [188]

XentaAbsenta © (03.01.09 03:40) [185]

> И Джоел Спольски - не такой уж авторитет, многие о нём даже
> не слышали, и при этом немного потеряли

Кругозор нефигово бы расширить

> Игорь Шевченко © (03.01.09 13:38) [187]

Есть разные системы распознавания, например в моем случае(я не писал эту систему, я просто ее пользователь), где в определенные моменты в течение 1-15 мин необходимо принимать входящий видеопоток(его буферизация не поддерживается) сохранять его в памяти, дальше уже делать само разпознавание. Если в момент захвата raw видеопотока уйти на сбор мусора, то гарантированно можно получить потерю важных кадров.

> Игорь Шевченко © (03.01.09 13:38) [187]
> oxffff © (03.01.09 01:53) [180]
>
>
> > Для критичных с точки зрения отклика приложений.
>
>
> Их надо обязательно писать на .Net ? Месье понимает толк
> в извращениях...

Вы ничего не перепутали?
Я то как раз и остаиваю точку зрения, что не все можно написать на .NET.
И разработчикам пришлось делать нехитрые манипуляции, чтобы сбор мусора проходил не в момент захвата.

oxffff © (03.01.09 16:44) [189]

> Вы ничего не перепутали?

Нет, я ничего не перепутал. Помимо сборки мусора у .Net есть еще факторы, не способствующие быстродействию, например, Just-In-Time компиляция.

> Я то как раз и остаиваю точку зрения, что не все можно написать
> на .NET.

Ради бога, отстаивай. Я просто не понимаю, причем здесь утверждение, что не все можно написать на .Net (точнее, не все имеет смысл писать на .Net - написать можно многое и на чем угодно, вопрос только - зачем) и оценка сборщика мусора, вынесенная в заголовок темы. По-моему, дискуссия ушла несколько не туда.

> И разработчикам пришлось делать нехитрые манипуляции, чтобы
> сбор мусора проходил не в момент захвата.

У разработчиков, по-видимому, дофига времени

> Игорь Шевченко © (03.01.09 17:07) [190]
> oxffff © (03.01.09 16:44) [189]
>
>
> > Вы ничего не перепутали?
>
>
> Нет, я ничего не перепутал. Помимо сборки мусора у .Net
> есть еще факторы, не способствующие быстродействию, например,
> Just-In-Time компиляция.

Есть средства для борьбы с этим NGEN.

← →
Анти.ПТУ (2009-01-03 21:50) [192]

Удалено модератором
Примечание: Рано вышел

> oxffff © (03.01.09 16:44) [189]

А я думаю что сборщик муссора и Just-In-Time компиляция это будущие. И такии программы будут не то что медленее работать, а быстрее или также. А вот разрабатывать будет проще. Просто пока эти вещи еще долеки от своего совершенства вот лет через 5-10.

> написать хоть как-то работающее реальное приложение на asm
> кривыми руками проблемотично.

Ты неповеришь, но на асаме его чуть ли не больше. Просто криворучек поменьше будет.

> Pavia © (04.01.09 05:17) [193]
>
> > oxffff © (03.01.09 16:44) [189]
>
> А я думаю что сборщик муссора и Just-In-Time компиляция
> это будущие. И такии программы будут не то что медленее
> работать, а быстрее или также. А вот разрабатывать будет
> проще. Просто пока эти вещи еще долеки от своего совершенства
> вот лет через 5-10.

Интересная логика.
Вы видили IL набор?
Хочется ли вам того или не хочется, но .NET должен лезть в неуправляемый код за той функциональностью которой нет в IL наборе. А такой функциональности подавляющая часть. Для этой цели(лезем в native) в IL есть инструкция

calli – indirect method call
Format Assembly Format Description
29 <T> calli callsitedescr Call method indicated on the stack with arguments described by callsitedescr.
......

The ftn argument is assumed to be a pointer to native code (of the target machine) that can be legitimately called with the arguments described by callsitedescr (a metadata token for a stand-alone signature). Such a pointer can be created using the ldftn or ldvirtftn instructions, or could have been passed in from native code.

Так вот, отсюда следует, что вызов этот идет через native инструкцию
call, если конечно у инструкции нет tail. prefix , который shall immediately precede a call, calli, or callvirt instruction. It indicates that the current method’s stack frame is no longer required and thus can be removed before the call instruction is executed. Because the value returned by the call will be the value returned by this method, the call can be converted into a cross-method jump.

А отсюда следует, прощай inline native кода. То есть как минимум потери на этом вызове. Так что хотите вы этого или нет.
Но .NET спасает только мощь процессора. И хороший prefetch кода по call переходу.

Хотя в delphi вызов API функции тоже идет через некоторый stub. :)

> А отсюда следует, прощай inline native кода. То есть как
> минимум потери на этом вызове. Так что хотите вы этого или
> нет.
> Но .NET спасает только мощь процессора. И хороший prefetch
> кода по call переходу.

Я всеже дополню свою мысль. Я думаю, что в Mircosoft тоже ребята непростые работают. Поэтому возможно придумали некий динамический inline native кода, но для этого код должен быть специальным образом написан и описан некоторой метаинформацией для JIT компилятора.
Хотя чего не сделаешь для продвижения .NET.

Eraser © (03.01.09 02:03) [182]

> написать хоть как-то работающее реальное приложение на asm
> кривыми руками проблемотично.

Это неверное утверждение. Вне зависимости от языка программирования кривые руки порождают кривые приложения. На асме его чуть дольше писать, только и разницы.

> oxffff © (04.01.09 11:01) [195]

NET он оптимальнее для работы с объектами. Поэтому тут именно и стоти ждать прирост. А то что родные(native) команды платформы нужно вызывать через call так это ничего. Это всеравно что жаловаться что процедуры через call вызываются. Он для этого и предназначен. Что касается инлине, то я думаю что в скором будущем введут intrinsics в NET. Тогда всем станет хорошо.

> NET он оптимальнее для работы с объектами.

Получается что другие языки менее оптимальные?

А так ли нужен сборщик мусора? Найти похожие ветки