?

Log in

No account? Create an account
Помощники - Valse oubliée [entries|archive|friends|userinfo]
aruslan

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]
[ delicious | aruslan's delicious ]

Links
[Links:| Tags Profile Friends FG1 PP gamedev XNA FF Entries Comments Memories ]

Помощники [May. 30th, 2006|03:06 pm]
aruslan
[Tags|, , , , ]

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

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

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

Comments:
[User Picture]From: aruslan
2006-05-31 04:01 pm (UTC)
Дай один-два нетривиальных примера, где, по-твоему, совершенно очевидна полезность ref countов.

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

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

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

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

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

Примеры давай! :)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 04:02 pm (UTC)
Блядский ЖЖ, это был shared_ptr<B>, сцуко, а не аффторское форматированиё... :(
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 04:19 pm (UTC)
Бывают в отладочно-вспомогательных штуках, чтобы меньше требовать усилий, но тебе видимо это интересно.
Глобально - вот пусть те же shared-ресурсы (не в глобальном, а конкретном понимании - материал, текстура, кусок SG). Там нет почти двойной вложенности, там можно буферизировать и стримить, и даже вполне реально контролировать спеки и бюджеты, прямым запуском.

Давай кстати, тоже наоборот. Расскажи свои примеры, где тебе refcount ну совсем уж противен.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 05:05 pm (UTC)
Мне понравилось про буферизовать и стримить ;)
Давай поговорим про стримить.

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

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

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

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

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

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

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

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

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

Вариант "текстура нужна SG по рандому" оставлю как домашнее задание на предмет спеков, буферизаций и стримингов.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: sim0nsays
2006-05-31 06:31 pm (UTC)
Да очень просто. Есть кусочки, в которых есть shared и не очень ресурсы. Кусочек загружаеццо - надо выгрузить все, что сейчас не нужно. Рядом всегда есть другие кусочки, которые часть shared-ресурсов имеют. Выгружать их туда-сюда - западло. Вполне живет для этого дела refcount. И предсказуемо живет, отмечу. И формируется буфер запросов объектов на стриминг (вместо которых временно dummy в SG.

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

А можно вместо этого сделать "просто" и перегружать все целиком, даже в конце-концов согласившись на копии. Или продумывать нетривиальный граф завязок ресурсов между чанками. Так лучше?
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: ddima
2006-05-31 06:32 pm (UTC)
Саймон, ты лучше расскажи, где тебе refcount уж совсем нужен. Просто я (за своей умственной ограниченностью) все годы ухитрялся обойтись без него, поэтому мои примеры непоказательны :)
(Reply) (Parent) (Thread) (Expand)
From: shodan_ru
2006-06-01 05:37 am (UTC)
Дай один-два нетривиальных примера, где, по-твоему, совершенно очевидна полезность ref countов.

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

пойнт в том что оно вполне может работать и вполне нормально. впрочем, случай у меня как раз простой и тривиальный, увы. рендерятор наш..
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-01 07:28 am (UTC)
верю, Шоданчег.
просто когда я вижу SG у которого все ноды - в смартпойнтерах, мне отчего-то хочется подарить человеку GC.
пусть даже и импульсный.
(Reply) (Parent) (Thread)
From: shodan_ru
2006-06-01 07:50 am (UTC)
просто когда я вижу SG у которого все ноды - в смартпойнтерах, мне отчего-то хочется подарить человеку GC.

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

а так, беда известная. у нас игровые объекты refcounted, будь оно неладно. :(
(Reply) (Parent) (Thread)
From: ironpeter
2006-06-01 08:16 am (UTC)
Подари мне GC!
(Reply) (Parent) (Thread) (Expand)
(no subject) - (Anonymous) Expand
[User Picture]From: _winnie
2006-06-04 08:13 pm (UTC)




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

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

дай ссылку на форум, где разговаривали про обмен целых при помощи xor и разбирался код разных компиляторов. Там в названии что-то вроде pascal было.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-04 08:38 pm (UTC)
если его заклинания и умения держаться и после умирания - то он такой же пользователь заклинаний, как и остальные объекты - ему лично они не принадлежат.
а значит, есть lifetime scope более высокого уровня.

про xor - ты имеешь ввиду мои ответы под ником darkgraf вот тут?
а при чём тут xor? %)
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2006-06-04 10:02 pm (UTC)
Про мага - я хотел сказать, что тут нужно что-то точно не менее мощное, чем рефкаунт, а лучше даже что-то помощней.

>а при чём тут xor? %)
Нипричём.
я написал про graphf объектов. и неожиданно вспомнил, что потерял ссылку на хорошее обсуждение :)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-04 08:52 pm (UTC)
Я не сказал, что ref count не нужен.
Я про то, что если человек знает только strong ref count - это плохо.
Когда strong ref count и weak ref count - это лучше.
Когда он понимает, что это на самом деле GC - еще лучше.
Когда он знает, какие бывают GC и почему sbrk() - это GC - совсем лучше.

А потом он начинает практиковать кунфу.
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2006-06-04 10:09 pm (UTC)
имхо, часто в GC смешивают как и в синглетонах сразу несколько понятий, а иногда наоборот имеют в виду только что-то одно.

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

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

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