OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:59

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Понедельник, 09 Август, 2010 18:04 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Не знаю, в какую ветку, поместил в эту - поскольку один из тезисов, в частности, И21 - о том, что основные преимущества ФП связаны с автоматическим управлением памятью, и в Обероне это открывает соответствующие возможности...

http://russian.joelonsoftware.com/Artic ... aronA.html
Цитата:
В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.

Врезка
Почему автоматическое управление памятью значительно улучшает вашу продуктивность? 1) Потому что вы можете написать f(g(x)) не беспокоясь о том, как освободить память, занятую возвращаемым значением функции g, значит вы можете использовать функции, которые возвращают интересные сложные типы данных и функции, трансформирующие интересные сложные типы данных, что в результате позволяет вам работать на более высоком уровне абстракции. 2) Потому что вам не надо тратить время на код, освобождающий память или отслеживать утечки памяти. 3) Потому что вам не надо аккуратно координировать точки выхода из ваших функций, чтобы убедиться, что память освобождена должным образом.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Среда, 11 Август, 2010 13:25 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Языки со сборкой мусора дают не то что описал Спольски, а совсем другое -- невозможность запороть память (герметичность типов).
1) От утечки памяти это не спасает.
2) От необходимости следить за тем когда какой объект уже можно "удалить" (т. е. использовать повторно для других целей) не избавляет тоже.
3) Сложные структуры можно передавать и без сборщика мусора.

Короче, нет порчи памяти - и на этом уже большое спасибо, остальное всё по старинке в рукопашную.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Среда, 11 Август, 2010 16:30 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Языки со сборкой мусора дают не то что описал Спольски, а совсем другое -- невозможность запороть память (герметичность типов).
1) От утечки памяти это не спасает.
2) От необходимости следить за тем когда какой объект уже можно "удалить" (т. е. использовать повторно для других целей) не избавляет тоже.
3) Сложные структуры можно передавать и без сборщика мусора.

Короче, нет порчи памяти - и на этом уже большое спасибо, остальное всё по старинке в рукопашную.

Ниче не понял...
Поставлю закладочку -- жара спадет, попробую перечитать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Среда, 11 Август, 2010 16:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Губанов писал(а):
Языки со сборкой мусора дают не то что описал Спольски, а совсем другое -- невозможность запороть память (герметичность типов).
....
Короче, нет порчи памяти - и на этом уже большое спасибо, остальное всё по старинке в рукопашную.


Ну почему. Для прикладников, пишущих настольные приложения, дают, в общем-то, всё.
Ну а про остальное, конечно, нам понятно :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Среда, 11 Август, 2010 22:47 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Info21 писал(а):
Ниче не понял... Поставлю закладочку -- жара спадет, попробую перечитать...
Разжую:

1) Память течёт потому что указатели забывают обнулить или какой-нибудь контейнер почистить.

2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.

3) GC нужен чтобы невалидных указателей не было. Запись по невалидному указателю портит память.

Баг типа (1) отлавливается memory profiler-ом.
Баг типа (2) может сильно влиять на производительность.
Ни (1) ни (2) не смертельны.
А вот баг типа (3) -- порча памяти -- смертельна и практически не поддаётся лечению.

GC полностью избавляет только от смертельного бага (3) (что очень-переочень хорошо), но ни от чего другого он полностью не избавляет.

Илья Ермаков писал(а):
Для прикладников, пишущих настольные приложения
Ну вот разьве что для них только, местами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Среда, 11 Август, 2010 22:58 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Сергей Губанов писал(а):
2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.
Добавлю, что некоторые системные ресурсы, оборачиваемые в объекты, могут исчерпываться гораздо раньше, чем про них вспомнит GC. Такие объекты надо уничтожать вручную, а не накапливать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 07:24 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Info21 писал(а):
Ниче не понял... Поставлю закладочку -- жара спадет, попробую перечитать...
Разжую:
Да, спасибо. Голова занята другим, лекций давно не читал :)

Сергей Губанов писал(а):
Илья Ермаков писал(а):
Для прикладников, пишущих настольные приложения
Ну вот разве что для них только, местами.
Четто Илья Евгеньевич пренебрежительно стал отзываться об настольных приложениях :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 10:01 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Александр Ильин писал(а):
Добавлю, что некоторые системные ресурсы, оборачиваемые в объекты, могут исчерпываться гораздо раньше, чем про них вспомнит GC. Такие объекты надо уничтожать вручную, а не накапливать.

