?

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

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

А можно вместо этого сделать "просто" и перегружать все целиком, даже в конце-концов согласившись на копии. Или продумывать нетривиальный граф завязок ресурсов между чанками. Так лучше?
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 06:43 pm (UTC)
Саймон, ты меня убил и практически съел.

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

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

Понимаешь?

Ну и предсказуемо живёт - не вижу как.
Посчитать и сравнить со спеками - тоже не вижу как.
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 06:49 pm (UTC)
Убил и съел - значит, не выполнил философских ожиданий? Я по-другому не умею разговаривать, мне непонятно без объяснений на пальцах.

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

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

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

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

(Reply) (Parent) (Thread) (Expand)
From: shodan_ru
2006-06-01 05:39 am (UTC)
Вариант "текстура нужна SG по рандому" оставлю как домашнее задание на предмет спеков, буферизаций и стримингов.

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

а ежели карты, ебись оно конем, рандомные? ;)
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-01 07:19 am (UTC)
/me криво ухмыльнулся

Тогда ты применяешь патентованную технологию INFINITRAX!
(Reply) (Parent) (Thread)
From: zemedelec
2006-06-01 10:25 am (UTC)
Да, Руслан.
Стратегия, load on demand, 15 расс, из которъх рандомнъе 8 всегда на диске.
Тогда пользуется популярнъй паттерн: "неможеш стримить -> load on demand" :)
Конечно, ето не ref_count нужен, если на PC, ибо факт существования только нужен, в остальном virtual memory спасает, въгрузит все device вместе с heap-ом... :)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: ddima
2006-05-31 06:32 pm (UTC)
Саймон, ты лучше расскажи, где тебе refcount уж совсем нужен. Просто я (за своей умственной ограниченностью) все годы ухитрялся обойтись без него, поэтому мои примеры непоказательны :)
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 06:37 pm (UTC)
Дима, я боюсь с тобой говорить на эту тему. Если уж не видно смысла в динамических аллокациях во время работы игры вообще - то про рефкаунт даже говорить не удобно.

Тот пример, какой я привел - кажется совсем глупым?
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-05-31 06:46 pm (UTC)
Саймон, у меня были динамические аллокации - загрузка.
Но рефкаунтов всё равно не было.

Правда, расскажи за sine qua non!
(Reply) (Parent) (Thread)
[User Picture]From: sim0nsays
2006-05-31 06:51 pm (UTC)
И никаких кроме загрузки не было?
И те - именно один на чанк?
Уважуха. Давай ты еще меня добьешь и скажешь, что пулов не было вообще. И патиклы летали группами по ровно 20.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: ddima
2006-06-01 05:35 am (UTC)
Пример вполне жизненный, если бы не одно "но". Shared кусочки с непонятным временем жизни занимают непонятный объем памяти. А я со своей хронической нелюбовью к аллокациям непонятного размера хочу точно знать, когда и что мне надо загружать. Поэтому заменяю refcount на понятие "объекты этой группы ссылаются на общий блок". И веду проверку на препроцессоре, что не дай бог, возникнет ситуация с одновременно двумя блоками.

А вообще приведенный тобой пример - это идеологический refcount, который как метод решения локальной задачи вполне применим. Я против refcount, который темплейтом оборачивает любой поинтер, даже если это локальная переменная с очевидным временем жизни несколько микросекунд.
(Reply) (Parent) (Thread)
[User Picture]From: aruslan
2006-06-01 07:27 am (UTC)
Вот кстати ты правильно сказал.
Не в ref count зло, очевидно, но в ленности духа.

sim0nsays, понимаешь?
(Reply) (Parent) (Thread) (Expand)