Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, igna, Вы писали:
I>>А вдруг? А может это и вовсе одно и то же сообщение выводимое 10000000 раз в секунду, чтобы поиздеваться над сборщиком мусора?
VD>
VD>Количество сборок в поколнии 0: 8084
VD>Количество сборок в поколнии 1: 0
VD>Количество сборок в поколнии 2: 0
VD>
VD>Еще вопросы есть?
Ещё бы! Это же один из основных сценариев, под которые .NET GC был перво-наперво соптимизирован. А потом некоторые люди вроде Дона Бокса парили мозги людям, показывая на этом сценарии, какой это великолепный сборщик мусора, и как он легко уделывает new/delete в десятки а то и более раз. Это явление даже своё имя получило: Don Box Hoax. Поищите в google groups кому не лень.
Здравствуйте, alexeiz, Вы писали:
A>Ещё бы! Это же один из основных сценариев, под которые .NET GC был перво-наперво соптимизирован. А потом некоторые люди вроде Дона Бокса парили мозги людям, показывая на этом сценарии, какой это великолепный сборщик мусора, и как он легко уделывает new/delete в десятки а то и более раз. Это явление даже своё имя получило: Don Box Hoax. Поищите в google groups кому не лень.
Если ты про это http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0208a&L=atl&D=0&P=20241
То заявления данного персонажа яйца выеденого не стоят ибо нет исходных кодов тестов. Следовательно невозможно преверить корректность тестов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, alexeiz, Вы писали:
A>>Ещё бы! Это же один из основных сценариев, под которые .NET GC был перво-наперво соптимизирован. А потом некоторые люди вроде Дона Бокса парили мозги людям, показывая на этом сценарии, какой это великолепный сборщик мусора, и как он легко уделывает new/delete в десятки а то и более раз. Это явление даже своё имя получило: Don Box Hoax. Поищите в google groups кому не лень. WH>Если ты про это
Я не про это, а про Дона Бокса.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, alexeiz, Вы писали:
WH>>>Если ты про это A>>Я не про это, а про Дона Бокса. WH>Что про Дона Бокса? То что он лжет нужно доказать.
VladD2 wrote: > C>Зато во время сборки ГЦ имеют обыкновение периодически сканировать > C>память, причем несовсемтимо с realtime'ом. > Какой на фиг реалтайм под Виндовс? Что ты к нему цепляшся. Ты хоть одну > программу реального времени написал?
eao107 писал явно не про Windows, если посмотришь выше по треду.
Кстати, отсутствие задержек GC важно в играх, например. И чего-то у нас
качественных сложных игр на суперпроизводительном .NET пока не видно, за
исключением портов старых Doom/Quake'ов.
> C>А с realtime-GC уже радужная картина с "простым увеличением указателя на > C>свободное место" пропадает. > Не о собых проблем с realtime-GC. Просто у оного класса алгоритмов свои > особенности.
Да? Хотите поговорить об этом?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prVovik, Вы писали:
V>>Тут дело даже не в том, что теоетически можно написать супер-аллокатор, применив какие-то инновационные супер оптимальные алгоритмы, которые в конечном счете "порвут" ГЦ. Нет, вся соль в том, что в аллокаторах можно учесть специфику конкретного приложения, благодаря которой можно реализовать крайне эффективное управление памятью, с которой не сможет сравниться никакие универсальные ГЦ и кучи.
VD>Хм. Несомненно! Как несомнено то, что потенциально можно написать любую программу на ассемблере и добиться того, что она будет быстрее любой скомпилированной с высокоуровневого языка.
При чем тут ассемблер и высокоуровневые языки? Смысл моего топика был в том, что часто работа с памятью происходит (или может происходить) согласно некоторых предопределенных схем. Например, это может быть схема: первый создался, первый удалился. В этих условиях применение применение универсальных рааспределителей памяти (гц, или хип) может оказаться нецелесообразным.
VD>Вот только не некотором объеме оказывается, что затраты на ручную оптимизацию слишком высоки. К тому же оказывается, что для того чтобы осуществить эти оптимизации нужно обладать нехилыми знаниями в довольно тонких вопросах (вроде влияния кэша процессора и т.п.). Ну, и в итоге получается, что в 99.9% случаев GC окажется предпочтительнее.
Конь в вакууме? Какая еще ручная оптимизация? Они разные бывают.
V>> Например, очень часто можно заметить, что 90% некоторых объектов в программе удаляются (то есть становятся ненужными) в той же последовательности, что и создаются. В этом случае можно использовать супер эффективный менеджер памяти, реализованный на основе циклического буффера. Он будет работать, как О(1), причем константа будет чрезвычайно мала (порядка нескольких команд процессора). Пример такой задачи: к нам приходят сообщения, мы их накапливаем в некотором буффере и постепенно обрабатываем. После обработки сообщение нас больше не интересует.
VD>А сообщения одного размера? Ой не верю. А если разных, то твоя идея идет лесом, так как блок маленького размера будет непригоден для следующего сообщения имеющего больший размер.
Не важно какого размера блоки. Важен только их порядок создания и удаления. Есть выделенный кусок памяти и два указателя: один указывает на голову "кучи", второй на "хвост". Выделяем с "головы", удаляем с "хвоста", просто перемещая соответствующим образом указатели.
VD>В то же время ЖЦ основанный на поколениях довольно эффективно разрулит эту ситуацию.
В том то и дело, что он ее будет РАЗРУЛИВАТЬ, как в прочем и хип. А тут то и рулить нечего! Прямо как в том анектоде: "Что тут думать — прыгать надо!"
VD>Можно сслочку на то, где ты видел подобные решения в реальной жизни? Сколько таких случаев было?
Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом.
VD>В случае если нужен стек, то использовать лучше стек. VD>И чаще всего тут не катит. Только если объекты живут в стиле LIFO.
Нет. В случае, если удаляется объект не на вершине, то можно запоминать удаляемый указатель и реально освобождать память уже после того, как удалится объект на вершине стека. Точно такая же стретегия и для FIFO.
VD>Ну, а в С++ и без всяких аллокаторов можно вручную размещать объекты в стеке.
Не всегда удобно. Я имел ввиду именно некоторое хранилище объектов, которое разделяется между разными участками кода.
VD>Тут оно как. Или ты пишешь программу, или занимашся оптимизациями. Так вот ЖЦ можно рассматривать как автоматическое средство глобальной оптимизации.
У ГЦ есть свои особенности, которые в одних случаях идут в "+", а в других в "-". Да ты и сам об этом далее говоришь. Важно то, что и ГЦ и хип — это УНИВЕРСАЛЬНЫЕ средства, которые понятия не имеют о логике и характере работы моей программы.
VD>Увеличить производительность на порядки можно просто использовав более подходящие алогоритмы.
Совершенно верно! Например, использовав более подходящие задаче алгоритмы управления памятью. Именно это и было сделано.
VD>Так вот рельно лучше сосредоточиться на оптимизации прикладных алгоритмов, а не на оптимизации системных вещей вроде выделения памяти. В будущем, когда появятся более эффективные методы автоматической оптимизации можно будет извлечь из них выгоду.
Если задача близка к системной, то управление памятью может стать прикладной задачей.
Здравствуйте, alexeiz, Вы писали:
A> ... Don Box Hoax. Поищите в google groups кому не лень.
. . .
My measurements shows a performance ratio of 8:1 in advantage for C#
over C++. But no C++ would allocate such small objects on the heap.
C#, on the otherhand, have no choice. And if you rewrite to proper C++
code you get a ratio of 42:1 -that is C++ is 42 times (!) quicker than
C#. So I enlarged the test with a) object specific new/delete op and
b) with a object of approx size 32 kb. The meassurements are found
below — and they are quiet astonishing: C++ outperforms C# in every
aspect, only with one exception: the Don Box demo!!!
Здравствуйте, Cyberax, Вы писали:
C>Кстати, отсутствие задержек GC важно в играх, например.
Или такой пример: Случайно выключил телефон во время процесса подозрительно напоминающего сборку мусора, результат — пропажа кое-какой информации. Да, понимаю, программа не должна была разрешать выключение в это время; но это пример того, как уменьшая вероятность ошибок программиста в одном месте использование GC увеличивает ее в другом.
Здравствуйте, Cyberax, Вы писали:
C>Кстати, отсутствие задержек GC важно в играх, например. И чего-то у нас C>качественных сложных игр на суперпроизводительном .NET пока не видно, за C>исключением портов старых Doom/Quake'ов.
Старая мантра. Для игр достаточно самых примитивных GC:
Tim Sweeney:
Garbage collection performance in games:
Though an Unreal Engine 3 game can easily consume 512MB memory (on console) or up to 2GB (on PC, in the editing tools), less than 10% of that memory consists of data that contains pointers. The rest is bulk binary resources — like texture maps, sounds, animations, which don't require scanning for references.
50MB of data is well within the range of a mark-and-sweep garbage collector taking a few milliseconds within a game running at 30 frames per second. This is what we do. Realtime garbage collection is another possibility, but we didn't want to try to implement that within a primarily C++ engine.
Garbage collecting memory:
I do believe this is completely practical as the sole memory management solution, even in a realtime application like a game.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Хотите раельных программ? Их есть у меня.
K>>http://www.qform3d.com/en/91.html — использует рукописный (мой) менеджер памяти.
K>>Стандартный хип на таких обьемах уже не просто тормозил, но и не мог выдать требуемое число блоков. Тогда я написал свой собственный менеджер памяти, и все стало ок.
VD>И где гарантия, что твое решение не является в пустую потраченным временем по сровнению с банальным выбором ЖЦ?
А где противоположная гарантия, что ЖЦ лучше моего решения? Напиши аналогичную программу на ЖЦ и сравним.
VD>В общем, не нужно тыкать в свой код.
А в какой надо тыкать, в чужой?
VD>Я вот видил пару оптимизаций в соей жизни. И весе они без проблем заменялись бы ЖЦ. Вот к примеру, компилятор C# (MS-ный) использует пул для каких-то тама оптимизаций. Вот только пул ничем не отличается от ЖЦ основанного на поколения с точки зрения скорости.
I>My measurements shows a performance ratio of 8:1 in advantage for C# over C++. But no C++ would allocate such small objects on the heap. C#, on the otherhand, have no choice. And if you rewrite to proper C++ code you get a ratio of 42:1 -that is C++ is 42 times (!) quicker than C#. So I enlarged the test with a) object specific new/delete op and b) with a object of approx size 32 kb. The meassurements are found below — and they are quiet astonishing: C++ outperforms C# in every aspect, only with one exception: the Don Box demo!!!
Еще раз: Данное заявление без исходных кодов ничего не стоит. То есть АБСОЛЮТНО НИЧЕГО.
Особенно на фоне выделеного... этот разоблачитель сравнивает теплое с мягким и при этом не знает о существовании value типов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, prVovik, Вы писали:
VD>>Можно сслочку на то, где ты видел подобные решения в реальной жизни? Сколько таких случаев было? V>Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом.
8 тысяч коротко живущих объектов в секунду... да ГЦ это даже не заметит. Это для него вобще не цифра.
Причем если для обычной кучи объекты разного размера приводят к фрагментации и серьезному замедлению работы то мусорщику на это начхать.
Болие того алгоритм мусорщика таков что при сборке мусора время тратится ТОЛЬКО на живые объекты. А в твоем случае подавляющие большинство объектов будут мусором.
Те это вобще идеальные условия для мусорщика.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, igna, Вы писали:
I>Или такой пример: Случайно выключил телефон во время процесса подозрительно напоминающего сборку мусора, результат — пропажа кое-какой информации. Да, понимаю, программа не должна была разрешать выключение в это время; но это пример того, как уменьшая вероятность ошибок программиста в одном месте использование GC увеличивает ее в другом.
Я думаю там были какието другие тормоза. Ибо я не верю что сборку мусора можно заметить на глаз даже на телефоне.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Кстати, отсутствие задержек GC важно в играх, например.
Бред. Сборки нулевого и первого поколений никто не заметит ибо они не приведут к выпадению кадров. А сборка второго поколения приведет к выпадению одного кадра раз в несколько минут. И это тоже никто не заметит. C>И чего-то у нас качественных сложных игр на суперпроизводительном .NET пока не видно, за исключением портов старых Doom/Quake'ов.
Вот только про разработчиков игр не надо. Я с ними очень не мало общался. В подавляющем большинстве случаев это просто жутчайшие консерваторы готовые удавится за пол процента производительности.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом. WH>8 тысяч коротко живущих объектов в секунду... да ГЦ это даже не заметит. Это для него вобще не цифра.
Как я понимаю, речь шла не о 8K объектов в секунду, а об обработке 8K сообщений в секунду. Еще не известно, сколько и чего создавалось во время обработки одного сообщения. А обработка 8K сообщений в секунду в сетевом приложении это не кисло.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
