[@] GC

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

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

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

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

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

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

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

«zero overhead» буста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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