Помощники

[aruslan]

Ненавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().

мгновенность, нераспределенность, модель exception, lower-order programming.

Но научить правильно не всегда получается.

Comments

[shodan-ru.livejournal.com]

ref count - расслабляет и заставляет думать только в мАлом.
напрочь исчезает возможность управлять и оптимизировать в большОм.
ну и тупо неэффективно, в конце концов.

но тем не менее, для малого же применимо вполне? в пределах подсистемы, к примеру?

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

[aruslan.livejournal.com]

Дай один-два нетривиальных примера, где, по-твоему, совершенно очевидна полезность ref countов.

Так будет проще объяснить, думаю.

А вообще ты не туда смотришь про неэффективность.
Неэффективность в виде overhead на addref/release и (в говнокоде) на синхронизацию между потоками - она прямолинейна и в простых случаях избегаема. Впрочем, в простых случаях - если она избегаема - её проще избежать ;)

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

Ты не можешь спрогнозировать ни время, ни стоимость, ни лавинообразные расходы на простой release().
Ты не можешь использовать на порядок более простые и безопасные средства типа "грохнуть всё", не можешь позволить себе глобальные оптимизации (со смартами у тебя и на локальные-то силёнок не хватит, впрочем).

Всё это очевидно и конечно не касается простых и тривиальных случаев.

Примеры давай! :)

[aruslan.livejournal.com]

Блядский ЖЖ, это был shared_ptr<B>, сцуко, а не аффторское форматированиё... :(

[sim0nsays.livejournal.com]

Бывают в отладочно-вспомогательных штуках, чтобы меньше требовать усилий, но тебе видимо это интересно.
Глобально - вот пусть те же shared-ресурсы (не в глобальном, а конкретном понимании - материал, текстура, кусок SG). Там нет почти двойной вложенности, там можно буферизировать и стримить, и даже вполне реально контролировать спеки и бюджеты, прямым запуском.

Давай кстати, тоже наоборот. Расскажи свои примеры, где тебе refcount ну совсем уж противен.

[aruslan.livejournal.com]

Мне понравилось про буферизовать и стримить ;)
Давай поговорим про стримить.

(Только я буду говорить сплошные трюизмы, а ты мне скажешь, где я обшибся.)

Есть себе такая текстура.
Раз ref counted - значит разделяется по меньшей мере двумя объектами. Иначе - ебланство.

Объекты явно имеют несхожее время жизни. Иначе - блядство.

Более того, время жизни объектов обязательно пересекается, причём - обязательно только частично (то есть А и Б имеют общий участок Ц, в котором они разделяют текстуру, причём Ц!=А и Ц!=Б). Иначе - либо просто специфическая случайность, либо профанация.

Возможны два варианта: "текстура просто в процессе меняет владельца" (пример - разбиение трассы на сегменты) либо рекурсивное транзитивное замыкание всего хода рассуждений (пример - текстура юзается ахуенно динамичным SG, который живёт по рандому и хуй его знает).

Рассмотрим вопрос эффективного управления ресурсами.

В варианте "текстура меняет владельца" (А -> А/Б==Ц -> Б) мы имеем дело с явно заведомо заранее разбитой на фрагменты хернёй.
Очевидно, что текстура не абстрактно меняет владельца, а вполне конкретно.
Причём заранее продуманы и указаны фазы "скоро потребуется текстура", "текстура нужна", "пусть текстура полежит потому что скоро будет нужна опять", "нахуй текстуру".
Замечу, что третья фаза соответствует (Б -> В где Т не нужна -> Г где нужна опять).

Таким образом мы приходим к выводу, что нам куда важнее не ref count (который, очевидно, НЕ работает в третьей и первой фазе), а знание куда что когда класть.
Получился такой тупой и очевидный стриминг.
И это правильно и эффективно.

И вот скажи - нахуй здесь ref count??
И как проще и правильнее считать спеки и стриминг??

Вариант "текстура нужна SG по рандому" оставлю как домашнее задание на предмет спеков, буферизаций и стримингов.

[sim0nsays.livejournal.com]

Да очень просто. Есть кусочки, в которых есть shared и не очень ресурсы. Кусочек загружаеццо - надо выгрузить все, что сейчас не нужно. Рядом всегда есть другие кусочки, которые часть shared-ресурсов имеют. Выгружать их туда-сюда - западло. Вполне живет для этого дела refcount. И предсказуемо живет, отмечу. И формируется буфер запросов объектов на стриминг (вместо которых временно dummy в SG.

В этом смысле так как иерархия всегда сверху вниз, то можно между этими кусочками таким образом это дело шейрить.

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

[aruslan.livejournal.com]

Саймон, ты меня убил и практически съел.

Какая связь между ref count для управления временем жизни и dummy который на самом деле - proxy - не вижу.
То, что ты рассказал - совершенно не нуждается в ref count.

Зачем ref count если и так известна структура SG?
Держи ты его себе всегда в памяти.
А если выгружаешь - так без разницы опять же - указатели или имена, по которым ты будешь искать то, что за ref count.

Понимаешь?

Ну и предсказуемо живёт - не вижу как.
Посчитать и сравнить со спеками - тоже не вижу как.

[sim0nsays.livejournal.com]

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

Ну надо контролировать цикл жизни shared-кусков. Вовремя их выгружать-загружать и т.д. Как это делать?

Proxy - для буферизации запросов. Пришел новый кусок SG на загрузку, загрузил одним куском уникальные данные. Теперь нужно загружать shared. Составили список тех, которых еще не загружено, поставили вместо них proxy, ждем асинхронной загрузки.

Выгружать надо так, чтобы те, кто эти же данные пользуют, не погибли. Кусков одновременно, конечно, живет много.
Как их менеджить и это контролировать?

Сравнивать со спеками можно прямой "загрузкой" - позиция в мире определяет объем загруженных данных. Я лично вижу только проблему контроля спеков на время загрузки этих частей. Что во-первых из-за фрагментирования винта и так хер проконтролируешь и во-вторых оценки таки есть в препроцессе.

[shodan-ru.livejournal.com]

Вариант "текстура нужна SG по рандому" оставлю как домашнее задание на предмет спеков, буферизаций и стримингов.

/me криво ухмыляется.

а ежели карты, ебись оно конем, рандомные? ;)

