Здравствуйте, CreatorCray, Вы писали:
CC>Тут: http://creatorcray.googlepages.com/MemMon.rar
CC>Гуй в нем делался на скорую руку бо сильно нужны были результаты замеров. CC>вкратце основные кнопы: CC>+- — зум CC>курсорные стрелки + ins/del — перемещение. CC>В силу особенностей перехвата работает не до абсолютной смерти проги, отключается несколько раньше, но позже завершения main.
Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3.
Здравствуйте, hattab, Вы писали:
H>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3.
Небось Athlon?
Собиралась ICC 11 с опцией /QxSSE3. Я то могу вырубить, но там либа используется, которая уже с SSE3 собрана.
Попробую перевыложить.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Кроме того, скорость (и cache locality) для HeapAlloc (и соответственно для стандартного аллокатора) сильно повышает следующее:
CC>
Здравствуйте, hattab, Вы писали:
H>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3.
Там просто если ICC считает что твой проц не поддерживает нужные фичи то он делает printf и exit
Прога не консольная, посему в консоль ничего не пишет, а printf этот происходит до winmain.
Выложил собранные без оптимизаций вообще. Вообще удивлён что сей сурс собрался с первой попытки и даже без ворнингов, как никак года три ему наверное, и кинут был на полпути.
У меня самый старый комп что могу найти это P4 820, на нем работало и в первом случае.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении). G>>Вы бы разобрались что скрывается под словами "строит граф", обычный рекурсивный обход без построения динамических структур. G>>Оверхеда там действительно нет, как бы вам не хотелось обратного.
H>Рихтер с тобой не согласен: H>
При компиляции IL-кода метода JIT-компилятор создает, помимо машинного
H>кода, внутреннюю таблицу. Логически каждая строка таблицы указывает диапа-
H>зон смещений байтов машинных кодов процессора, и адреса корней для каждого
H>диапазона (или регистра процессора)
H>Далее: H>
Начиная работу, сборщик предполагает, что все объекты в куче — мусор. Ина-
H>че говоря, он предполагает, что ни один из корней приложения не ссылается на
H>объекты в куче. Затем сборщик проходит по корням, строя граф всех достижи-
H>мых объектов. Например, он может найти глобальную переменную, указывающую
H>на объект в куче. На рис. 19-2 показана куча с несколькими объектами, где корни
H>приложения напрямую ссылаются на объекты А, С, D и F, Все эти объекты стано-
H>вятся частью графа. При добавлении объекта D сборщик замечает, что этот объект
H>ссылается на объект Н, добавляет объект Н к графу и продолжает рекурсивный
H>просмотр всех достижимых объектов.
H>Далее: H>
Завершив эту часть графа, сборщик мусора проверяет следующий корень и снова
H>проходит по объектам. Поскольку он проверяет объект за объектом, при попыт-
H>ке добавить к графу объект, уже добавленный ранее, он останавливается.
Включай мозг: все что требуется от такого "графа" только возможность проверить присуствует ли объект в нем. Это значит что достаточно битовго флага.
H>>>Размеры, и правда можно из метаданных получать, заплатив перформансом G>>С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).
H>Ты же сам про процессорный кэш упоминал... Забыл?
Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается.
Стандартный аллокатор тоже неспособствует частому попаданию в кеш при выделении относительно неболишах блоков, причем эффект проявляется при каждом выделении-освобождении.
H>>>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера: H>>>
Как видите, сбор мусора вызывает существенное снижение производительно-
H>>>сти — это основной недостаток управляемой кучи.
G>>Только это все может работать быстрее, чем аллокатор на основе списков. H> Рихтер не авторит, да?
А причем тут авторитет? Это результатами тестов подтверждается.
H>>>Там есть Private bytes. G>>И че? H>Это реальный показатель: H>
Private Bytes represents the amount of private virtual memory a process has allocated and is the value that will rise of a process exhibiting a memory leak bug.
Такой же эфимерный показательнь для GC.
G>>>>Нативная программа использует GDI+ для этих целей? G>>>>Память там в основном жрет не .NET, а GDI+ (который тоже нативный).
H>>>Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается. G>>Меня измерения потребляемой памяти на HelloWorld не интересуют.
H>Т.е. GDI+ реабилитирован?
Нет, это была и есть тормозная библиотека, пожирающая ресусры.
Мне в .NET несколько раз приходиллось использовать pinvoke для функций GDI чтобы рисование достаточно быстро происходило.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>>>Возьмите Paint.NET — на многих задачах работает быстрее фотошопа, но это разные весовые категории.
H>>>Дельфовый PhotoFiltre разрывает Paint.NET на куски G>>Скачал и поставил себе это. G>>Срзу узнал дельфовую программу. Дофига непонятных непермещаемых тулбаров. Дофига пунктов в меню, даже больше чем у фотошопа. G>>Сам такие интерфейсы ет пять назад плодил.
H>Так и в Paint.NET тулбары не перемещаемые, во всяком случае у меня в 3.31.
Там панели инструментов перемещаемые и полупрозрачные чтобы под ними было видно что нарисовано.
G>>Нету возможности работы со слоями, нету визуально undo/redo stack. H>У меня версия от 2004 года, тут действительно нет, но есть PhotoFilter Studio, там слои есть.
А я поледнюю скачал, там тоже нет
G>>При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET H>Это ты вероятно с Paint.Net спутал В нем действительно, при выделении (Magic Wand) изображения на картинке 400x647 начинаются тормоза: загрузка CPU в районе 100%, частота подскакивает до своего максимума в 1700MHz. PhotoFiltre при этом спокойно работает на минимуме в 600MHz не нагружая процессор выше 8%.
Я проверил на одинаковых картинках, жрет процессор одинаково, но у PhotoFiltre при этом торможит интерфейс
G>>Дельфовый PhotoFiltre разрывает Paint.NET на куски только во сне. G>>Хотя памяти от захавал меньше в 2 раз — 20 мб, против 40 для Paint.NET, но с моими двумя гигами мне как-то пофиг. G>>Скорость работы — одинаковая. H>Уж не надо про скорость заливать, PhotoFiltre летает заметно шустрее Paint.NET.
Мечты, мечты.
G>>>>Можете посмотреть Windows Live Writer, но анлогов вообще нет H>>>Дельфовый BlogJet... Ну ты понял G>>Тока он платный, так что сразу в пролете. H>Только он не единственный, этих блогопостилок вообще море, слабо сопоставляющееся со словами об отсутствии аналогов.
Здравствуйте, gandjustas, Вы писали:
H>>Во-первых, я не мониторю TaskManager'ом, а использую ProcessExplorer (там цифирки более другие ) G>Другие это какие?
Поставь посмотри.
G>Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени.
Есть еще Virtual size, Working set (private/shareable/shared) и Private bytes.
Процхп умеет показывать график реально юзаемой памяти по времени per process.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
H>>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3. CC>Небось Athlon?
Здравствуйте, CreatorCray, Вы писали:
H>>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3. CC>Там просто если ICC считает что твой проц не поддерживает нужные фичи то он делает printf и exit CC>Прога не консольная, посему в консоль ничего не пишет, а printf этот происходит до winmain. CC>Выложил собранные без оптимизаций вообще. Вообще удивлён что сей сурс собрался с первой попытки и даже без ворнингов, как никак года три ему наверное, и кинут был на полпути. CC>У меня самый старый комп что могу найти это P4 820, на нем работало и в первом случае.
Здравствуйте, gandjustas, Вы писали:
H>>>>Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении). G>>>Вы бы разобрались что скрывается под словами "строит граф", обычный рекурсивный обход без построения динамических структур. G>>>Оверхеда там действительно нет, как бы вам не хотелось обратного.
H>>Рихтер с тобой не согласен: H>>
При компиляции IL-кода метода JIT-компилятор создает, помимо машинного
H>>кода, внутреннюю таблицу. Логически каждая строка таблицы указывает диапа-
H>>зон смещений байтов машинных кодов процессора, и адреса корней для каждого
H>>диапазона (или регистра процессора)
H>>Далее: H>>
Начиная работу, сборщик предполагает, что все объекты в куче — мусор. Ина-
H>>че говоря, он предполагает, что ни один из корней приложения не ссылается на
H>>объекты в куче. Затем сборщик проходит по корням, строя граф всех достижи-
H>>мых объектов. Например, он может найти глобальную переменную, указывающую
H>>на объект в куче. На рис. 19-2 показана куча с несколькими объектами, где корни
H>>приложения напрямую ссылаются на объекты А, С, D и F, Все эти объекты стано-
H>>вятся частью графа. При добавлении объекта D сборщик замечает, что этот объект
H>>ссылается на объект Н, добавляет объект Н к графу и продолжает рекурсивный
H>>просмотр всех достижимых объектов.
H>>Далее: H>>
Завершив эту часть графа, сборщик мусора проверяет следующий корень и снова
H>>проходит по объектам. Поскольку он проверяет объект за объектом, при попыт-
H>>ке добавить к графу объект, уже добавленный ранее, он останавливается.
G>Включай мозг: все что требуется от такого "графа" только возможность проверить присуствует ли объект в нем. Это значит что достаточно битовго флага.
Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным.
H>>>>Размеры, и правда можно из метаданных получать, заплатив перформансом G>>>С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).
H>>Ты же сам про процессорный кэш упоминал... Забыл? G>Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается.
Ты посмотри, как этот редкий процесс накручивает счетчик, когда ты мышкой водишь над кнопками на тулбаре. К тому же не забывай, я давал пример, когда на один вызод метода по XML-RPC происходит 3 сборки мусора. Не веришь мне, проверь сам.
G>Стандартный аллокатор тоже неспособствует частому попаданию в кеш при выделении относительно неболишах блоков, причем эффект проявляется при каждом выделении-освобождении.
Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету.
H>>>>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера: H>>>>
Как видите, сбор мусора вызывает существенное снижение производительно-
H>>>>сти — это основной недостаток управляемой кучи.
G>>>Только это все может работать быстрее, чем аллокатор на основе списков. H>> Рихтер не авторит, да? G>А причем тут авторитет? Это результатами тестов подтверждается.
Так Рихтер и говорит, что управляемая куча это есть потеря перформанса. Впрочем, я уже понял, что твою слепую веру ничто не способно поколебать.
H>>>>Там есть Private bytes. G>>>И че? H>>Это реальный показатель: H>>
Private Bytes represents the amount of private virtual memory a process has allocated and is the value that will rise of a process exhibiting a memory leak bug.
G>Такой же эфимерный показательнь для GC.
При чем тут GC? Это показатель реально используемого/выделенного (не зарезервированного) объема, хоть с GC, хоть без GC
H>>>>Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается. G>>>Меня измерения потребляемой памяти на HelloWorld не интересуют.
H>>Т.е. GDI+ реабилитирован? G>Нет, это была и есть тормозная библиотека, пожирающая ресусры.
Еще раз: ресурсы (в частности речь шла о памяти) GDI+ не жрет. У него модель использования другая. Может почитаешь уже?
G>Мне в .NET несколько раз приходиллось использовать pinvoke для функций GDI чтобы рисование достаточно быстро происходило.
GDI+ это тормоз, я не спорю, только как ты это увязал с , якобы, прожорливостью для меня остается загадкой
Здравствуйте, gandjustas, Вы писали:
H>>Так и в Paint.NET тулбары не перемещаемые, во всяком случае у меня в 3.31. G>Там панели инструментов перемещаемые и полупрозрачные чтобы под ними было видно что нарисовано.
В PhotoFiltre панель инструментов тоже отцепляемая, в настройки глянь. Хотя обсуждение фейса, это все придирки не по теме.
G>>>Нету возможности работы со слоями, нету визуально undo/redo stack. H>>У меня версия от 2004 года, тут действительно нет, но есть PhotoFilter Studio, там слои есть. G>А я поледнюю скачал, там тоже нет
Так ты студию посмотри, там есть
G>>>При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET H>>Это ты вероятно с Paint.Net спутал В нем действительно, при выделении (Magic Wand) изображения на картинке 400x647 начинаются тормоза: загрузка CPU в районе 100%, частота подскакивает до своего максимума в 1700MHz. PhotoFiltre при этом спокойно работает на минимуме в 600MHz не нагружая процессор выше 8%. G>Я проверил на одинаковых картинках, жрет процессор одинаково, но у PhotoFiltre при этом торможит интерфейс
Я тоже проверил на одинаковых, и результат изложил выше, а посему позволь тебе не поверить.
Здравствуйте, hattab, Вы писали:
H>>>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3. CC>>Небось Athlon? H>Pentium M 735 (1.7) (Dothan)
А, ясно.
Их интел относит к категории /QxSSE2
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, CreatorCray, Вы писали:
H>>>Чего-то не запустилась у меня Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3. CC>>Там просто если ICC считает что твой проц не поддерживает нужные фичи то он делает printf и exit CC>>Прога не консольная, посему в консоль ничего не пишет, а printf этот происходит до winmain. CC>>Выложил собранные без оптимизаций вообще. Вообще удивлён что сей сурс собрался с первой попытки и даже без ворнингов, как никак года три ему наверное, и кинут был на полпути. CC>>У меня самый старый комп что могу найти это P4 820, на нем работало и в первом случае.
H>Новая работает
Надо будет как нить ее доработать.
К примеру она не "видит" аллокации из динамически подгружаемых DLL, только из статики. Не будет работать с упакованными/защищенными EXE и т.п. Как нить сделать чтобы можно было отловить откуда была выделена/освобождена память (StackWalk), правда глядя на объем данных, получаемый с простой программки (~200Mb) становится понятно что stackwalk на каждый alloc/free — это будет черезчур.
Плюс почему то к моменту выгрузки DLL не на все аллокации приходит освобождение, причем часто строго на определенном блоке заканчивается работа.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
G>Маленький ликбез: G>1)Стандартный аллокатор поддерживает связный список блоков памяти, выделение нового и освобождение блока вызывает проход по списку, который имеет алгоритмическое время O(n) от количества блоков.
Ты сам в это веришь? Это наивная реализация 80-ых годов. Сейчас используются всякого рода оптимизации, позволяющие минимизировать время поиска и частично отказаться от блокировок кучи. Например, в windows heap создается, если мне память не изменяет, на одну кучу 128 ассоциативных однонаправленных списков, не требующих блокировок.
G>При постоянных выделениях-освобождениях памяти получются очень большие затраты на эту простую операцию.
В С# в целом та же херня.
G>2)При выделении блока идет небольшой оверхед, который зависит от реализации, 16-32 байта кажись. Исследования исходных кодов программ показывают что средний размер объекта составляет от 32 до 128 байт, при такких размерах оверхед является очень значительным.
Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь. Кроме того, в С++ принято мелкие объекты создавать на стеке. А если нужно в динамической памяти разместить объект, то есть placement new, который позволяет разместить объект в уже выделенной памяти.
G>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров.
Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики.
G>4)Алгоритм выделения памяти не потокобезопасный, требуется синхронизация.
GC тоже не потокобезопасный, и зачастую требует не просто синхронизации, но и приостановки работы потоков.
G>5)В программах на С++ часто делают свои аллокаторы, которые выделяют память для маленькиз объектов чтобы избежать описанно выше оверхеда как по потребляемой памяти, так и по времени этой операции
В С++ такое делают крайне-крайне редко. Потому что а) есть стэк; b) есть placement new; c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части;
G>Теперь о GC G>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю
Ага, аж десять раз. Это как бог на душу положит. Может и GC запуститься с полной остановкой всех потоков. Веселуха... G>7)Оверхед по выделяемой памяти равен 8 байтам на 32-битной платформе (может ошибаюсь немного, лень смотреть)
уже писал про мелкие объекты и про то, что общий оверхед памяти для .net программ хорошо больше цэпэпэ. G>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна.
в c# выделение памяти не более потокобезопасно, чем в с++ G>9)такое распределение памяти увелиичивает cache-locality
стандартные аллокаторы windows тоже оптимизированы на это дело G>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении
по сути это и означает, что когда захочется, особенно если речь идет о более-менее больших системах G>11)Для нулевого поколения объем памяти — пара сотен КБ, этот кусок очень хорошо ложится в кеш процессора.
пофиг, в С++ частое выделение/удаление мелких объектов стараются делать на стэке. G>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить. G>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь
это в общем-то самообман
PS
существенное преимущество GC — не надо следить за уничтожением объектов, что облегчает программирование, позволяет использовать всякие инетересные техники программирования, вроде замыканий. Но за эти удобства мы платим скоростью исполнения и большим расходом памяти. Вот собственно и все.
Здравствуйте, Игoрь, Вы писали:
G>>Маленький ликбез: G>>1)Стандартный аллокатор поддерживает связный список блоков памяти, выделение нового и освобождение блока вызывает проход по списку, который имеет алгоритмическое время O(n) от количества блоков. И>Ты сам в это веришь? Это наивная реализация 80-ых годов. Сейчас используются всякого рода оптимизации, позволяющие минимизировать время поиска и частично отказаться от блокировок кучи. Например, в windows heap создается, если мне память не изменяет, на одну кучу 128 ассоциативных однонаправленных списков, не требующих блокировок.
Эта наивная реализация во многих местах осталась и по сей день.
G>>При постоянных выделениях-освобождениях памяти получются очень большие затраты на эту простую операцию. И>В С# в целом та же херня.
Доказательства? Может сначала статью про .NETовский JIT прочитаете. На этом сайте статьи есть.
G>>2)При выделении блока идет небольшой оверхед, который зависит от реализации, 16-32 байта кажись. Исследования исходных кодов программ показывают что средний размер объекта составляет от 32 до 128 байт, при такких размерах оверхед является очень значительным. И>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит.
Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
И>Кроме того, в С++ принято мелкие объекты создавать на стеке. А если нужно в динамической памяти разместить объект, то есть placement new, который позволяет разместить объект в уже выделенной памяти.
Ага, это все увеличивает энтропию языка, то есть количество свпособов сделать одно и тоже по-разному.
G>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики.
Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
Про мемори лики хочу узнать поподробнее, как их получить, потом сравните это с простотой получчения лика в unamanged коде.
G>>4)Алгоритм выделения памяти не потокобезопасный, требуется синхронизация. И>GC тоже не потокобезопасный, и зачастую требует не просто синхронизации, но и приостановки работы потоков.
Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
G>>5)В программах на С++ часто делают свои аллокаторы, которые выделяют память для маленькиз объектов чтобы избежать описанно выше оверхеда как по потребляемой памяти, так и по времени этой операции И>В С++ такое делают крайне-крайне редко. Потому что И>а) есть стэк;
Стек заставляет копировать объекты чаще, чем нужно.
И>b) есть placement new;
Теже яйца что и кастомный аллокатор, только сбоку
И>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части;
Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
G>>Теперь о GC G>>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю И>Ага, аж десять раз. Это как бог на душу положит. Может и GC запуститься с полной остановкой всех потоков. Веселуха...
Читайте как работает GC, он не может просто так взять и запуститься.
G>>7)Оверхед по выделяемой памяти равен 8 байтам на 32-битной платформе (может ошибаюсь немного, лень смотреть) И>уже писал про мелкие объекты и про то, что общий оверхед памяти для .net программ хорошо больше цэпэпэ.
А вы вообще ветку читали перед тем как это постить?
G>>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна. И>в c# выделение памяти не более потокобезопасно, чем в с++
Полный бред.
G>>9)такое распределение памяти увелиичивает cache-locality И>стандартные аллокаторы windows тоже оптимизированы на это дело
Рад за аллокатор Windows, только зачем он нужен если можно выделять память смещением указателя. Быстрее просто нечего придумать.
G>>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении И>по сути это и означает, что когда захочется, особенно если речь идет о более-менее больших системах
И че? сборка памяти в нулевом поколении работает быстре чем использование алоокатора на списках при выделении-освобождении того же объема памяти.
G>>11)Для нулевого поколения объем памяти — пара сотен КБ, этот кусок очень хорошо ложится в кеш процессора. И>пофиг, в С++ частое выделение/удаление мелких объектов стараются делать на стэке.
Ну и пусть стараются.
G>>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить. G>>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь И>это в общем-то самообман
Самообман — думать что C++ всегда быстрее.
И>PS И>существенное преимущество GC — не надо следить за уничтожением объектов, что облегчает программирование, позволяет использовать всякие инетересные техники программирования, вроде замыканий. Но за эти удобства мы платим скоростью исполнения и большим расходом памяти. Вот собственно и все.
Тесты будут? Или вы тоже омновываете свое мнение на просмотре пары говнопрограмм?
Здравствуйте, hattab, Вы писали:
H>Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным. http://www.rsdn.ru/article/dotnet/GC.xml
H>>>>>Размеры, и правда можно из метаданных получать, заплатив перформансом G>>>>С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).
H>>>Ты же сам про процессорный кэш упоминал... Забыл? G>>Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается. H>Ты посмотри, как этот редкий процесс накручивает счетчик, когда ты мышкой водишь над кнопками на тулбаре.
Накручивает до определенной степени, потом переставет.
H>К тому же не забывай, я давал пример, когда на один вызод метода по XML-RPC происходит 3 сборки мусора. Не веришь мне, проверь сам.
Не надо в пример приводить какую-то левую либу.
G>>Стандартный аллокатор тоже неспособствует частому попаданию в кеш при выделении относительно неболишах блоков, причем эффект проявляется при каждом выделении-освобождении. H>Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету.
"мотаться" — громко сказано, это пара ассемблерных команд. Стандартному аллокатору чтобы поместить свободный блок в список приходится мотаться.
H>>>>>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера: H>>>>>
Как видите, сбор мусора вызывает существенное снижение производительно-
H>>>>>сти — это основной недостаток управляемой кучи.
G>>>>Только это все может работать быстрее, чем аллокатор на основе списков. H>>> Рихтер не авторит, да? G>>А причем тут авторитет? Это результатами тестов подтверждается. H>Так Рихтер и говорит, что управляемая куча это есть потеря перформанса. Впрочем, я уже понял, что твою слепую веру ничто не способно поколебать.
Слепая вера и невежество у тебя. http://www.rsdn.ru/forum/Default.aspx?mid=3164491
H>>>>>Там есть Private bytes. G>>>>И че? H>>>Это реальный показатель: H>>>
Private Bytes represents the amount of private virtual memory a process has allocated and is the value that will rise of a process exhibiting a memory leak bug.
G>>Такой же эфимерный показательнь для GC. H> При чем тут GC? Это показатель реально используемого/выделенного (не зарезервированного) объема, хоть с GC, хоть без GC
Что значит "реально используемого", ты ведь понимаешь что это далеко не тоже самое что "выделенного", GC нет смысла релизить память первых двух поколений, даже если она не используется. Метаданные в памяти также используются далеко не всегда, несмотря на то что память под них выделлена.
Неиспользуемые страницы могут долго находится в памяти, пока память не понадобится другим приложениям.
Здравствуйте, hattab, Вы писали:
G>>>>При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET H>>>Это ты вероятно с Paint.Net спутал В нем действительно, при выделении (Magic Wand) изображения на картинке 400x647 начинаются тормоза: загрузка CPU в районе 100%, частота подскакивает до своего максимума в 1700MHz. PhotoFiltre при этом спокойно работает на минимуме в 600MHz не нагружая процессор выше 8%. G>>Я проверил на одинаковых картинках, жрет процессор одинаково, но у PhotoFiltre при этом торможит интерфейс
H>Я тоже проверил на одинаковых, и результат изложил выше, а посему позволь тебе не поверить.
У тебя видимо плохая карма что все .NET программы тормозят.
G>>>>>При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET H>>>>Это ты вероятно с Paint.Net спутал В нем действительно, при выделении (Magic Wand) изображения на картинке 400x647 начинаются тормоза: загрузка CPU в районе 100%, частота подскакивает до своего максимума в 1700MHz. PhotoFiltre при этом спокойно работает на минимуме в 600MHz не нагружая процессор выше 8%. G>>>Я проверил на одинаковых картинках, жрет процессор одинаково, но у PhotoFiltre при этом торможит интерфейс
H>>Я тоже проверил на одинаковых, и результат изложил выше, а посему позволь тебе не поверить. G>У тебя видимо плохая карма что все .NET программы тормозят.
Вообще по тихому, ни сообщений, ни записей в евентлоге. Windows XP SP3.
Рихтер не авторит, да?
