?

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: 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)
[User Picture]From: aruslan
2006-05-31 08:36 pm (UTC)
Ок, Саймон, буду краток и конкретен.
Но уж тогда прости - не сферической вакуумности для, но краткости ради.

Одно описываю, второе - ты додумаешь.


Есть мир побитый на чанки типа грид, чанки стримятся.
Одна камера без мгновенных скачков.
Константные требования по количеству чанков в локации.
Каждый чанк требует некоторого количества "ресурсов", которые стримятся.
Ресурсы - потенциально shared, квадратные и все одинакового размера.

Строим таблицу всех ресурсов требуемых любым из чанков.
Вычисляем для каждого чанка список требуемых ему лично ресурсов.

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

Тупым линейным по гриду алго заполняем эти таблички.
Инвариант - для каждой локации гарантируется, что размера таблички хватит, чтобы уместить все необходимые активным чанкам ресурсы, при этом никакие разные ресурсы в смежных по локации чанках не лежат в одной и той же позиции таблицы.
Ресурсы внутри табличек смежных по локации чанков лежат по одним и тем же местам (это необязательно но типа желательно).
(Это примерно то же самое распределение, которое даст твой ref counting - оно неоптимально, но всегда существует и не требует затрат на поиск.)
(Очевидно, я знаю алго, которое находит субоптимальное решение для неквадратных ресурсов в менее сферическо-вакуумном варианте.)

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


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

Теперь загрузка нового чанка.
Матчим табличку чанка against нашей рабочей.
Если чанк требует ресурс а у нас там не он - мы обязаны загрузить туда требуемый ресурс. По инварианту это означает, что если у нас в этой позиции таблицы был какой-то ресурс - он нахуй никому не нужен и мы можем его выкинуть.

Выгрузка чанка - ничего не делаем.


Вкратце если интересно - чем это отличается от ref count:

1. Нет проёбов типа "выгрузить - бля! - загрузить обратно", которые неминуемы при ref counting - особенно если порядок загрузки чанков определяется фазой луны и есть дырки типа "ресурс нужен - теперь не нужен - а вот теперь снова нужен".
Очевидным образом, если уж выгрузили - то только для загрузки необходимого ресурса.

2. Нет проёбов типа "ох нихуя себе! и куда теперь грузить?!", неминуемых при ref counting - ты так и не рассказал, дорогой, как же ИМЕННО ты собираешься мне гарантировать, что при любых путях на "гриде" у тебя хватит памяти.
Более строго - реальный IP здесь - это алго распределения, если хочется хотя бы субоптимального решения.

3. Нет проёбов типа "ох нихуя себе! рисуем что успели загрузить!", неминуемых при ref counting - ты так и не рассказал, как же ИМЕННО ты собираешься мне гарантировать, что все ресурсы успеют загрузится при переезде от локации к локации при произвольных путях.


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

Весь механизм - в реальности - классический, но ощутимо более сложный, чем я здесь описал (кстати, я мог что-то проебать при упрощении, не обессудь).
Но алгоритмы и идеи - все из 70-80 годов - оверлеи IBM, раскраска регистров и т.п.


Теперь второе.
Никогда не задумывался, почему ни в оверлеях, ни в страничной виртуальной памяти не используются счётчики ссылок?
Думай.
(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)