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

← →
Eraser © (2008-12-26 17:17) [80]

> [79] test (26.12.08 11:16)

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

← →
test (2008-12-27 13:00) [81]

Eraser © (26.12.08 17:17) [80]
Обычно это достигается, нативной частью.

← →
tesseract © (2008-12-27 22:02) [82]

> как хорошая платформа для серверных приложений.

А разрабатывалась для стиральных машинок :-) Виртуальная машина имеет свои преимущества, особенно в среде 1- wire и иже в виду резкого снижения затрат именно на программировании контроллеров - огромное преимущество, там специалист по нативным приложениям редок и пуглив. А свин он и есть свин - пришлепка к идее именно сервлетов, как сердца всего. ИМХО mono для программирования именно кроссплатформенной части толстого клиента значительно оправданнее. Мне кажеться .Net и создавался MS именно для интервенции в *nix системы. Причем интервенция прошла не за счет самого Билли, а за счет Netware.

← →
Eraser © (2008-12-27 22:07) [83]

> ИМХО mono для программирования именно кроссплатформенной
> части толстого клиента значительно оправданнее

чем оправданнее?

← →
tesseract © (2008-12-27 22:12) [84]

> чем оправданнее?

Сроками сдачи проекта, и удобством интерфейса. Правда сильно мешает размер фрэймворка в винде и удобство интеграции в браузер. Здесь ява явно лидирует, но интерфейс всё равно тошнотворный и наши любимые тормоза в свине.

← →
Johnmen © (2008-12-27 22:14) [85]

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

Без него мы все умрём в помоях....

← →
boa_kaa © (2008-12-27 22:16) [86]

> tesseract © (27.12.08 22:02) [82]
> ИМХО mono для программирования именно кроссплатформенной
> части толстого клиента значительно оправданнее.

блин, я сплю, что ли? 8-)

← →
Eraser © (2008-12-27 22:17) [87]

> [84] tesseract © (27.12.08 22:12)

хм. не наблюдаю особых тормозов со свином, но если уж проблема в этом - никто не запрещает использовать его прямого конкурента - SWT. в эклипсе используется именно SWT, а вот NetBeans написан на swing.

← →
Johnmen © (2008-12-27 22:17) [88]

> boa_kaa © (27.12.08 22:16) [86]
> блин, я сплю, что ли? 8-)

Ты уже умер...

← →
Городской Шаман (2008-12-27 22:53) [89]

> Johnmen © (27.12.08 22:14) [85]
>
>
> > А так ли нужен сборщик мусора?
>
> Без него мы все умрём в помоях....

Чисто не там где убирают...

← →
Johnmen © (2008-12-27 23:12) [90]

> Городской Шаман (27.12.08 22:53) [89]
> Чисто не там где убирают...

Знаю-знаю, проходили...

← →
test (2008-12-28 07:25) [91]

Eraser © (27.12.08 22:17) [87]
Исходники его посмотри и возрадуйся. Я как то видел переменную virginity в их исходниках, она за проверку задачи на второй запуск отвечала ))

Сборщик мусора не понацея, поскольку удалять ты ничего не можеш
/*
obj = null; // не удаление, а присваевание значения
*/
то писать надо еще более осторожно чем в языках с возможностью удаления.
Например String.replaceAll(text,text) вроде бы все впорядке только она на каждый вызов создает обьект в памяти который удалиться не скоро.
Причем класс String часть языка Java.

← →
Mystic © (2008-12-28 13:47) [92]

> В нескольких местах он забывал "убирать за собой".

В последних версиях Delphi первая строка в проекте это ReportMemoryLeakOnShutdown := True; В более ранних пишу свой небольшой модуль, который подключаю первым, и который просто проверяет была утечка или нет.

> Городской Шаман (24.12.08 20:45) [8]

Там скорее всего говорилось про реализацию HeapAlloc.

> Тогда чем не устраивают interface или smart_ptr<>, кроме
> кольцевых ссылок (которые встречаются довольно редко и их
> можно разрулить) оно будет работать не хуже GC?

Еще weak указатели могут разрулить большую часть кольцевых ссылок. Но это надо ломать мозги как все организовать. А так тыц и работает. Не возникает ситуации, когда в силу изменившихся требований надо переиначить систему, и единственная проблема это стратегия освобождения объектов.

> XentaAbsenta © (25.12.08 04:30) [21]

Во многом зависит от специфики задачи. Конечно, если в проекте много системных задач, то их лучше реализовать на чем-то, дающим тебе больше контроля над жизнью объектов.

> ИМХО С++ обладает достаточным сборщиком.

Программисты C++ любят шутить на эту тему, что лучший язык, это язык который не порождает мусора :)

> я сейчас как раз плотно работаю почти одновременно на Делфи
> и NetBeans - последний ощутимо шустрее работает

