[@] GC

В общем, надоели вы мне.

dave (26.03.2011 7:01:59)

shared_ptr тормознее GC из SBCL в 3-4 раза:

http://love5an.livejournal.com/365174.html

> shared_ptr тормознее GC из SBCL

Сравнение нелепо по своей сути.

archimag (26.03.2011 22:19:14)

Очень даже хорошее сравнение, показывающее весь дутый "zero overhead" буста.

> Очень даже хорошее сравнение, показывающее весь дутый
> "zero overhead" буста.

Скорей полное не понимание предмета.

archimag (26.03.2011 22:51:05)

а можно подробней?

jtootf (26.03.2011 22:58:55)

> а можно подробней?

Ну а что тут подробней рассказывать. То, что подсчёт ссылок является не лучшей стратегией для GC как бы не новость. Но только shared_ptr это ни в коей мере не замена сборщика мусора. Вот если бы каждый объект в программах на С++ заворачивался в shared_ptr, но только в этом нет никакого смысла. Основная часть ресурсов освобождается во время раскрутки стэка, либо в деструкторах "больших" объектов. Написать реальную программу, в которой использование share_ptr имело бы сколько-нибудь заметный эффект на производительность это ведь надо ещё постараться. Но даже если такой эффект вдруг по кривости рук и образовался, то профайлер его покажет и можно будет переписать код без shared_ptr, а вот отказаться от GC несколько проблематично.

Кстати, хвалённый GC в SBCL почему-то валится под нагрузкой и никакой (sb-ext:gc :full t) не помогает. Я сейчас подумываю о переходе на Clozure CL.

archimag (26.03.2011 23:15:10)

Но, вообще, описанные в статье тормоза вообще с shared_ptr никак не связаны то. Что бы поймать тормозать именно от shared_ptr нужно намного более сложный код писать.

archimag (26.03.2011 23:32:59)

ага, не связаны.

на intrusive_ptr переписали - стало быстрее в три раза.

Никак не связаны!

и, кстати, что самое смешное - все-равно тормознее SBCL почти в два раза

> shared_ptr тормознее GC из SBCL в 3-4 раза:
> на intrusive_ptr переписали - стало быстрее в три раза.
> все-равно тормознее SBCL почти в два раза

занимательная у вас арифметика

>Почему бы не сделать промежуточный вариант, когда по умолчанию память чистит GC, но программист может вызвать освобождение памяти конкретного объекта явно?

Я сейчас for fun участвую в проекте на таком языке. Там del(foo) убивает объект и зануляет все ссылки на него. В сочетании с кооперативной многопоточностью это даёт большое количество ошибок доступа к полям несуществующих объектов, буквально как блох на собаке, сколько не вычёсывай. Хорошо, что интерпретатор это глотает, а юзеры не замечают. Но лучше бы что-то одно было - либо GC либо del(), тогда-бы, может, аккуратность у программистов стимулировалась.

legolegs (27.03.2011 1:00:18)

Я тут посмотрел, языки с гибридным управлением памятью таки есть. К примеру также модула-3 (Вот уж не ожидал от Вирта) имеет две кучи. Одна с GC, другая без. так что не все так безнадежно.

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

ИМХО, GC хорош в тех случаях, где нет однозначной определенности, когда объект должен быть создан, и когда он должен быть удален. Для остальных случаев он ненужен.

AF (28.03.2011 10:48:38)