Здравствуйте, BulatZiganshin, Вы писали:

BZ>вот то-то и оно, что C++ почитай описание GC. ведь это очень просто — если последний большой GC нашёл 10 мб реальных объектов, то следующий GC можно сделать когда общий объём распределённой памяти будет 20 мб или даже 11 мб. это и даёт гарантии

GC не используется в С++ только по причине отсутствия реальной необходимости в нем.
Если сильно приспичит — ничего не мешает использовать GC и в C++, это даже имеет смысл в движках активно работающих с графами.
Я (и не только я) когда-то писал

Автор: NikeByNike
Дата: 19.06.08

свой GC, но забросил — он просто недостаточно востребован.

Здравствуйте, BulatZiganshin, Вы писали:

NBN>>Потому что есть не менее эффективный С++, а что?

BZ>не было в 80-х годах ни C++, ни эффективных оптимизирующих компиляторов. тем не менее полчему-то люди обходились пессимизирующими С-компляторами. садись, опять двойка

Ты сам ответил совсем неполно, а следовательно не верно

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>Это слишком просто Пул это блок определенного размера, в котором выделение памяти происходит так же порциями определенного размера: 12, 20, 28, 36, 44 (шаг меняется с увеличением размеров на которые ориентирован пул), есть еще и отдельные пулы для средних и крупных блоков. В твоем примере будут выделяться блоки из первого пула по 12 байт, и ни какой фрагментации. Эффективность использования пулов можно контролировать тем самым трекингом, и в случае необходимости внести коррективы в алгоритм. Надо заметить, что лично мне ни разу не приходилось затачивать алгоритмы под работу менеджера памяти.

G>>Только общее увеличение потребления памяти получим.
G>>А кто-то еще ругается что .NET много памяти жрет.

H>Конечно получим, куда же мы денемся. Только оверхед сильно меньше, чем у .Net . Это я про общий случай, и по реальным приложениям это видно.
И по какой причине он станет "сильно меньше"?

Здравствуйте, gandjustas, Вы писали:

H>>>>Это слишком просто Пул это блок определенного размера, в котором выделение памяти происходит так же порциями определенного размера: 12, 20, 28, 36, 44 (шаг меняется с увеличением размеров на которые ориентирован пул), есть еще и отдельные пулы для средних и крупных блоков. В твоем примере будут выделяться блоки из первого пула по 12 байт, и ни какой фрагментации. Эффективность использования пулов можно контролировать тем самым трекингом, и в случае необходимости внести коррективы в алгоритм. Надо заметить, что лично мне ни разу не приходилось затачивать алгоритмы под работу менеджера памяти.

G>>>Только общее увеличение потребления памяти получим.
G>>>А кто-то еще ругается что .NET много памяти жрет.

H>>Конечно получим, куда же мы денемся. Только оверхед сильно меньше, чем у .Net . Это я про общий случай, и по реальным приложениям это видно.
G>И по какой причине он станет "сильно меньше"?

Ты сейчас о чем говоришь, об общих случаях или о той синтетике с 7-8 байтовыми ячейками? Если о синтетике, то там выделение нафиг не нужно, достаточно динамического массива с размером ячейки в 8 байт. Получим при этом оверхед в 1 байт на ячейку. Если же ты об общих случаях, то тут существующий софт тому доказательство.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>>>Это слишком просто Пул это блок определенного размера, в котором выделение памяти происходит так же порциями определенного размера: 12, 20, 28, 36, 44 (шаг меняется с увеличением размеров на которые ориентирован пул), есть еще и отдельные пулы для средних и крупных блоков. В твоем примере будут выделяться блоки из первого пула по 12 байт, и ни какой фрагментации. Эффективность использования пулов можно контролировать тем самым трекингом, и в случае необходимости внести коррективы в алгоритм. Надо заметить, что лично мне ни разу не приходилось затачивать алгоритмы под работу менеджера памяти.

G>>>>Только общее увеличение потребления памяти получим.
G>>>>А кто-то еще ругается что .NET много памяти жрет.

H>>>Конечно получим, куда же мы денемся. Только оверхед сильно меньше, чем у .Net . Это я про общий случай, и по реальным приложениям это видно.
G>>И по какой причине он станет "сильно меньше"?

H>Ты сейчас о чем говоришь, об общих случаях или о той синтетике с 7-8 байтовыми ячейками? Если о синтетике, то там выделение нафиг не нужно, достаточно динамического массива с размером ячейки в 8 байт. Получим при этом оверхед в 1 байт на ячейку. Если же ты об общих случаях, то тут существующий софт тому доказательство.

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

Понятно , значит незнание.

Задумайтесь почему программы на С++ быстрее с таким плохим аллокатором?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>потому, что malloc/free на каждый глобальный объект может быть медленней, чем последовательное выделение памяти и затем gc, который за один раз собирает весь мусор

Даю подсказку
int a = 0;
int b = 3 + a;

Очень память дефрагментирует ? затратит линейное время на на выделение памяти и т.п. ?