Я с Java не сталкивался, но пятый Delphi у меня просто летает :)

← →
Mystic © (2008-12-28 14:09) [93]

А по сабжу мое мнение можно резюмировать следующим образом: можно разрабатывать программы как со сборкой мусора, так и без оной. На вкус и цвет, да и от задачи зависит. От коллектива в конце концов. При этом зачастую есть ресурсы, за которыми надо следить вручную в обеих моделях. Если человек начинает следить за некоторым типом ресурсов вручную, то из-за невнимательности то тут то там он начинает пропускать освобождение того или иного ресурса. И тут, как по мне, очень важно, чтобы был механизм учета таких утечек. Чтобы после выхода из программы отладчик ткнул меня носом: тут не освобожден IDisposable объект или утечка памяти.

← →
Городской Шаман (2008-12-28 18:03) [94]

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

← →
Eraser © (2008-12-28 18:08) [95]

> [94] Городской Шаман (28.12.08 18:03)

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

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

← →
Alkid (2008-12-28 19:28) [96]

> Городской Шаман (28.12.08 18:03) [94]
> Eraser © (28.12.08 18:08) [95]

Господа, а давайте в числах выражать подобные мысли? :)
В процентах, часах наработки на отказ и т.п. :)

← →
Городской Шаман (2008-12-28 20:13) [97]

> Eraser © (28.12.08 18:08) [95]

Угу позволяет просто решить те проблемы, которых в языках с детерминированной сборкой мусора (Delphi, C++) просто не существовало.

← →
boa_kaa © (2008-12-28 20:16) [98]

мужчины, а вам еще не надоело?
шли бы елку лучше б нарядили...

← →
Городской Шаман (2008-12-28 20:16) [99]

> Alkid (28.12.08 19:28) [96]
>
>
> > Городской Шаман (28.12.08 18:03) [94]
> > Eraser © (28.12.08 18:08) [95]
>
> Господа, а давайте в числах выражать подобные мысли? :)
> В процентах, часах наработки на отказ и т.п. :)

Если смотреть на отказоустойчивость программ на Delphi и .NET(не знаю на каком языке их писали), то фриварные продакшн-программы на Delphi в среднем более стабильны. Не знаю, глюки это VM, jit-компилятора, GC или программистов, но факт налицо.

← →
Alkid (2008-12-28 20:48) [100]

> Городской Шаман (28.12.08 20:16) [99]
> Если смотреть на отказоустойчивость программ на Delphi и
> .NET(не знаю на каком языке их писали), то фриварные продакшн-
> программы на Delphi в среднем более стабильны. Не знаю,
> глюки это VM, jit-компилятора, GC или программистов, но
> факт налицо.

"Огласите весь список, пожалуйста" (с).

← →
Игорь Шевченко © (2008-12-28 21:26) [101]

Городской Шаман (28.12.08 20:16) [99]

Ты проводил исследования ? Где можно ознакомится с результатами ?

← →
@!!ex © (2008-12-29 02:39) [102]

> Ты проводил исследования ? Где можно ознакомится с результатами
> ?

Вероятно магия подсказала.
Результаты можете узнать у ближайшей ведьмы.
Сеанс платный.

← →
test (2008-12-29 09:04) [103]

Игорь Шевченко © (28.12.08 21:26) [101]
@!!ex © (29.12.08 02:39) [102]

Мои проги

Исходные задачи
1. 24/7 перелопатить много текста в виде сервиса язык Java, только после вдумчевого управления удаления обьктов это начало работать, до этого постоянные проблемы с памятью приклад просто забивал всю память и висел.
2. 24/7 полученные данные сложить в БД во много потоков язык Дельфи, надо было просто написать, проблем с мусором вообще не было.

Такие факты подойдут?

← →
G.N. (2008-12-29 09:20) [104]

test (29.12.08 09:04) [103]

>1. 24/7 перелопатить много текста в виде сервиса язык Java, только после вдумчевого управления удаления обьктов
>только после вдумчевого управления удаления обьктов
>вдумчевого
>обьктов

Простите, вы уже празднуете?
Да, и не лишне было бы узнать, соотношение времени, которое вы уделяли программированию на Delphi/Java в течение всей вашей практики программирования?

← →
test (2008-12-29 10:23) [105]

G.N. (29.12.08 09:20) [104]
На Дельфи года 4 стажа, на Java года 3 стажа.

← →
Вариант (2008-12-29 10:30) [106]

> test (29.12.08 09:04) [103]

Исходные задачи
1) 24/7 перелопатить много чужого текста в виде сервиса на Дельфи, только после ...полгода убил одним словом и только тогда стало работать, до этого постоянные проблемы с памятью, приклад просто забивал всю память и висел, а так же отжирал хэндлы .
2) 24/7 полученные по TCP данные сложить в БД, приложение многопоточное на C#, проблем с мусором вообще не было.

← →
Игорь Шевченко © (2008-12-29 12:08) [107]

test (29.12.08 09:04) [103]

> Мои проги

Ну это несерьезно.

← →
test (2008-12-29 12:22) [108]

Игорь Шевченко © (29.12.08 12:08) [107]
А что серьезно?

← →
StriderMan (2008-12-29 13:14) [109]

Interface тоже препогано устроен. Я наступал на такие грабли, что в одном месте ссылка хранится как на обычный объект а в другом - на интерфейс этого же объекта. Так вот при освобождении ссылки на интерфейс объект оказывался прибитым. Это нормальное поведение или руки неоттуда растут? :)

← →
Alkid (2008-12-29 13:42) [110]

> StriderMan (29.12.08 13:14) [109]

Это руки не оттуда растут :)
Просто смешивать в рамках одной программы обращения и по интерфейсным ссылка и по "обычным" объектным ссылкам не рекомендуется в силу из сильно разной семантики управления временем жизни объекта. В качестве паллиатива можно отключить в объекте механизм подсчёта ссылок. Но всё равно останется сильный трабл - если у тебя объект был уничтожен ДО того, как все интерфейсные ссылки на него обнулены, то при попытке что-то присвоить такой "висящей" ссылке nil или ссылку на другой объект, ты словишь AV, ибо будет попытка вызова метода Release у дохлого объекта. В качестве паллиатива для паллиатива можно присваивать значение nil при помощи выражения
Pointer(InterfacePtr) := nil
Но это уже будет кривизна второго порядка.
Вообщем, лучше не смешивай.

← →
Alkid (2008-12-29 13:44) [111]

> test (29.12.08 12:22) [108]
> А что серьезно?

Провести обзор достаточно большого количества программ сравнимых характеристик (т.е. не сравнивать notepad с серверным приложением) и написанных с использованием разных технологий. Это достаточно сложное и дорогое исследование получится.

← →
Городской Шаман (2008-12-29 17:12) [112]

> Alkid (28.12.08 20:48) [100]
> > Городской Шаман (28.12.08 20:16) [99]
> > Если смотреть на отказоустойчивость программ на Delphi и
> > .NET(не знаю на каком языке их писали), то фриварные продакшн-
> > программы на Delphi в среднем более стабильны. Не знаю,
> > глюки это VM, jit-компилятора, GC или программистов, но
> > факт налицо.
>
> "Огласите весь список, пожалуйста" (с).

Хм. Посмотрел на все используемые мной утилиты. Утилиты на Java есть, используются регулярно, как клиент-банк, Jabber-сервер, сервер-поисковик по ftp. Чистых утилит на .NET у меня почему-то и нет. Конечно Office2007 и Autocad 2007 вроде бы используют .NET фреймворк, но в качестве плагина и написаны явно не на .NET. После поиска по инету в качестве достойной программы на .NET я нашёл только SharpDevelop, этакий простенький аналог NetBeans(Java) но только для программирования на .NET.

Вывод по части надёжности .NET программ был сделан после игры в freeware XNA игры. Скорее всего, он был неточен по причине того что .NET платформа для программистов уровня ПТУ, которые не способны вспомнить что у них делается на предыдущей строчке программы и которым нужен умный компилятор разбирающий такой вот код:
if (a==a) {a=a}

После этого можно даже сделать вывод как должна расшифровываться .NET (New Elementary Technology - .ПТУ), этакая начальная школа программирования для учеников пятых классов. Такое впечатление составили программы на .NET, которые были выложены на SourceForge.

Так что вывод вполне ясен - .ПТУ нужна для программистов начального уровня чтобы их программы хоть как-то работали, хотя бы на демонстрации заказчику. Отсюда и сборщик мусора, чтобы можно было "прогнать все переменные из программы", и VM, так как программист не способен понять, что такое ресурсы системы и зачем они нужны, и Jit компиляция - чтобы можно было свои баги свалить на компилятор.

Так что основной вывод - .NET со своим сборщиком мусора сделана для выпускников ПТУ, чтобы программирование не было сложнее укладки кирпичей на стройке. Но это не особо работает.

← →
StriderMan (2008-12-29 18:15) [113]

> Alkid (29.12.08 13:42) [110]
> Просто смешивать в рамках одной программы обращения и по
> интерфейсным ссылка и по "обычным" объектным ссылкам не
> рекомендуется в силу из сильно разной семантики управления
> временем жизни объекта. В качестве паллиатива можно отключить
> в объекте механизм подсчёта ссылок. Но всё равно останется
> сильный трабл - если у тебя объект был уничтожен ДО того,
> как все интерфейсные ссылки на него обнулены, то при попытке
> что-то присвоить такой "висящей" ссылке nil или ссылку на
> другой объект, ты словишь AV, ибо будет попытка вызова метода
> Release у дохлого объекта.