[aruslan.livejournal.com]

/me криво ухмыльнулся

Тогда ты применяешь патентованную технологию INFINITRAX!

[ddima.livejournal.com]

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

[sim0nsays.livejournal.com]

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

Тот пример, какой я привел - кажется совсем глупым?

[aruslan.livejournal.com]

Саймон, у меня были динамические аллокации - загрузка.
Но рефкаунтов всё равно не было.

Правда, расскажи за sine qua non!

[ddima.livejournal.com]

Пример вполне жизненный, если бы не одно "но". Shared кусочки с непонятным временем жизни занимают непонятный объем памяти. А я со своей хронической нелюбовью к аллокациям непонятного размера хочу точно знать, когда и что мне надо загружать. Поэтому заменяю refcount на понятие "объекты этой группы ссылаются на общий блок". И веду проверку на препроцессоре, что не дай бог, возникнет ситуация с одновременно двумя блоками.

А вообще приведенный тобой пример - это идеологический refcount, который как метод решения локальной задачи вполне применим. Я против refcount, который темплейтом оборачивает любой поинтер, даже если это локальная переменная с очевидным временем жизни несколько микросекунд.

[shodan-ru.livejournal.com]

Дай один-два нетривиальных примера, где, по-твоему, совершенно очевидна полезность ref countов.

речь не о том что refcounted мега-полезен и единственно правилен, а остальное ересь. понятно, что даже если тебя съели, то все равно есть варианты.

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

[aruslan.livejournal.com]

верю, Шоданчег.
просто когда я вижу SG у которого все ноды - в смартпойнтерах, мне отчего-то хочется подарить человеку GC.
пусть даже и импульсный.

[shodan-ru.livejournal.com]

просто когда я вижу SG у которого все ноды - в смартпойнтерах, мне отчего-то хочется подарить человеку GC.

тут еще не раскрыта тема гранулярности.

а так, беда известная. у нас игровые объекты refcounted, будь оно неладно. :(

[ironpeter.livejournal.com]

Подари мне GC!

[aruslan.livejournal.com]

Так в ДМ (тм) вроде есть :)
Счастлив? ;)

[(Anonymous)]

Из рук глупца не принимай лекарства! (с)

[http://users.livejournal.com/_winnie/]

О, вот ещё придумал.
Предположим, имеется игровой объект, маг.
На описание списка его заклинаний и умений (который занимает аж килобайт) держится куча ссылок у других игровых объектов. Который им нужен даже после умирания мага.

PS. Иногда хочу GC. Не тот который дефрагментация, а тот который может убить Тёмного Графа Мертвых.

дай ссылку на форум, где разговаривали про обмен целых при помощи xor и разбирался код разных компиляторов. Там в названии что-то вроде pascal было.

[aruslan.livejournal.com]

если его заклинания и умения держаться и после умирания - то он такой же пользователь заклинаний, как и остальные объекты - ему лично они не принадлежат.
а значит, есть lifetime scope более высокого уровня.

про xor - ты имеешь ввиду мои ответы под ником darkgraf вот тут?
а при чём тут xor? %)

[http://users.livejournal.com/_winnie/]

Про мага - я хотел сказать, что тут нужно что-то точно не менее мощное, чем рефкаунт, а лучше даже что-то помощней.

>а при чём тут xor? %)
Нипричём.
я написал про graphf объектов. и неожиданно вспомнил, что потерял ссылку на хорошее обсуждение :)

[aruslan.livejournal.com]

Я не сказал, что ref count не нужен.
Я про то, что если человек знает только strong ref count - это плохо.
Когда strong ref count и weak ref count - это лучше.
Когда он понимает, что это на самом деле GC - еще лучше.
Когда он знает, какие бывают GC и почему sbrk() - это GC - совсем лучше.

А потом он начинает практиковать кунфу.

[http://users.livejournal.com/_winnie/]

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

1) уничтожение объектов, на которые нет ссылок, даже при циклических зависимостях.
2) дефрагментация памяти, перенос объектов.
3) черти-когда-неизвестный-вызов-Finalize-и-останов-всех-потоков-для-сборки.
4) что-то ещё, не помню что :(

Что ты имел в виду под "почему sbrk() - это GC"? А "какие бывают GC" ?

PS. фото катёнка_GJ видел? =)