![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
aruslanНенавижу
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
автоматически рождающиеся объекты типа блокирующего loading-on-demand. И синглтоны типа Майерса.
автоматически уничтожающиеся объекты под smart_ptr. И подсчёт ссылок.
автоматически регистрирующиеся получатели сообщений. И unbound рассылку сообщений.
автоматически создающиеся нетривиальные объекты со статическим storage duration. И вообще бурную деятельность до main().
мгновенность, нераспределенность, модель exception, lower-order programming.
Но научить правильно не всегда получается.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: May. 31st, 2006 16:19 (UTC)Глобально - вот пусть те же shared-ресурсы (не в глобальном, а конкретном понимании - материал, текстура, кусок SG). Там нет почти двойной вложенности, там можно буферизировать и стримить, и даже вполне реально контролировать спеки и бюджеты, прямым запуском.
Давай кстати, тоже наоборот. Расскажи свои примеры, где тебе refcount ну совсем уж противен.
no subject
Date: May. 31st, 2006 17:05 (UTC)Давай поговорим про стримить.
(Только я буду говорить сплошные трюизмы, а ты мне скажешь, где я обшибся.)
Есть себе такая текстура.
Раз ref counted - значит разделяется по меньшей мере двумя объектами. Иначе - ебланство.
Объекты явно имеют несхожее время жизни. Иначе - блядство.
Более того, время жизни объектов обязательно пересекается, причём - обязательно только частично (то есть А и Б имеют общий участок Ц, в котором они разделяют текстуру, причём Ц!=А и Ц!=Б). Иначе - либо просто специфическая случайность, либо профанация.
Возможны два варианта: "текстура просто в процессе меняет владельца" (пример - разбиение трассы на сегменты) либо рекурсивное транзитивное замыкание всего хода рассуждений (пример - текстура юзается ахуенно динамичным SG, который живёт по рандому и хуй его знает).
Рассмотрим вопрос эффективного управления ресурсами.
В варианте "текстура меняет владельца" (А -> А/Б==Ц -> Б) мы имеем дело с явно заведомо заранее разбитой на фрагменты хернёй.
Очевидно, что текстура не абстрактно меняет владельца, а вполне конкретно.
Причём заранее продуманы и указаны фазы "скоро потребуется текстура", "текстура нужна", "пусть текстура полежит потому что скоро будет нужна опять", "нахуй текстуру".
Замечу, что третья фаза соответствует (Б -> В где Т не нужна -> Г где нужна опять).
Таким образом мы приходим к выводу, что нам куда важнее не ref count (который, очевидно, НЕ работает в третьей и первой фазе), а знание куда что когда класть.
Получился такой тупой и очевидный стриминг.
И это правильно и эффективно.
И вот скажи - нахуй здесь ref count??
И как проще и правильнее считать спеки и стриминг??
Вариант "текстура нужна SG по рандому" оставлю как домашнее задание на предмет спеков, буферизаций и стримингов.
no subject
Date: May. 31st, 2006 18:31 (UTC)В этом смысле так как иерархия всегда сверху вниз, то можно между этими кусочками таким образом это дело шейрить.
А можно вместо этого сделать "просто" и перегружать все целиком, даже в конце-концов согласившись на копии. Или продумывать нетривиальный граф завязок ресурсов между чанками. Так лучше?
no subject
Date: May. 31st, 2006 18:43 (UTC)Какая связь между ref count для управления временем жизни и dummy который на самом деле - proxy - не вижу.
То, что ты рассказал - совершенно не нуждается в ref count.
Зачем ref count если и так известна структура SG?
Держи ты его себе всегда в памяти.
А если выгружаешь - так без разницы опять же - указатели или имена, по которым ты будешь искать то, что за ref count.
Понимаешь?
Ну и предсказуемо живёт - не вижу как.
Посчитать и сравнить со спеками - тоже не вижу как.
no subject
Date: May. 31st, 2006 18:49 (UTC)Ну надо контролировать цикл жизни shared-кусков. Вовремя их выгружать-загружать и т.д. Как это делать?
Proxy - для буферизации запросов. Пришел новый кусок SG на загрузку, загрузил одним куском уникальные данные. Теперь нужно загружать shared. Составили список тех, которых еще не загружено, поставили вместо них proxy, ждем асинхронной загрузки.
Выгружать надо так, чтобы те, кто эти же данные пользуют, не погибли. Кусков одновременно, конечно, живет много.
Как их менеджить и это контролировать?
Сравнивать со спеками можно прямой "загрузкой" - позиция в мире определяет объем загруженных данных. Я лично вижу только проблему контроля спеков на время загрузки этих частей. Что во-первых из-за фрагментирования винта и так хер проконтролируешь и во-вторых оценки таки есть в препроцессе.
no subject
Date: May. 31st, 2006 20:36 (UTC)Но уж тогда прости - не сферической вакуумности для, но краткости ради.
Одно описываю, второе - ты додумаешь.
Есть мир побитый на чанки типа грид, чанки стримятся.
Одна камера без мгновенных скачков.
Константные требования по количеству чанков в локации.
Каждый чанк требует некоторого количества "ресурсов", которые стримятся.
Ресурсы - потенциально shared, квадратные и все одинакового размера.
Строим таблицу всех ресурсов требуемых любым из чанков.
Вычисляем для каждого чанка список требуемых ему лично ресурсов.
Для каждого чанка есть табличка фиксированного и одинакового для всех чанков размера (пока неизвестного), в которую в определенные (пока неизвестные) позиции будут записаны "номера" ресурсов требуемых этим чанком.
Тупым линейным по гриду алго заполняем эти таблички.
Инвариант - для каждой локации гарантируется, что размера таблички хватит, чтобы уместить все необходимые активным чанкам ресурсы, при этом никакие разные ресурсы в смежных по локации чанках не лежат в одной и той же позиции таблицы.
Ресурсы внутри табличек смежных по локации чанков лежат по одним и тем же местам (это необязательно но типа желательно).
(Это примерно то же самое распределение, которое даст твой ref counting - оно неоптимально, но всегда существует и не требует затрат на поиск.)
(Очевидно, я знаю алго, которое находит субоптимальное решение для неквадратных ресурсов в менее сферическо-вакуумном варианте.)
Резюмирую:
Теперь мы знаем размер таблиц - это то, куда будем класть ресурсы.
Во всех чанках есть табличка, в которой написано что где должно лежать (плюс "UNUSED" для позиций по которым похуй что лежит).
В смежных по локации чанках всегда можно разместить необходимые ресурсы.
В рантайме у нас есть одна табличка, в которую мы пишем, что куда у нас сейчас загружено из ресурсов. Формат таблички - такой же, как и в чанках.
Теперь загрузка нового чанка.
Матчим табличку чанка against нашей рабочей.
Если чанк требует ресурс а у нас там не он - мы обязаны загрузить туда требуемый ресурс. По инварианту это означает, что если у нас в этой позиции таблицы был какой-то ресурс - он нахуй никому не нужен и мы можем его выкинуть.
Выгрузка чанка - ничего не делаем.
Вкратце если интересно - чем это отличается от ref count:
1. Нет проёбов типа "выгрузить - бля! - загрузить обратно", которые неминуемы при ref counting - особенно если порядок загрузки чанков определяется фазой луны и есть дырки типа "ресурс нужен - теперь не нужен - а вот теперь снова нужен".
Очевидным образом, если уж выгрузили - то только для загрузки необходимого ресурса.
2. Нет проёбов типа "ох нихуя себе! и куда теперь грузить?!", неминуемых при ref counting - ты так и не рассказал, дорогой, как же ИМЕННО ты собираешься мне гарантировать, что при любых путях на "гриде" у тебя хватит памяти.
Более строго - реальный IP здесь - это алго распределения, если хочется хотя бы субоптимального решения.
3. Нет проёбов типа "ох нихуя себе! рисуем что успели загрузить!", неминуемых при ref counting - ты так и не рассказал, как же ИМЕННО ты собираешься мне гарантировать, что все ресурсы успеют загрузится при переезде от локации к локации при произвольных путях.
Недостаток тоже очевиден - схема чуть более сложная в реальной жизни.
Но если достаточно неоптимальное решение - ничего сверхестественного в ней нет. Понятно, что таблицы реально выглядят иначе, да и номеров в ней нет, ну и т.п.
Весь механизм - в реальности - классический, но ощутимо более сложный, чем я здесь описал (кстати, я мог что-то проебать при упрощении, не обессудь).
Но алгоритмы и идеи - все из 70-80 годов - оверлеи IBM, раскраска регистров и т.п.
Теперь второе.
Никогда не задумывался, почему ни в оверлеях, ни в страничной виртуальной памяти не используются счётчики ссылок?
Думай.
no subject
Date: Jun. 1st, 2006 07:36 (UTC)Выгрузить-загрузить обратно будет с дискретностью перехода по нескольким кускам. Это большой период времени типично. И значит - пусть лучше он выгрузится, а потом загрузится.
Гарантировать очень просто. Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли. И поэтому его можно успешно проверять при экспорте. Сложно только формализуются требования к скорости стриминга как такового, но и здесь можно вполне строить оценки преходов, и как бы shared-ресурсы таки меньше уникальных.
Рефкаунт для таких shared-ресурсов - просто, тупо и весело. Оно дискретно, оно не имеет циклов, оно решает время жизни shared-объектов для независимых кусков в иерархии сверху-вниз.
no subject
Date: Jun. 1st, 2006 07:47 (UTC)И если есть ресурс, не нужный загружаемому куску - не надо его трогать.
Прочти внимательно, что я написал, тривиальная же схема :(
Только загружаешь, никогда не выгружаешь.
"Требования к памяти для точки-куска не зависят от того, каким путем мы к нему дошли."
Это надо понимать в том же русле, как и гарантии отсутствия фрагментации при malloc?
(no subject)
From:(no subject)
From:(no subject)
From:мой пароль на работе
From: (Anonymous) - Date: Jun. 1st, 2006 18:26 (UTC) - Expand(no subject)
From:(no subject)
From:no subject
Date: Jun. 1st, 2006 05:39 (UTC)/me криво ухмыляется.
а ежели карты, ебись оно конем, рандомные? ;)
no subject
Date: Jun. 1st, 2006 07:19 (UTC)Тогда ты применяешь патентованную технологию INFINITRAX!
no subject
Date: Jun. 1st, 2006 10:25 (UTC)Стратегия, load on demand, 15 расс, из которъх рандомнъе 8 всегда на диске.
Тогда пользуется популярнъй паттерн: "неможеш стримить -> load on demand" :)
Конечно, ето не ref_count нужен, если на PC, ибо факт существования только нужен, в остальном virtual memory спасает, въгрузит все device вместе с heap-ом... :)
no subject
Date: Jun. 1st, 2006 10:35 (UTC)Воистину - дай стеклянный хуй и дальше по списку :))
Я не против load on demand.
Я против ленности и слепоты.
Просто опыт показывает - видишь pull-модель, видишь load-on-demand, видишь иерархическую object system - можно уже начинать спрашивать "почему".
И, к сожалению, в 80% случаев ответ - потому что лень.
"Не потому что, с нею нам светло, а потому - что с ней не нужно света."
no subject
Date: Jun. 1st, 2006 14:46 (UTC)Да, но одно лень, а другое - лень сидеть пол-года ночами, имплементируя на досуге load inplace, стриминг, бандлование даннъх и т.д.
Ибо на работе такое рассценивается как трата времени, на сей момент, совсем так, тривиально.
no subject
Date: Jun. 4th, 2006 20:54 (UTC)no subject
Date: May. 31st, 2006 18:32 (UTC)no subject
Date: May. 31st, 2006 18:37 (UTC)Тот пример, какой я привел - кажется совсем глупым?
no subject
Date: May. 31st, 2006 18:46 (UTC)Но рефкаунтов всё равно не было.
Правда, расскажи за sine qua non!
no subject
Date: May. 31st, 2006 18:51 (UTC)И те - именно один на чанк?
Уважуха. Давай ты еще меня добьешь и скажешь, что пулов не было вообще. И патиклы летали группами по ровно 20.
no subject
Date: May. 31st, 2006 20:07 (UTC)Пулы были. Кэши были.
Размеры партикл систем были известны, конечно, заранее.
Операторов new во время собственно retail игры, насколько я помню, таки не было совсем. Но могу легонько приврать.
Впрочем, assertы вроде ближе к релизу не срабатывали.
no subject
Date: Jun. 1st, 2006 07:37 (UTC)no subject
Date: Jun. 1st, 2006 07:53 (UTC)Даже стеки были. На каждый поток.
Я не говорю, что каждый выделил себе по максимуму на всякий случай (хотя, кстати, в каких-то местах это близко к правде).
Я говорю, что максимум этот определен, и суммарный максимум тоже и от него пляшешь.
Когда я говорю "динамическое выделение", я имею ввиду Васю Пупкина с немытой попой, когда он делает v.push_back() или создает какой-нибудь string или того хуже hashmap.
Ну или там std::vector в функции просто чтобы ему напомнили, если он индексы неправильно посчитает, а boost::array не подходит, потому что требует фиксированного размера.
no subject
Date: Jun. 1st, 2006 05:35 (UTC)А вообще приведенный тобой пример - это идеологический refcount, который как метод решения локальной задачи вполне применим. Я против refcount, который темплейтом оборачивает любой поинтер, даже если это локальная переменная с очевидным временем жизни несколько микросекунд.
no subject
Date: Jun. 1st, 2006 07:27 (UTC)Не в ref count зло, очевидно, но в ленности духа.
no subject
Date: Jun. 1st, 2006 07:51 (UTC)Руслан, Дима, вы серьезно верите, что ленность духа неминуемо следует из refcount и STL? ;)
no subject
Date: Jun. 1st, 2006 08:06 (UTC)Я видел много программистов и еще больше кода.
И - да - любой из пунктов выше плюс STL - это индекс рисков на ленность духа.
Но есть еще программисты, которым не нужен STL и smart ptr, потому что они дебилы и еще и мой пост прочли. И они будут теперь говорить, что smart ptr - это плохо, и поэтому они не будут даже разбираться, что это такое.
Чтобы уметь НЕ пользоваться, нужно сначала таки научиться пользоваться.
И про это хорошо пишет Гай Кавасаки.