Здравствуйте, gandjustas, Вы писали:

H>>Ты сейчас о чем говоришь, об общих случаях или о той синтетике с 7-8 байтовыми ячейками? Если о синтетике, то там выделение нафиг не нужно, достаточно динамического массива с размером ячейки в 8 байт. Получим при этом оверхед в 1 байт на ячейку. Если же ты об общих случаях, то тут существующий софт тому доказательство.

G>Почитай как работает выделение памяти в .NET. Там нету никакого оверхеда.

Рихтер:

У каждого объекта есть пара таких полей: указатель на
таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
по 16 байт

Это оверхед не аллокатора, а организации данных. Но тем не менее.

G>Оверхед может возникнуть из-за того что создается больше обеъктов, но это уже зависит от программы, а не от аллокатора.

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

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, alsemm, Вы писали:

NBN>>>Ага, а в задачу входит создание красивого, быстрого и кроссплатформенного кода и софта — это решаемо _только_ на С++. Даже ущербный С с этим не спрвится.
A>>Любая встравиваемая real-life JVM — это только C.
A>>Телефонный софт (OS, стандартные приложения) — только C.

NBN>Это далеко не так, хотя этой нечисти там действительно хватает
"Далеко не так" что?
Что JVM написан на C? А на чем их еще писать, если их надо запихивать черте куда, где вменяемого C++ компилятора и не стояло?
Телефонный софт — это как правило море legacy кода, древнего как, даже и не знаю что
Symbian — формально там конечно есть C++, но какой-то он на вид своеобразный.

Алексей

Здравствуйте, hattab, Вы писали:

H>Рихтер:
H>У каждого объекта есть пара таких полей: указатель на
H>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>по 16 байт

H>Это оверхед не аллокатора, а организации данных. Но тем не менее.
Ну без указателя на таблицу виртуальных методов врядли какой ООП язык обходится и в той же Делфи, если мне не изменяет память, функция New неявно по смещению сохраняет еще и объем выделенной памяти.

Здравствуйте, MxKazan, Вы писали:

H>>Рихтер:
H>>У каждого объекта есть пара таких полей: указатель на
H>>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>>по 16 байт

H>>Это оверхед не аллокатора, а организации данных. Но тем не менее.
MK>Ну без указателя на таблицу виртуальных методов врядли какой ООП язык обходится и в той же Делфи, если мне не изменяет память, функция New неявно по смещению сохраняет еще и объем выделенной памяти.

Я ведь не сказал, что в Delphi нет оверхеда Это была фраза на отсутствие оверхеда в .Net. В Delphi еще можно вспомнить о выравнивании, пусть и отключаемом, которое тоже увеличивает оверхед но положительно влияет на производительность. Но не смотря на все это, мы имеем то о чем я уже написал

Здравствуйте, gandjustas, Вы писали:

G>Маленький ликбез:
G>1)Стандартный аллокатор поддерживает связный список блоков памяти, выделение нового и освобождение блока вызывает проход по списку, который имеет алгоритмическое время O(n) от количества блоков.
G>При постоянных выделениях-освобождениях памяти получются очень большие затраты на эту простую операцию.
G>2)При выделении блока идет небольшой оверхед, который зависит от реализации, 16-32 байта кажись. Исследования исходных кодов программ показывают что средний размер объекта составляет от 32 до 128 байт, при такких размерах оверхед является очень значительным.
G>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров.
G>4)Алгоритм выделения памяти не потокобезопасный, требуется синхронизация.
G>5)В программах на С++ часто делают свои аллокаторы, которые выделяют память для маленькиз объектов чтобы избежать описанно выше оверхеда как по потребляемой памяти, так и по времени этой операции
Вот именно. В частности аллкоаторы для блоков фиксировааной длины. Я не знаю, как сделать оверхед в таких аллокаторах нулевым, знаю только как сделать, чтобы оверхед был 1бит на блок + ~30байт на страницу. Если условия задачи позволяют, можно еще и компактирование страниц в таких аллокаторах сделать, т.е. перекидывать содержимое блоков между ними так, чтобы минимизировать дефрагментацию и аллокатор держал свободными блоков не более чем на одну страницу.

G>Теперь о GC
G>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю
Это, если память есть свободная.
G>7)Оверхед по выделяемой памяти равен 8 байтам на 32-битной платформе (может ошибаюсь немного, лень смотреть)
G>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна.
Конечно потокобезопасно, еще бы. Только потокобезопасность — не бесплатная.

G>9)такое распределение памяти увелиичивает cache-locality
G>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении
G>11)Для нулевого поколения объем памяти — пара сотен КБ, этот кусок очень хорошо ложится в кеш процессора.
G>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить.
Реальный недостаток GC — это его непредсказуемость. Эта сущность не управлется из клиентского кода никак. Она может проснуться когда посчитает нужным. Если бы GC давал равномерную нагрузку на CPU, то никто бы от него не плевался. У идеального GC не должно быть "всплесков" и "провалов" активности, он должен просыпаться через фиксированные промежутки времени и отрабатывать каждый раз фиксированный квант времени, а не "залипать" разгребая образовавшиеся завалы.

