Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Рихтер: H>>>
У каждого объекта есть пара таких полей: указатель на
H>>>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>>>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>>>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>>>по 16 байт
H>>>Это оверхед не аллокатора, а организации данных. Но тем не менее. G>>указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.
H>Аллокатору нужны списки блоков? Нужны. Нужны размеры блоков? Нужны. Эти вещи, используемые любым аллокатором, считать оверхедом нельзя. Считать оверхедом можно большее, нежели было запрошено, выделение памяти, что присутствует в приведенном в качестве примера дельфийском менеджере (но учитывая эффективность пулов, этот оверхед обсуждать смешно).
Еще раз, в .NETовском аллокаторе не нужны ни списке блоков, ни размеры. (размеры есть в метаданных)
G>>>>Оверхед может возникнуть из-за того что создается больше обеъктов, но это уже зависит от программы, а не от аллокатора. H>>>На практике мы видим, что .Net софт потребляет больше нежели нативный со всеми его пулами. Это позволяет говорить о том, что вся инфраструктура управления памятью в .Net имеет больший оверхед нежели в нативном софте. G>>Большее потребление памяти вовсе не означает оверхеда аллокатора или какой-то-там "ифнраструктуры управления памятью".
H>Я и не говорю про оверхед аллокатора, я конкретно указал о каком оверхеде идет речь.
Только этот оверхед не влияет на производительность.
Вы же не боспокоетесь так исльно из-за лишнего дестяка мегабайт.
Я больше чем уверен что вы спокойное кешируете в памяти множество данных, получаемых извне.
H>К слову сказать, в Delphi я могу, при желании, создать объект и на стеке, только чаще всего необходимости в этом нет.
Каким образом?
Кстати при отсутствии необходимости создавать объекты на стеке многие С++ники часто ргугают другие языки из-за отсуствия такой возможности.
G>>В C++ большая часть короткоживущих объектов создается на стеке. G>>Кроме того для работы аллокаторы .NET необходимы непрерывные куски памяти, а это требует резервирования и выделегния большего объема оперативной памяти, чем реально испольхуется программой (это к тому что не надо верить цифирке в Task Manager). G>>Причем все эти особенности выделения паяти в .NET только ускоряют работу.
H>Во-первых, я не мониторю TaskManager'ом, а использую ProcessExplorer (там цифирки более другие )
Другие это какие?
Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени.
H>Во-вторых, в Delphi менеджер памяти тоже предварительно создает пулы (в текущей версии в количестве 55(!) штук. Общая эффективность использования пулов для 12000 различных объектов составляет ~95% (это показания трекинга)), но при этом перерасхода памяти не наблюдается. В-третьих, под задачу можно аллокатор поменять (существуют и комммерческие и бесплатные решения).
Ага, наши поезда самые поездатые поезда в мире.
G>>Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков. H>Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)?
Нативная программа использует GDI+ для этих целей?
Память там в основном жрет не .NET, а GDI+ (который тоже нативный).
Кроме того перечитайте еще раз мой пост о статическом оверхеде .NET, может тогда поймете почему не стоит сравнивать потребление памяти на программах типа HelloWorld
Здравствуйте, alsemm, Вы писали:
G>>>>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна. A>>>Конечно потокобезопасно, еще бы. Только потокобезопасность — не бесплатная. G>>Любая потокобезопасноть небесплатная, но пока быстрее intelokcedAdd не существует. A>Что-то мне кажется, что одним intelokcedAdd дело там не ограничивается.
Не вижу причин по которым нельзя ограничиться одним инкрементом.
A>>>Реальный недостаток GC — это его непредсказуемость. Эта сущность не управлется из клиентского кода никак. G>>Управляется: есть классы GC и GCSettings. только практика показывает что чем больше лезешь в ручное управление GC, тем хуже все работает. A>GCSettings нашел, GC — не нашел. Из того что нашел складывается ощущение, что толку от него, как от поводка для носорога. Да и не должно быть средств для управления нормальным GC, он незаметно для программы должен работать, а не выскакивать как бандит из подворотни
В предыдущем посте вы обвиняли что нету средств контроля GC, вам показали средства, а теперь говорите что он должен незаметно работать. Вы определитесь уже.
A>>>Она может проснуться когда посчитает нужным. G>>Он работает по строгому алгоритму, если вы не будете писать код, который завтавляет срабатывать GC очень часто, то все будет хорошо. A>Затачивать код под алгоритм GC? Полагаю, что это одного уровня сложности задача, как и настройка управления памтью в C++ проекте.
Как раз "затачивать" ничего не надо. Надо просто писать. Работа GC основана не на каких-то предположениях, а на вполне конкретных сатистических (выполняющихся для большенства программ) фактах. Поэтому когда вы пишите программу не сильно задумываясь о распределениипамяти получается лучше всего, а тонкие места можно отловить профайлером.
По моим наблюдениям самые неэффективные программы для .NET пишут именно те кто писал на оптимизированные программы на C++.
A>>>Если бы GC давал равномерную нагрузку на CPU, то никто бы от него не плевался. G>>Ага, его бы просто не использовали. A>А что есть выбор?
Вообще говоря да. Вот в этой теме как раз вопрос выбора.
G>>Странные у вас представления о CG. A>Расскажите как должно быть по вашему.
Меня устраивает так как сейчас есть. И я быб лы очень недоволен если бы работа GC давала постоянный тормозняк.
G>>Кстати описанный вами GC вполне можно сделать на C++, почему до сих пор не применяют? A>В С++ GC не нужен.
Я много раз видел как пишут аллокаторы, которые по свойствам похожы на GC, значит нужны всетаки.
A>>>К сожалению, имидж управляемых сред был сильно подпорчен первыми версиями Java. Так что вы тут хоть 1000 аргументов в пользу C# приведите, стереотипы забороть очень тяжело. G>>Меня стериотипы не итересуют уже давно. A>А зачем тогда, спрашивается, вы в этой ветке так активно участвуете?
Вот и пытаюсь разрушить стериотипы.
Ведь можно написать эффективную программу на Java/.NET, но некоторые почему-то свято верят что можно писать толко на С++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Хороший топик для потенциальных работодателей. Участников холивара можно смело на должности выше сеньора не брать
зря написал. теперь последует ещё на 28 страниц холивар о правильных работодателях
Здравствуйте, gandjustas, Вы писали:
G>В предыдущем посте вы обвиняли что нету средств контроля GC, вам показали средства, а теперь говорите что он должен незаметно работать. Вы определитесь уже.
В этом не противоречия. Либо GC должен быть так хорош, чтобы в не надо было ничего "подкручивать", либо, если, им все-таки можно и нужно управлять должны быть для этого адекватные средства.
... G>>>Странные у вас представления о CG. A>>Расскажите как должно быть по вашему. G>Меня устраивает так как сейчас есть. И я быб лы очень недоволен если бы работа GC давала постоянный тормозняк.
Постоянный предсказуемый тормозняк это лучше чем неожиданный непредсказуемый тормозняк
G>>>Кстати описанный вами GC вполне можно сделать на C++, почему до сих пор не применяют? A>>В С++ GC не нужен. G>Я много раз видел как пишут аллокаторы, которые по свойствам похожы на GC, значит нужны всетаки.
... G>Вот и пытаюсь разрушить стериотипы. G>Ведь можно написать эффективную программу на Java/.NET, но некоторые почему-то свято верят что можно писать толко на С++.
Живая эффективная программа на Java/.NET быстро порушит стереотипы. Где такую можно посмотреть?
Здравствуйте, alsemm, Вы писали:
G>>>>Странные у вас представления о CG. A>>>Расскажите как должно быть по вашему. G>>Меня устраивает так как сейчас есть. И я быб лы очень недоволен если бы работа GC давала постоянный тормозняк. A>Постоянный предсказуемый тормозняк это лучше чем неожиданный непредсказуемый тормозняк
В том то и дело что в случае .NET тормозняк очень даже предсказуем и легко сделать так чтобы он не мешал.
G>>>>Кстати описанный вами GC вполне можно сделать на C++, почему до сих пор не применяют? A>>>В С++ GC не нужен. G>>Я много раз видел как пишут аллокаторы, которые по свойствам похожы на GC, значит нужны всетаки. A>... G>>Вот и пытаюсь разрушить стериотипы. G>>Ведь можно написать эффективную программу на Java/.NET, но некоторые почему-то свято верят что можно писать толко на С++. A>Живая эффективная программа на Java/.NET быстро порушит стереотипы. Где такую можно посмотреть?
Не порушит, потому что сравнивать не с чем.
Возьмите Paint.NET — на многих задачах работает быстрее фотошопа, но это разные весовые категории.
Можете посмотреть Windows Live Writer, но анлогов вообще нет, Windows Media Center — аналогично.
Autocad 2009 можно сравнить только с предыдущей версией, но бессмысленно это.
Вот еще и студия 2010, которая у меня на виртуалке работает также резво, как студия 2008 на компе.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, niellune, Вы писали:
AVK>Хороший топик для потенциальных работодателей. Участников холивара можно смело на должности выше сеньора не брать
О, спасибо, пополнит мою коллекцию:
Писали ли вы в резюме "C/C++" через слеш?
Придерживаетесь ли вы code-style ядра виндовс?
Знаете формулу площади круга?
Ваше резюме помещается на одну страницу?
Ваше резюме не помещается на одну страницу?
Разберетесь с фиговиой а-ля // wtf????\ etc. ?
Разберетесь с фиговиной а-ля :> etc. ?
Имеете ли опыт работы в аутсорсе?
Отписывались ли вы на рсдн в форуме "О работе" в топике "Работа — с чего начать: С++ или С#?"
Гуй в нем делался на скорую руку бо сильно нужны были результаты замеров.
вкратце основные кнопы:
+- — зум
курсорные стрелки + ins/del — перемещение.
В силу особенностей перехвата работает не до абсолютной смерти проги, отключается несколько раньше, но позже завершения main.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
ГВ>>Меняется не столько сам C++, сколько его реализация. Не одно и то же, однако. G>Ну и в чем различия?
Скажи пожалуйста, ты правда не понимаешь разницу между стандартом ANSI и реализацией стандарта тем или иным компилятором? Или просто хочешь развести меня на очередной виток объяснения очевидных вещей?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Меняется не столько сам C++, сколько его реализация. Не одно и то же, однако. G>>Ну и в чем различия?
ГВ>Скажи пожалуйста, ты правда не понимаешь разницу между стандартом ANSI и реализацией стандарта тем или иным компилятором? Или просто хочешь развести меня на очередной виток объяснения очевидных вещей?
Меня не это интересует.
Меня интересует чем отличается "сам язык" (не его стандарт) от реализации этого языка в конкретном компиляторе.
Все программисты на C++ знают что стандартный C++ это далеко не тот C++ на котором пишут программы. Так что в этом контексте "сам язык"?
Здравствуйте, gandjustas, Вы писали:
G>Можете посмотреть Windows Live Writer, но анлогов вообще нет, Windows Media Center — аналогично.
Совершенно верно, аналогов этому, гхм, и правда нет.
Здравствуйте, gandjustas, Вы писали:
G>Меня интересует чем отличается "сам язык" (не его стандарт) от реализации этого языка в конкретном компиляторе.
Неправильно ставишь вопрос: "сам язык" от стандарта не отличается. Стандарт (в виде документа) для того и нужен, вообще говоря, чтобы зафиксировать определение языка.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
H>>>>Это оверхед не аллокатора, а организации данных. Но тем не менее. G>>>указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.
H>>Аллокатору нужны списки блоков? Нужны. Нужны размеры блоков? Нужны. Эти вещи, используемые любым аллокатором, считать оверхедом нельзя. Считать оверхедом можно большее, нежели было запрошено, выделение памяти, что присутствует в приведенном в качестве примера дельфийском менеджере (но учитывая эффективность пулов, этот оверхед обсуждать смешно). G>Еще раз, в .NETовском аллокаторе не нужны ни списке блоков, ни размеры. (размеры есть в метаданных)
Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении). Размеры, и правда можно из метаданных получать, заплатив перформансом
H>>Я и не говорю про оверхед аллокатора, я конкретно указал о каком оверхеде идет речь. G>Только этот оверхед не влияет на производительность. G>Вы же не боспокоетесь так исльно из-за лишнего дестяка мегабайт.
Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера:
Как видите, сбор мусора вызывает существенное снижение производительно-
сти — это основной недостаток управляемой кучи.
G>Я больше чем уверен что вы спокойное кешируете в памяти множество данных, получаемых извне.
По требованию алгоритма, но не аллокатора
H>>К слову сказать, в Delphi я могу, при желании, создать объект и на стеке, только чаще всего необходимости в этом нет. G>Каким образом?
TObject.InitInstance. Только нужно понимать, что объект для подобного использования должен быть специально подготовлен, ибо нет смысла размещать на стеке объект имеющий поля требующие динамического выделения памяти. Но сделать это можно. А с 2005 так вообще можно использовать advanced-records (структуры с методами/свойствами, class-like в общем).
G>Кстати при отсутствии необходимости создавать объекты на стеке многие С++ники часто ргугают другие языки из-за отсуствия такой возможности.
Ну на стеке быстрее, просто...
G>>>В C++ большая часть короткоживущих объектов создается на стеке. G>>>Кроме того для работы аллокаторы .NET необходимы непрерывные куски памяти, а это требует резервирования и выделегния большего объема оперативной памяти, чем реально испольхуется программой (это к тому что не надо верить цифирке в Task Manager). G>>>Причем все эти особенности выделения паяти в .NET только ускоряют работу.
H>>Во-первых, я не мониторю TaskManager'ом, а использую ProcessExplorer (там цифирки более другие ) G>Другие это какие? G>Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени.
Там есть Private bytes.
H>>Во-вторых, в Delphi менеджер памяти тоже предварительно создает пулы (в текущей версии в количестве 55(!) штук. Общая эффективность использования пулов для 12000 различных объектов составляет ~95% (это показания трекинга)), но при этом перерасхода памяти не наблюдается. В-третьих, под задачу можно аллокатор поменять (существуют и комммерческие и бесплатные решения). G>Ага, наши поезда самые поездатые поезда в мире.
Большое количество пулов это: 1) Быстрая аллокация т.к. по размеру блока моментально вычисляется "идеальный" пул. 2) В мульти-тредовом софте большое количество пулов снижает вероятность возникновения коллизий на локах. 3) В мульти-треде аллокатор не висит тупо на локе, а если не смог получить доступ к "идеальному пулу" делает три попытки получить блок из следующего (+1, +2, +3) пула, если снова не смог процесс повторяется.
Я описал то, что есть в наличии FastMM используется и в C++ Builder'е кстати
G>>>Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков. H>>Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)? G>Нативная программа использует GDI+ для этих целей? G>Память там в основном жрет не .NET, а GDI+ (который тоже нативный).
Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается.
G>Кроме того перечитайте еще раз мой пост о статическом оверхеде .NET, может тогда поймете почему не стоит сравнивать потребление памяти на программах типа HelloWorld
Это далеко не HelloWorld. Впрочем, сравнивать все равно, что. У .Net, расход на аналогичных вещах выше, такова объективная реальность.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Это оверхед не аллокатора, а организации данных. Но тем не менее. G>>>>указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.
H>>>Аллокатору нужны списки блоков? Нужны. Нужны размеры блоков? Нужны. Эти вещи, используемые любым аллокатором, считать оверхедом нельзя. Считать оверхедом можно большее, нежели было запрошено, выделение памяти, что присутствует в приведенном в качестве примера дельфийском менеджере (но учитывая эффективность пулов, этот оверхед обсуждать смешно). G>>Еще раз, в .NETовском аллокаторе не нужны ни списке блоков, ни размеры. (размеры есть в метаданных)
H>Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении).
Вы бы разобрались что скрывается под словами "строит граф", обычный рекурсивный обход без построения динамических структур.
Оверхеда там действительно нет, как бы вам не хотелось обратного.
H>Размеры, и правда можно из метаданных получать, заплатив перформансом
С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).
H>>>Я и не говорю про оверхед аллокатора, я конкретно указал о каком оверхеде идет речь. G>>Только этот оверхед не влияет на производительность. G>>Вы же не боспокоетесь так исльно из-за лишнего дестяка мегабайт.
H>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера: H>
Как видите, сбор мусора вызывает существенное снижение производительно-
H>сти — это основной недостаток управляемой кучи.
Только это все может работать быстрее, чем аллокатор на основе списков.
G>>Я больше чем уверен что вы спокойное кешируете в памяти множество данных, получаемых извне. H>По требованию алгоритма, но не аллокатора
А какая разница?
G>>Кстати при отсутствии необходимости создавать объекты на стеке многие С++ники часто ргугают другие языки из-за отсуствия такой возможности. H>Ну на стеке быстрее, просто...
Не всегда, размещение объектов на стеке часто приводит к копированию этих объектов когда не надо.
Для выпрямления такой ситуации в C++ есть ссылки — безопасный, но ограниченный в возможностях аналог указателей.
G>>Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени. H>Там есть Private bytes.
И че?
G>>>>Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков. H>>>Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)? G>>Нативная программа использует GDI+ для этих целей? G>>Память там в основном жрет не .NET, а GDI+ (который тоже нативный).
H>Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается.
Меня измерения потребляемой памяти на HelloWorld не интересуют.
G>>Кроме того перечитайте еще раз мой пост о статическом оверхеде .NET, может тогда поймете почему не стоит сравнивать потребление памяти на программах типа HelloWorld H>Это далеко не HelloWorld. Впрочем, сравнивать все равно, что. У .Net, расход на аналогичных вещах выше, такова объективная реальность.
Да как раз не все равно. Ты перечитай еще раз о чем я тебе толкую. .NET поребляет больше памяти на практически константную величину. Истории о том что кто-то запустил программу на .NET и она схавала сразу все свидетельствуют о криворукости автора программы, а не об особенностях работы с памятью в .NET.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Возьмите Paint.NET — на многих задачах работает быстрее фотошопа, но это разные весовые категории.
H>Дельфовый PhotoFiltre разрывает Paint.NET на куски
Скачал и поставил себе это.
Срзу узнал дельфовую программу. Дофига непонятных непермещаемых тулбаров. Дофига пунктов в меню, даже больше чем у фотошопа.
Сам такие интерфейсы ет пять назад плодил.
Нету возможности работы со слоями, нету визуально undo/redo stack. При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET
Очень порадовали диалоки без кнопок, которые еще и не дают кликать по вкладкам выдавая мессадж бокс.
Ну и из мелких придирок — нифига не подерживает vista style диалоги.
Дельфовый PhotoFiltre разрывает Paint.NET на куски только во сне.
Хотя памяти от захавал меньше в 2 раз — 20 мб, против 40 для Paint.NET, но с моими двумя гигами мне как-то пофиг.
Скорость работы — одинаковая.
G>>Можете посмотреть Windows Live Writer, но анлогов вообще нет H>Дельфовый BlogJet... Ну ты понял
Тока он платный, так что сразу в пролете.
Здравствуйте, gandjustas, Вы писали:
H>>Списки по любому нужны (т.е. GC все равно строит граф всех объектов в поколении). G>Вы бы разобрались что скрывается под словами "строит граф", обычный рекурсивный обход без построения динамических структур. G>Оверхеда там действительно нет, как бы вам не хотелось обратного.
Рихтер с тобой не согласен:
При компиляции IL-кода метода JIT-компилятор создает, помимо машинного
кода, внутреннюю таблицу. Логически каждая строка таблицы указывает диапа-
зон смещений байтов машинных кодов процессора, и адреса корней для каждого
диапазона (или регистра процессора)
Далее:
Начиная работу, сборщик предполагает, что все объекты в куче — мусор. Ина-
че говоря, он предполагает, что ни один из корней приложения не ссылается на
объекты в куче. Затем сборщик проходит по корням, строя граф всех достижи-
мых объектов. Например, он может найти глобальную переменную, указывающую
на объект в куче. На рис. 19-2 показана куча с несколькими объектами, где корни
приложения напрямую ссылаются на объекты А, С, D и F, Все эти объекты стано-
вятся частью графа. При добавлении объекта D сборщик замечает, что этот объект
ссылается на объект Н, добавляет объект Н к графу и продолжает рекурсивный
просмотр всех достижимых объектов.
Далее:
Завершив эту часть графа, сборщик мусора проверяет следующий корень и снова
проходит по объектам. Поскольку он проверяет объект за объектом, при попыт-
ке добавить к графу объект, уже добавленный ранее, он останавливается.
H>>Размеры, и правда можно из метаданных получать, заплатив перформансом G>С чего бы? Метаданные то в памяти лежат (это как раз лишние пара метров занимаемой памяти).
Ты же сам про процессорный кэш упоминал... Забыл?
H>>Ну, потребление само по себе может и не влиять в определенных ситуациях, зато на производительность не лучшим образом влияет сам GC. Строить граф нужно, кучу упаковывать иногда нужно (а это за собой влечет и модификацию указателей). В общем, чего я, вот тебе цитата из Рихтера: H>>
Как видите, сбор мусора вызывает существенное снижение производительно-
H>>сти — это основной недостаток управляемой кучи.
G>Только это все может работать быстрее, чем аллокатор на основе списков.
Рихтер не авторит, да?
G>>>Кстати при отсутствии необходимости создавать объекты на стеке многие С++ники часто ргугают другие языки из-за отсуствия такой возможности. H>>Ну на стеке быстрее, просто... G>Не всегда, размещение объектов на стеке часто приводит к копированию этих объектов когда не надо.
Я так понимаю, что мы говорим об адекватном использовании...
G>>>Вообще "объем памяти, занимаемый программой" очень эфимерная величина. Есть workset, есть commited memory, есть reserved memory, причем не один из этих параметров не показывает реальной величины используемой памяти в течение какого-то промежутка времени. H>>Там есть Private bytes. G>И че?
Это реальный показатель:
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>>>Нативная программа использует GDI+ для этих целей? G>>>Память там в основном жрет не .NET, а GDI+ (который тоже нативный).
H>>Не смеши. Не жрет GDI+ столько памяти. Более того, модель использования GDI+ отличается от GDI, требуя ресурсы (кисти и прочее) не накапливать, а создавать по мере необходимости. Я тебе могу выслать бинарник который рисует с использованием GDI+, так у него расход выше 4.1Mb не поднимается. G>Меня измерения потребляемой памяти на HelloWorld не интересуют.
Здравствуйте, gandjustas, Вы писали:
G>>>Возьмите Paint.NET — на многих задачах работает быстрее фотошопа, но это разные весовые категории.
H>>Дельфовый PhotoFiltre разрывает Paint.NET на куски G>Скачал и поставил себе это. G>Срзу узнал дельфовую программу. Дофига непонятных непермещаемых тулбаров. Дофига пунктов в меню, даже больше чем у фотошопа. G>Сам такие интерфейсы ет пять назад плодил.
Так и в Paint.NET тулбары не перемещаемые, во всяком случае у меня в 3.31.
G>Нету возможности работы со слоями, нету визуально undo/redo stack.
У меня версия от 2004 года, тут действительно нет, но есть PhotoFilter Studio, там слои есть.
G>При выделении с помощью magic wand изображение мелькает и начинает тормозить интерфейс, в отличие от Paint.NET
Это ты вероятно с Paint.Net спутал В нем действительно, при выделении (Magic Wand) изображения на картинке 400x647 начинаются тормоза: загрузка CPU в районе 100%, частота подскакивает до своего максимума в 1700MHz. PhotoFiltre при этом спокойно работает на минимуме в 600MHz не нагружая процессор выше 8%.
G>Дельфовый PhotoFiltre разрывает Paint.NET на куски только во сне. G>Хотя памяти от захавал меньше в 2 раз — 20 мб, против 40 для Paint.NET, но с моими двумя гигами мне как-то пофиг. G>Скорость работы — одинаковая.
Уж не надо про скорость заливать, PhotoFiltre летает заметно шустрее Paint.NET.
G>>>Можете посмотреть Windows Live Writer, но анлогов вообще нет H>>Дельфовый BlogJet... Ну ты понял G>Тока он платный, так что сразу в пролете.
Только он не единственный, этих блогопостилок вообще море, слабо сопоставляющееся со словами об отсутствии аналогов.
) 