Я собственно так и выкрутился - в классе сделал пустышки для _AddRef и _Release. Полет нормальный.

> [112] Городской Шаман (29.12.08 17:12)

Paint. Net - зачетная штука.

← →
Городской Шаман (2008-12-29 20:16) [115]

> @!!ex © (29.12.08 20:15) [114]
>
> > [112] Городской Шаман (29.12.08 17:12)
>
> Paint. Net - зачетная штука.

Если сравнивать с GIMP, то Paint.Net - отстой позорный.

> [115] Городской Шаман (29.12.08 20:16)

Если сранвить с Photoshop, то GIMP отстой позорный? :))

А вообще я о качестве выполнения софта. к Паинт НЕту есть претензии по качеству?

← →
Городской Шаман (2008-12-29 20:30) [117]

> @!!ex © (29.12.08 20:20) [116]
>
> > [115] Городской Шаман (29.12.08 20:16)
>
> Если сранвить с Photoshop, то GIMP отстой позорный? :))
>
> А вообще я о качестве выполнения софта. к Паинт НЕту есть
> претензии по качеству?

Есть - поделка уровня курсового в нормальном университете. Есть куча шаровар на нативных языках выше по качеству (в том числе специализированных).

Если SharpDevelop и Paint.Net - это флагманские программы на .NET, то скоро Python догонит это семейство языков программирования. А Perl уже на уровне.

← →
Alkid (2008-12-29 20:35) [118]

> Городской Шаман (29.12.08 17:12) [112]
> Так что основной вывод - .NET со своим сборщиком мусора
> сделана для выпускников ПТУ, чтобы программирование не было
> сложнее укладки кирпичей на стройке. Но это не особо работает.

Т.е. твой основной аргумент в споре - это то, что .NET - это технология для ПТУшников => на ней программы по определению будут глючнее, чем на Java.
В качестве аргумента ты привёл:
1. Аж 1 пример тупого кода.
2. Гениальную расшифровку названия ".NET"
Не то, что бы я был фанатом .NET`а, но твоя аргументация не выдерживает никакой критики :) Пример говнокода можно найти на любом языке и для любого языка можно придумать обидную расшифровку.

Вообще-то я изначально имел в виду какое-нибудь серьёзное исследование. Я понимаю, что ты сам вряди ли проводил подобное (я тоже не проводил), но может дал бы ссылку? Вот я, например, не имею подобных данных и огульных заявлений вида "программы использующие технологию X в целом в большей(меньшей) сепени обладают свойстом Y, чем программы, основанные на технологии Z" просто не делаю.

← →
Городской Шаман (2008-12-29 21:03) [119]

> Alkid (29.12.08 20:35) [118]

Хорошо. Возьмём на частном но аргументированном примере. Разработка игр на .NET. Даже имея такую мощную вещь как managed DirectX, разработка игр для сторонников .NET довольно сложна. Почему эта технология была исключена, ведь в DX нет готовых рисуемых окошек в десигн-тайм кнопочек и прочих. Нужно самому прорабатывать архитектуру игры.

Что же делает Microsoft - выпускает готовый игровой движок на управляемом коде, объявляет его новой прогрессивной технологией гейм-девелопмента, основным качеством которого, цитируя Википедию, "позволит разработчикам игр избежать многих технических трудностей, возникающих при написании кода".

Конечно данный движок позволит без особых усилий бывшему ПТУ-шнику написать очередной трехмерный тетрис, но грамотному разработчику игр, использующему такой движок как Ogre http://www.ogre3d.org/ , это не даст никаких преимуществ, даже свяжет его по рукам угловатостью и неэффективностью игрового движка XNA.

Что мы имеем - .NET привлекательная своей ПТУ-шной направленностью, так как позволяет быстро собрать какую-то поделку из кирпичиков среднего уровня не особо понимая как оно всё работает. А ничего толкового так создать нельзя.

PS
Кому не нравится XNA- игровой движок может заменить на XNA - игровой фреймворк, но смысл от этого не изменится.

← →
Alkid (2008-12-29 21:15) [120]

> Городской Шаман (29.12.08 21:03) [119]

Справедливо ли то, что ты сказал, относительно всех феймворков или же .NET тут чем-то особенно отличился? Я сильно не знаю XNA, но, насколько мне известно, предлагаемые ею шаблоны можно и не использовать, сторя приложение как себе вздумается.

И опять же, это не то, что я хочу увидеть. Как говорил герой одноц книги: "если бы за каждое логически безупречное утверждение, которое на пратктике оказалось полной чушью я получил по доллару, я бы давно стал миллиардером". Так же и тут - рассуждать можно сколько угодно, но это не заменит статистики, ибо практика - критерий истинности.

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