Относитесь к этому так, как относятся в ФП -- сборщик мусора только для управления одним ресурсом -- памятью, а все прочие ресурсы (файлы, порты ввода/вывода и пр.) обрабатывайте вручную, оборачивая, если нужно, в финализаторы (типа using в c# или with-... в лиспе).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 12:10 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Где-то читал, точно не помню где (возможно, что я что-то не так понял), что вроде бы в операционной системе Оберон, работа с файлами организована примерно также как и с памятью, то есть если понадобился файла, то открываешь его, беспокоиться о том, когда его закрыть не надо, а сборщик мусора сам определит что файл не нужен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 12:25 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Rifat писал(а):
Где-то читал, точно не помню где (возможно, что я что-то не так понял), что вроде бы в операционной системе Оберон, работа с файлами организована примерно также как и с памятью, то есть если понадобился файла, то открываешь его, беспокоиться о том, когда его закрыть не надо, а сборщик мусора сам определит что файл не нужен.
Что совершенно логично, поскольку файлы -- это тоже память. А то, что она внешняя, проявляется в дисциплине доступа.

При этом сохраняется возможность что-то сделать (Close, Flush ...) явно, рукой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 16:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Info21 писал(а):
Четто Илья Евгеньевич пренебрежительно стал отзываться об настольных приложениях :)


Да нет; у меня у самого настольные темы есть, куда без них ))

Просто народ очень любит комфорт - если им сборщик даден, он считают, что можно вообще никогда не вспоминать о том, что такое управление памятью. А ждать очередной версии Java VM, в которой супер-оптимизирующий компилятор уже умеет понимать, что вот этот их мусор можно побыстрее и поэффективнее отдельно обработать.
Сколько одними строками какими-нибудь намусорить можно при каждой операции, если бездумно полагаться на динамику..

Цитата:
2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.


Ага. Вообще, интересный пример спирали развития техники. Сначала запрещаем удалять вручную объекты, получаем качественный прорыв. Потом, когда давят требования производительности (реальные требования, т.к. с бездумным применением GC можно попасть не на слагаемое или множитель, а на степень - что и является признаком "реальности" проблемы) идёт "отрицание отрицания" - организуем вновь ручное управление, но уже уровнем выше, без посягательств на целостность памяти.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 17:50 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Сергей Губанов писал(а):
Языки со сборкой мусора дают не то что описал Спольски, а совсем другое -- невозможность запороть память (герметичность типов).
....
Короче, нет порчи памяти - и на этом уже большое спасибо, остальное всё по старинке в рукопашную.

Ну почему. Для прикладников, пишущих настольные приложения, дают, в общем-то, всё.
Ну а про остальное, конечно, нам понятно :)

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

Так вот, я лично нифига не вижу разницы между настольным и не очень приложением в контексте рассматриваемой проблемы. Везде важна производительность. Везде проблемы с утечками (о! для настольных приложений утечки случаются значительно чаще! да, именно со сборщиком мусора, ибо gui).

И, в плане производительности, настольные приложения не имеют такой лазейки как серверные -- масштабируемости. Если мы серверное решение спроектировали масштабируемо, то вместо того, чтобы допиливать производительность часто дешевле просто купить ещё один сервер. Однако для десктопного приложения так не выйдет, не скажешь же клиенту, мол для видеозвонка одного ноута вам не хватит, таскайте с собой два!

И да, приходится оптимизировать. В т.ч. не только повторное использование выделенных объектов (ака пулы), но, иногда, и совсем ручная, низкоуровневая работа с памятью. Да, в языке с GC.

Кстати, серверные приложения очень часто не зависят от всяких хитрых устройств. Т.е. они просто используют стандартный скажем tcp/ip стэк и всё. В десктопном так не выйдет. Тут нужен доступ к хитрым устройствам вроде видеокамеры, или звуковухи, к видеокарте. С отображением памяти и прочими прелестями. А тут и до порчи памяти недалеко. И ложится вся VM прекрасно. segmentation fault. core dumped и всё. Допрыгались.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 17:54 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Сергей Губанов писал(а):
2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.

Кстати, это не универсальный рецепт. Это вы пользуетесь особенностями реализации данного конкретного GC. Ибо некоторые типы сборщиков мусора таки работают быстрее тогда, когда больше мусоришь.

Т.е. теоретически возможна ситуация, когда в VM сменится тип сборщика мусора и вы вместо увеличения производительности, посредством этого трюка, получите её снижение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 18:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Если сборка мусора работает "сбоку" (т.е. VM считает, что "мусор порождается по определению - и его надо регулярно собирать"), то можно наверняка и на это налететь.

Если как в Обероне - сборка при очередном NEW, если требуется память, то можно так спрофилировать работу с памятью, что до сборки мусора вообще дело доходить не будет или будет крайне редко (программа не выходит за порог занятой памяти. Сколько "наела", столько и держит, явно переиспользуя объекты и очень редко что-нибудь совсем выбрасывая...). Нет сборки - нет пауз, и т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 18:23 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Если сборка мусора работает "сбоку" (т.е. VM считает, что "мусор порождается по определению - и его надо регулярно собирать"), то можно наверняка и на это налететь.

