Здравствуйте, WolfHound, Вы писали:
VD>>>Можно сслочку на то, где ты видел подобные решения в реальной жизни? Сколько таких случаев было? V>>Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом. WH>8 тысяч коротко живущих объектов в секунду... да ГЦ это даже не заметит. Это для него вобще не цифра. WH>Причем если для обычной кучи объекты разного размера приводят к фрагментации и серьезному замедлению работы то мусорщику на это начхать. WH>Болие того алгоритм мусорщика таков что при сборке мусора время тратится ТОЛЬКО на живые объекты. А в твоем случае подавляющие большинство объектов будут мусором. WH>Те это вобще идеальные условия для мусорщика.
Проблема в том, что это была не целая программа, а библиотека, от которой требовалось минимальная загрузка процессора. А работа с памятью была узким местом. Далее, в моем случае библиотека использовала фиксированные небольшой буфер памяти, и не "отжирала" память у основной программы — сервера (а она ему ой как была нужна, мморпг все-таки!!!). Плюс была применена очень эффективная оптимизация этого менеджера, когда при освобождении всех объектов, то есть когда указатель на хвост догонял указатель на голову, оба этих указателей сбрасывались в начало буфера. Благодаря этому бОльшая часть буфера все время находилась в файле подкачки и извлекалась оттуда только в случае "затора" сообщений.
По поводу большенства мертвых объектов. Доставала объекты оснавная программа (сервер), а не сетевая библиотека. И когда сервер соизволит достать очередное сообщение — это только серверу известно, и сколько поколений переживут сообщения в буффере тоже не понятно. Далее, подумай про объемы: 8к сообщений в секунду, каждое из которых в среднем по 4 килобайта. Получаем 32 мегабайта в секунду. Некислая я скажу нагрузка на ГЦ будет — дефрагментация получится очень "вкусной" операцией
Здравствуйте, WolfHound, Вы писали:
WH>Вот только про разработчиков игр не надо. Я с ними очень не мало общался. В подавляющем большинстве случаев это просто жутчайшие консерваторы готовые удавится за пол процента производительности.
но при этом рынок переполнен играми, которые глючат, тормозят на ровном месте и жрут память вагонами.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, WolfHound, Вы писали:
WH>>Вот только про разработчиков игр не надо. Я с ними очень не мало общался. В подавляющем большинстве случаев это просто жутчайшие консерваторы готовые удавится за пол процента производительности.
Д>но при этом рынок переполнен играми, которые глючат, тормозят на ровном месте и жрут память вагонами.
Здравствуйте, eao197, Вы писали:
E>Как я понимаю, речь шла не о 8K объектов в секунду, а об обработке 8K сообщений в секунду. Еще не известно, сколько и чего создавалось во время обработки одного сообщения.
Да какая разница? Это всеравно будут коротко живущие объекты. E>А обработка 8K сообщений в секунду в сетевом приложении это не кисло.
И как сеть связана с мусорщиком? Вобще говоря сеть по сравнению с мусорщиком тормоз просто жутчайший.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, prVovik, Вы писали:
V>Проблема в том, что это была не целая программа, а библиотека, от которой требовалось минимальная загрузка процессора. А работа с памятью была узким местом.
И что? Скорость работы с памятью V>Далее, в моем случае библиотека использовала фиксированные небольшой буфер памяти, и не "отжирала" память у основной программы — сервера (а она ему ой как была нужна, мморпг все-таки!!!).
Ой... MMORPG все упали ниц... да на любой сервер прилжений в сердней конторе нагрузка не меньше. И ничего их пишут и на .NET и на мение шутсрой Жабе... V>Плюс была применена очень эффективная оптимизация этого менеджера, когда при освобождении всех объектов, то есть когда указатель на хвост догонял указатель на голову, оба этих указателей сбрасывались в начало буфера. Благодаря этому бОльшая часть буфера все время находилась в файле подкачки и извлекалась оттуда только в случае "затора" сообщений.
А Мусорщик оптимизирует нулевое поколение под кешь процессора... И кто быстрее?
Кстати а что произойдет если буфера таки не хватит?
V>По поводу большенства мертвых объектов. Доставала объекты оснавная программа (сервер), а не сетевая библиотека. И когда сервер соизволит достать очередное сообщение — это только серверу известно, и сколько поколений переживут сообщения в буффере тоже не понятно. Далее, подумай про объемы: 8к сообщений в секунду, каждое из которых в среднем по 4 килобайта. Получаем 32 мегабайта в секунду.
Из этих цифр следует что сервер весьма шустро выберает сообщения. Иначе у вас вся память бы забилась... V>Некислая я скажу нагрузка на ГЦ будет — дефрагментация получится очень "вкусной" операцией
Угу... вот только мусорщик не дураки писали... если в нулевом поколении скопилось много живых объктов то весь блок просто перевидут в первое поколение без дефрагментации... А под нулевое поколение выделят новый блок памяти.
Причем если верить тебе то заторы у вас случались редко...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, prVovik, Вы писали:
Д>>но при этом рынок переполнен играми, которые глючат, тормозят на ровном месте и жрут память вагонами. V>И о чем это говорит?
Я бы сказал вот только мне после этого придется себя забанить...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, prVovik, Вы писали:
WH>>>Вот только про разработчиков игр не надо. Я с ними очень не мало общался. В подавляющем большинстве случаев это просто жутчайшие консерваторы готовые удавится за пол процента производительности.
Д>>но при этом рынок переполнен играми, которые глючат, тормозят на ровном месте и жрут память вагонами.
V>И о чем это говорит?
это говорит о том, что излишний консерватизм до добра не доводит.
z00n wrote: > C>Кстати, отсутствие задержек GC важно в играх, например. И чего-то у нас > C>качественных сложных игр на суперпроизводительном .NET пока не видно, за > C>исключением портов старых Doom/Quake'ов. > Старая мантра. Для игр достаточно самых примитивных GC
Хороший пример, кстати. В U3 они используют GC для UScript'а и некоторых
игровых объектов, что вполне логично.
А вот дорогими ресурсами (файлы, текстуры и т.п.) управляют
непосредственно из С++. Дорогие мутирующие операции тоже производятся в
С++ без вмешательства GC.
Cyberax wrote: > А вот дорогими ресурсами (файлы, текстуры и т.п.) управляют > непосредственно из С++. Дорогие мутирующие операции тоже производятся в > С++ без вмешательства GC.
И еще:
UnrealScript uses a simple recursive mark-and-sweep garbage collector
which is only executed when changing levels, along with some special-case code to garbage-collect destroyed actors during
gameplay.
Здравствуйте, WolfHound, Вы писали:
WH>Да какая разница? Это всеравно будут коротко живущие объекты. E>>А обработка 8K сообщений в секунду в сетевом приложении это не кисло. WH>И как сеть связана с мусорщиком? Вобще говоря сеть по сравнению с мусорщиком тормоз просто жутчайший.
Смотря какая сеть.
А вообще я говорил о том, что обработка 8K сообшений в секунду, будь это в real-time приложении, это было бы очень серьезно. Ведь на обработку каждого сообщения требовалось бы не больше 125 микросекунд. А ведь обработка -- это не только new/delete.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, prVovik, Вы писали:
V>>Плюс была применена очень эффективная оптимизация этого менеджера, когда при освобождении всех объектов, то есть когда указатель на хвост догонял указатель на голову, оба этих указателей сбрасывались в начало буфера. Благодаря этому бОльшая часть буфера все время находилась в файле подкачки и извлекалась оттуда только в случае "затора" сообщений. WH>А Мусорщик оптимизирует нулевое поколение под кешь процессора...
Звучит впечатляюще
WH>И кто быстрее?
Конечно, быстрее будет фиксированный буфер небольшого размера с последовательным доступом. Могут быть сомнения?
WH>Кстати а что произойдет если буфера таки не хватит?
Сервер перестанет принимать новые сообщения, пока не разгребет старые. Пользователей "лаганет".
WH>Угу... вот только мусорщик не дураки писали... если в нулевом поколении скопилось много живых объктов то весь блок просто перевидут в первое поколение без дефрагментации... А под нулевое поколение выделят новый блок памяти.
*мечтательно* эх, а была бы память бесконечной, ее бы тогда вообще не надо было бы освобождать
Здравствуйте, WolfHound, Вы писали:
WH>... этот разоблачитель сравнивает теплое с мягким ...
Это да. Но то, что на C# можно писать не создавая мусора, не отменяет того, что библиотека .NET Framework иногда создает его там, где это не является необходимым; например StreamReader.ReadLine при каждом вызове возвращает новый String, и в классе StreamReader нет метода читающего в имеющийся StreamBuilder.
Здравствуйте, WolfHound, Вы писали:
WH>Я думаю там были какието другие тормоза. Ибо я не верю что сборку мусора можно заметить на глаз даже на телефоне.
Может быть, но было так: Пытаюсь сохранить новую запись, нет места. Удаляю некоторые ненужные записи и пытаюсь сохранить еще раз. Телефон "зависает" секунд на 10, потом сохраняет запись. Наблюдал такое поведение несколько раз. Siemens M55.
Здравствуйте, Cyberax, Вы писали:
C>eao107 писал явно не про Windows, если посмотришь выше по треду.
А про что? Про Линукс? Про переносимый софт? Ды эти случаи тоже по определению не могут быть реалтаймными.
C>Кстати, отсутствие задержек GC важно в играх, например.
Кстати, отсуствие задержек видимых человеком и требования к СРВ — это разные вещи.
Современные ЖЦ, особенно дотнетный, отлично подходят для интерактивных задач.
C> И чего-то у нас C>качественных сложных игр на суперпроизводительном .NET пока не видно, за C>исключением портов старых Doom/Quake'ов.
Их не видит, тот кто не хчет. Скачай Арену понляди.
>> C>А с realtime-GC уже радужная картина с "простым увеличением указателя на >> C>свободное место" пропадает. >> Не о собых проблем с realtime-GC. Просто у оного класса алгоритмов свои >> особенности. C>Да? Хотите поговорить об этом?
Не с тобой.
В общем, старая заезжаенная пластинк уже надоела. В стоый раз повторяются "аргументы" которые не выдерживают даже малейшей критики. Мне это попросту не интересно. Счастливо оставаться со своими фобиями наедине.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>Кстати, отсутствие задержек GC важно в играх, например. WH>Бред. Сборки нулевого и первого поколений никто не заметит ибо они не приведут к выпадению кадров. А сборка второго поколения приведет к выпадению одного кадра раз в несколько минут. И это тоже никто не заметит.
Реально и сборка второго поколения не страшна, так как может производиться с помощью Concurrent GC.
WH>Вот только про разработчиков игр не надо. Я с ними очень не мало общался. В подавляющем большинстве случаев это просто жутчайшие консерваторы готовые удавится за пол процента производительности.
И что самое забавное порождающие при этом монстров вроде ФИРА.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>А где противоположная гарантия, что ЖЦ лучше моего решения? Напиши аналогичную программу на ЖЦ и сравним.
Зачем же программу? Достаточно корректных тестов. Я их пописал не много, и сейчас уже вряд ли буду заниматься такой фигней, как совственные системы управления памятью.
Кстати, можешь попробовать вместо своего чуда техники просто вставить мой QuickHeap. Будет любопытно...
VD>>В общем, не нужно тыкать в свой код. K>А в какой надо тыкать, в чужой?
В код известных приложений получивших конкуретное приемущество благодоря ручным оптимизациям. Ведь если это действительно есть, то не составит труда найти радужный отчет об этом?
VD>>Я вот видил пару оптимизаций в соей жизни. И весе они без проблем заменялись бы ЖЦ. Вот к примеру, компилятор C# (MS-ный) использует пул для каких-то тама оптимизаций. Вот только пул ничем не отличается от ЖЦ основанного на поколения с точки зрения скорости.
K>Свежо предание, но верится с трудом.
А ты не верь. Ты проверь. Я вот проврял. И если памяти достаточно, то ЖЦ обычно выглядит очень не плохо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Ещё бы! Это же один из основных сценариев, под которые .NET GC был перво-наперво соптимизирован.
Цитирую вопрос:
А может это и вовсе одно и то же сообщение выводимое 10000000 раз в секунду, чтобы поиздеваться над сборщиком мусора?
A> А потом некоторые люди вроде Дона Бокса парили мозги людям, показывая на этом сценарии, какой это великолепный сборщик мусора, и как он легко уделывает new/delete в десятки а то и более раз. Это явление даже своё имя получило: Don Box Hoax. Поищите в google groups кому не лень.
Понимаш ли, Дон Бокс человек уважаемый и просто так свое имя позорить не будет. Он говорит то, что есть. Единственное разумное возражение тут может быть одно. При ручном управлении памятью ее зачастую можно занимать в секе. Это действително более эффективно. Но и тут есть что сказать. 1. Вэлю-типы в дотнете тоже позволяют избавиться от динамической памяти. 2. Скоро появятся промышленные реализации рантаймов автоматически размещающие объекты в стеке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Еще вопросы есть?
ANS>Я, в общем, с тобой согласн, но в примере демонстрируется идеальный случай.
Прошу обратить внимание на то, что это ответ на реплику:
VD>А сообщения одного размера? Ой не верю.
А вдруг? А может это и вовсе одно и то же сообщение выводимое 10000000 раз в секунду, чтобы поиздеваться над сборщиком мусора?
Оппоненты откровенно неразбираются в сути вопроса и всю свою логику строют на основе совбственных фобий и предубеждений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>При чем тут ассемблер и высокоуровневые языки?
При том, что ручное уравление памятью ничем не отличается от ручного управления кодогенерацией. Потенциально получить выигрышь безуслвоно можно. Но при некоторых объемах просто нереально.
V>Смысл моего топика был в том, что часто работа с памятью происходит (или может происходить) согласно некоторых предопределенных схем. Например, это может быть схема: первый создался, первый удалился. В этих условиях применение применение универсальных рааспределителей памяти (гц, или хип) может оказаться нецелесообразным.
Пойми. И GC и неуправляемые коучи пишут не идеоты. И если у меня скоростная характеристика близка к O(1), то хоть в лепешку разбейся но серьезного выигрыша ты неполучишь.
Знаешь, как легче всего получить выигрыш от собственной реализации кучи?
Просто не задействовать в ней защиту от многопоточного доступу. Блокировки (даже самые легкие) отнимают основное время при выделении памяти.
В ЖЦ, выделение памяти в них деалется просым инкрементом. И основные затраты тут тоже на блокировку.
V>Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом.
Бнин, свой хип для оптимизации 8 000 выделений объектов в секунду, да еще в программе которая по определению не предвявлет особых требований к производительности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