G>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь
Это все ужимки и бег на месте, навроде java.lang.System.gc(), который ничего не гарантирует.

К сожалению, имидж управляемых сред был сильно подпорчен первыми версиями Java. Так что вы тут хоть 1000 аргументов в пользу C# приведите, стереотипы забороть очень тяжело.

Еще одна проблема C# — низкий порого вхождения для новичков. Собственно это не проблема — это вроде как его преимущество, теоретически.
На C++ писать надо аккуратно, чтобы хотя бы как-то работало. В управляемой среде писать дерьмовый код проще — утечки памяти (не все знают что такое WeakReference и зачем они нужны) маскируются мусоросборщиком, никих тебе AV и прочих мерзостей которые заканчиваются crash dump.

Алексей

Здравствуйте, BulatZiganshin, Вы писали:

BZ>в языках без gc расход памяти меньше в краткосрочном плане. а вот когда память выделяется, возвращается, снова выделяется — ты получаешь фрагментированную память и ничего с ней не поделаешь. поэтому для таких программ GC выгодней — есть хоть гарантии что расход памяти будет не более чем в три раза выше, нежели реальное использование. в c++ гарантий никаких
Написал я как то монитор выделяемой произвольным процессом памяти. Дабы значицца, посмотреть что там да как происходит в закулисье.
И что я только не гонял сей прогой, но пресловутой фрагментации увидеть так и не удалось.
HeapAlloc, который уже давным давно используется вместо говноаллокатора ранних версий CRT, отлично справлялся сам.

Здравствуйте, NikeByNike, Вы писали:

NBN>На яве и шарпе нельзя написать качественный продукт удовлетворяющий требованиям
Зависит от требований. Вообще у каждого языка есть своя ниша, определяемая пересечением требований с возможностями и ограничениями языка.

ЗЫ: Щас конечно вылезет кто нить из святой кучки апологетов и начнет кричать что у языка Х возможности безграничны, а ограничения несущественны.

Здравствуйте, BulatZiganshin, Вы писали:

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

Здравствуйте, hattab, Вы писали:

...
H>Большое количество вызовов GC это прямой урон перформансу, он же не просто так дергается, он собирает чего-то. К тому же счетчик %Time In GC совсем не нулевой, да еще и на таком коротком отрезке времени (чему я был сильно удивлен). Я сейчас не говорю о каких-то цифрах, я об общем поведении.

MK>>В конце концов тот же rpc-xml может это сам явно делать по каким-то своим умозаключениям. У меня вот в WPF'ной проге, окна иной раз не собираются по 10-20 минут. Можно ли быть уверенным, что моя прога в сто раз быстрее твоей?

H>В коде xmlrpc.net явного вызова GC.Collect нет.

Сборщики бывают нескольких типов. Может у вас параллельный сборщик работает, который в Idle time просто собирает статистику для настоящей сборки мусора, которая, благодаря такой предварительной подготовке работает очень быстро.

ЗЫ: А может и сами компоненты написаны неряшливо...

Здравствуйте, alsemm, Вы писали:

A>Что JVM написан на C? А на чем их еще писать, если их надо запихивать черте куда, где вменяемого C++ компилятора и не стояло?
A>Телефонный софт — это как правило море legacy кода, древнего как, даже и не знаю что
A>Symbian — формально там конечно есть C++, но какой-то он на вид своеобразный.

Я писал под брю и его потомков — WIZE и PDK, там было много старого кода на С и не меньше нового на С++, в частности вся гуйня.

Здравствуйте, CreatorCray, Вы писали:

NBN>>На яве и шарпе нельзя написать качественный продукт удовлетворяющий требованиям
CC>Зависит от требований.
Нашим требованиям — создать лучший продукт. Я бы с радостью на шарпе писал, но он, как и ява недостаточно кроссплатформенны и слишком тормозявы на девайсах, для нашей достаточно сложной программы. Каждого из этих факторов достаточно, чтобы от них отказаться в пользу С++.

Здравствуйте, CreatorCray, Вы писали:

CC>Написал я как то монитор выделяемой произвольным процессом памяти. Дабы значицца, посмотреть что там да как происходит в закулисье.
CC>И что я только не гонял сей прогой, но пресловутой фрагментации увидеть так и не удалось.
CC>HeapAlloc, который уже давным давно используется вместо говноаллокатора ранних версий CRT, отлично справлялся сам.

Скажите пожалуйста на каких компиляторах вы тестировали и если это VS начиная с какой версии компилятор/crt нет проблем с фрагментацией.

Спасибо

Здравствуйте, sergey2b, Вы писали:

S>Скажите пожалуйста на каких компиляторах вы тестировали и если это VS начиная с какой версии компилятор/crt нет проблем с фрагментацией.

У шестёрки в первых версиях был галимый аллокатор, точно помню...