Если как в Обероне - сборка при очередном NEW, если требуется память, то можно так спрофилировать работу с памятью, что до сборки мусора вообще дело доходить не будет или будет крайне редко (программа не выходит за порог занятой памяти. Сколько "наела", столько и держит, явно переиспользуя объекты и очень редко что-нибудь совсем выбрасывая...). Нет сборки - нет пауз, и т.п.

Как в какой из реализаций оберона? Вообще, это опять же сильно от реализации GC зависит. Т.е. даже если GC сбоку висит (да вообще работает параллельно. в отдельном потоке и работает асинхронно), то ему ровно также ничего не мешает начинать шерстить кучу тогда и только тогда, когда достигнут очередной предел по памяти.

Просто я к тому, что имея в системе такой вот black box, как сборщик мусора, полагаться на некие особенности его реализации может быть черевато.

PS. А пауз у современных GC вроде как и так нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 18:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
В каких-то случаях, на сборке старших поколений, всё равно они потоки морозят. Вроде бы.
Есть алгоритмы для систем реального времени (ещё Дейкстра придумал что-то), но они проигрывают в общих параметрах.
Вообще, там быстро у них всё меняется, года два назад изучал сан-овские статьи, а сейчас уже, говорят, оно там на стеке размещать умеет, когда понимает, что можно... Короче, рабочая сила и деньги есть - и не таких оптимизаций наворотят :) Доверять буим, или лучше сами? :))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 18:35 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
В каких-то случаях, на сборке старших поколений, всё равно они потоки морозят. Вроде бы.
Есть алгоритмы для систем реального времени (ещё Дейкстра придумал что-то), но они проигрывают в общих параметрах.
Вообще, там быстро у них всё меняется, года два назад изучал сан-овские статьи, а сейчас уже, говорят, оно там на стеке размещать умеет, когда понимает, что можно...

Дык этта.. Escape analysis же вроде как известен давно, вот теперь вкрутили... Да и сана то больше уже нет :-)

Илья Ермаков писал(а):
Короче, рабочая сила и деньги есть - и не таких оптимизаций наворотят :) Доверять буим, или лучше сами? :))

Если лучше сами, то нужно начинать с процессоров. В частности -- от современных x86 бежать надо как от чумы. Ибо там на уровне процессора, уже таких оптимизаций наворотили...

Ну а потом нужно 1) либо разработать самому язык, либо верифицировать спеки на существующий. 2) написать компилятор. 3) написать ОС. 4) захватить мир.

PS. Кстати, себе я не слишком то доверяю ;-) В плане подобных вещей -- явно не больше чем sun'у например.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 19:24 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Илья Ермаков писал(а):
Если как в Обероне - сборка при очередном NEW, если требуется память, то можно так спрофилировать работу с памятью, что до сборки мусора вообще дело доходить не будет или будет крайне редко (программа не выходит за порог занятой памяти. Сколько "наела", столько и держит, явно переиспользуя объекты и очень редко что-нибудь совсем выбрасывая...). Нет сборки - нет пауз, и т.п.
Вот я так и стараюсь делать. Наша программа у клиентов же на Линуксе работает под Моно. А Моновский сборщик мусора примерно такой же как и в Блэкбоксе: без поколений, не перемещающий, иногда консервативный; правда память обратно в систему его всё таки научили отдавать.
Илья Ермаков писал(а):
всё равно они потоки морозят. Вроде бы.
Моно морозит. Потому и борюсь с мусором вручную (даже ценой копирования, т.е. иногда вручную симулирую value-типовость на reference-типовых объектах). А то ужас был года три назад, старая версия программы при не очень высокой нагрузке работала 27 секунд, а потом полностью останавливалась и 3 секунды собирала мусор, затем опять работала 27 секунд и т.д.. Тратить 10% времени на сбор мусора может быть и приемлемо, но только если эти 10% будут равномерно распределены по времени.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 19:42 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Кстати, при больших нагрузках если нагрузку увеличить ещё на немножко, то время сборки мусора увеличится вовсе не на немножко, а сильно. Есть некий порог нагрузки при достижении которого программа захлёбывается мусором.

Функция зависимости времени сборки мусора от поданной на программу нагрузки:

t = ВремяСборкиМусора(нагрузка);

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

ВремяСборкиМусора(критическая_нагрузка) = бесконечность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Джоэл Спольски о сборке мусора
СообщениеДобавлено: Четверг, 12 Август, 2010 20:29 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
от современных x86 бежать надо как от чумы.
Ваши бы слова да Ситрониксу в уши.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB