Здравствуйте, _d_m_, Вы писали: ___>Он не "основан на предположении о том", а просто лучше подходит для таких случаев. А как и все алгоритмы сжатия с потерями основан на том что: любую ф-цию (даже и произвольную кривую и прямоугольные колебания) можно представить набором синусоид (гармоник).
Это упрощенное представление. "Алгоритмы сжатия с потерями" основаны не только на гармоническом разложении. Единственное, что можно с уверенностью сказать обо всех алгоритмах сжатия с потерями — это то, что они все пытаются игнорировать малосущественные подробности. Критерий малосущественности выбирается разработчиком алгоритма.
Кстати, как известно с 18 века, вовсе не любую функцию можно представить конечным набором гармоник. Функция с разрывами потребует бесконечно большого количества гармоник. Для интересующихся см. "явление Гиббса". Именно оно отвечает за грязь вокруг текста даже при максимальном качестве пожатия джпегом. ___>И чем больше степень сжатия, тем больше высших гармоник мы убираем, тем грубее приближение полученой суперпозиции оставшихся гармоник. Резкие границы как-раз представляют пример прямоугольного колебания, а в этом случае для более точного приближения результирующей кривой к исходной необходимы как раз высшие гармоники. ___>Для интересующихся см. раздел высшей математики "Ряды Фурье". Раздел этот появился еще задолго до jpeg-ов и алгоритмов сжатия, в 18 веке вроде.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Так вот, допуская гипотетическую возможность сущестования программы, которая управляет объемом занимаемой памяти в зависимости от общего доступного объема оной, мы приходим к интерестному вопросу.
А именно — какого рожна ты все время всем тыкаешь своими книгами по win32, если такую программу можно написать вообще под любую (вменяемую) OS включая DOS, хотя там это и бесполезно?
Ну а дальше для понимания сути дела остается ма-а-аленький такой шажок. Нужно всего-навсего понять, что именно этим (управлением занятой памятью) управляемая куча и занимается.
Здравствуйте, mrozov, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
M>Веришь ли ты в существование программы, которая выделит себе память... скажем в виде массива цифр от 0 до 10 количеством в 100МБ?
Да
M>Веришь ли ты в существование программы, которая в какой-то момент (скажем по таймеру) освободит половину этой памяти?
Да.
Только одно замечание — освободит коммитированную память в своем процессе. А не страницы ОП в системе. Вот этого ты никак не можешь понять А это совершенно разные вещи.
M>Если нет — ну... может мне и в самом деле стоит освежить свои знания ОС...
Именно.
>да и вообще сменить профессию.
Нет, не обязательно. просто почитать хорошие книги.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ie, Вы писали:
ie>>А почему?! S>Более точное объяснение: формат JPEG применяет сжатие с потерями. Он основан на предположении о том, что в изображении много плавных переходов и мало резких. Поэтому при сжатии "теряется" как раз информация о резких границах. Визуально это проявляется как грязь вокруг таких границ. Чем больше таких резких переходов — тем ниже коэффициент сжатия и тем хуже конечный результат. Хуже всего — черный текст на белом фоне. S>GIF оптимизирован под большие площади, залитые одинаковым цветом, а также под изображения с малым количеством использованных цветов.
Совершенно верно. Только одно замечание — а не все ли равно в применении к тому скриншоту, который я сделал ? Ей-богу, правильная передача полутонов меня в от момент мало волновала
PD>Только одно замечание — освободит коммитированную память в своем процессе. А не страницы ОП в системе. Вот этого ты никак не можешь понять А это совершенно разные вещи.
Во всем этом форуме нет наверное ни одного человека, который бы этого не понимал. Это очевидно. Но ты единственный, кто понимает, при чем тут это! Ну давай я теперь буду тебе тыкать, что ты не понимаешь, что никаких страниц вообще нет, а есть только электрические импульсы???
Здравствуйте, mrozov, Вы писали:
M>Во всем этом форуме нет наверное ни одного человека, который бы этого не понимал. Это очевидно. Но ты единственный, кто понимает, при чем тут это!
Еще и авторы выпущенного под эгидой Микрософт книги по внутренненму устройству Windows. Они понимают именно то, о чем я пишу, потому что я их высказывания и озвучиваю — сам я Windows не дизассемблировал. Правда, в этоим форуме они не участвуют, но им я как-то доверяю больше, чем всем участникам этого форума — в таких вопросах
Здравствуйте, kedik, Вы писали:
K>А как процесс Дотнета узнает что в системе ресурсов нехватает (память в данном случае)? Есть информация или хотя бы идеи по поводу как это происходит?
Из книги "Customizing .NET Framework Common Language Runtime", глава 13.Managing How the CLR Uses Memory (см выделенное жирным):
If you need to constrain or otherwise customize how the CLR uses memory, use the CLR hosting API to implement a memory manager. Implementing a memory manager enables you to customize the following aspects of how memory is managed in your process:
Virtual memory management
Heap management
File mapping functions
Reporting the current memory load to the CLR
These capabilities are provided by the three interfaces that make up a memory manager: IHostMemoryManager, IHostMalloc, and ICLRMemoryNotificationCallback. As the primary interface in the hosting manager, IHostMemoryManager is the interface the CLR asks the host for during initialization. The CLR determines whether a host implements the memory manager by passing the IID for IHostMemoryManager to the GetHostManager method of the host's implementation of IHostControl. (Refer to Chapter 2 for a complete description of how the CLR determines which managers a particular host implements.)
The equivalent of the Win32 GlobalMemoryStatus API is the GetMemoryLoad method on IHostMemoryManager. The CLR will call GetMemoryLoad periodically to determine the memory load on the system from the host's perspective. The host returns two values from GetMemoryLoad, as shown in the following definition from mscoree.idl:
The first parameter, pMemoryLoad, is the percentage of physical memory that is currently in use. This parameter is equivalent to the dwMemoryLoad field of the MEMORYSTATUS structure returned from GlobalMemoryStatus. The pAvailableBytes parameter is the number of bytes that are currently available for the CLR to use.
The exact behavior of the CLR in response to the values returned from GetMemoryLoad isn't defined and is likely to change between releases. That is, returning specific values doesn't guarantee that a specific amount of memory will be freed or even that a garbage collection will be done immediately. All that is guaranteed is that the CLR considers the values returned from GetMemoryLoad when determining the timing of the next garbage collection.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[14]: Память и .Net
От:
Аноним
Дата:
28.05.06 09:25
Оценка:
Здравствуйте, VladD2, Вы писали:
L>>Зиг хайль.
VD>Уже 60 лет как Гитлер капут.
С большим интересом прочитал топик от корки до корки. Понял, что тут такие кульные ребята, и дотнет они знают от и до, и неинтересно им это уже, а интересно друг на друга собак спускать и крестовые походы устраивать с битием камнями и тухлыми помидорами.
Ну, а поскольку заявленная тема уж больно близка к моей маленькой проблемке, подумалось: может они между делом и помогут с решением.
А вопрос простой: для ехе всегда можно установить зарезервированный размер хипа и стэка и таким образом получить сколько нужно непрерывного адресного пространства, в java машине тоже можно указать для приложения min max (managed) heap size. А вот в дотнет это как минимум нетривиально. Уверждается, что нужно использовать SetGCHostControl из интерфейса ICorConfiguration. А как сделать это практически? Писать своего хоста?
Только не надо меня .... того ... помидорами
Пожалуйста.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали: A>Супер, Павел, просто супер. Но до здравого смысла этих людей пробиться сложно. Упорные они. Я пытался. Мало что выходит:
Вообще, почитав посты этой темы, у меня сложилось впечатление о некоем противостоянии двух лагерей. В обоих лагерях участники имеют нешуточное представление как об внутренних механизмах ОС так и о языках прогр. Оба лагеря знают, что раньше все прогр.-мы сначала скромно перекусывали потом стали аккуратно есть а теперь просто жрут. Также все представляют (покрайней мере, я — в общих чертах) как наша любимая хрюша все это дело кормит, тобишь как распределяет рес. памяти. Кстати, может тут будут и смеяцца, но мне лично этот принцип распределения напоминает работу нашего мозга, так что если ктото досих пор недолюбливает работоспособность поделок от дяди билли, то эээ... интересно, как вы сами ссобой уживаетесь?
Ладно. Едем дальше..
В итоге все в курсе всего. Но тут возник вопрос. И началось... Одна умная голова заявила, что это, мол, хрюша пашутила и все насамом деле наместе — вот вам на суд рез-ты исследований. Другая голова поглядела и недоуменно возразила, что, мол, ОС шутить отродясь неумела и со времен рождества христова в соответсвующей божественной манере она отдавала всем кто нипопросит и столько, сколько никто не унесет. А чтО там несчатная приблуда будет делать дальше с сиими дарами операционным это ее проблеммы. Все подкреплено фактами и Все с этим согласны. Ладно хоть более темная и неграмотная часть жителей средиземья и севера, в рез-те этой перепалки стала лучше понимать хитрую ситему накормления семью хлебами и приобрела не менее хитрое знание о захапывании и делении. Дааа.. однозначно любимыми мат. операциями человека, сотворившего GC были операции отнимания и деления. Но мир никак нибрал стороны и идет пережовывание как разных, так и одних и техже фактов, цитат и тд., причем, хорошо известных обоим сторонам. И я никак немог ухватить вчем именно расходяцца ваши взгляды. Со стороны диалог сторон напоминает одну современную басню о покупке гопником чего-то там у глуховатой бабушки, торгующей картошкой —
"Да ты, бабка глухааяя!". "Чтоо?! Ааа! Да, сынок! Есть и гнилая!"
Но вопреки присутствию щедрого директора и жадного приложения в одной клетке, долгожданный всеми крах от их сожительства ненаступает. Сисадмины насторожены — Хрюша им в стук-листе рисует факт пропажи 40мб. Баггер-дамп-разведка подтверждает. "Блин!" — думают они, если все кодеры переберуцца на шарп и буду там такие жирные плюшки клепать, то блин, унас такой жор начнецца, что все демоны попадают. Так вам глядишь и самим писАть придецца.
А кодеры врасслабухе — "Пацаны в редмонде нашинские, тапочки курят такие же как и мы". А дядя Билии ваще наш старший брат. Блин, чесслово, мой старший брат так обомне не заботицца как дядя Билли. Меня например ваабще перестало интересовать, скролько шарп-проги стали жрать.
После прихода GC истиной так и остаецца простая зависимость производительности программы от кол-ва лишневыделенной оперативки. Так что мы свою шарп-глюкалу полностью понимаем и знаем зачем ей столько и куда. И даже недумайте наши законные два гектара маны отнимать. Посидите с наше на смещениях да на параграфах и потом машите выдержками и цитатами. А этому бедному, замордованному злобными сисадминами Артему и его команде могу сказать, что можете смело идти, переходить, садицца и радовацца. А если там какой нить больно великий админ начнет плакать, мол, из-за вашего творения у нас порнодум-10 притармаживает, сотвори ему теже 10 тыс. обращений на серв с логина, без отсоединенного кэша. Вместе с пулом пусть там накроюцца. Скажете, "у вас кабель узкий". Ато блин дайте нам стабильность, скорость, безопасность и чтоб само все набиралось, а сама БД и СУБД помещались на дискетку (вместе с сотней ихних любимых порнотелок).
Непонятно зачем вааще мелкие расказали о GC. Надо было им лишь отметить, что памяти в этом языке, даже как понятия, нету и спрашиват об этом всеравно что спрашивать об НЛО — откуда они приходят и куда улетают. Все чем занимаюцца в шарпе это манипулируют как готовыми обжектамим так и своими. А на ныряния во внутренности GC со стороны штаба админов можно сказать только то, что занятие это для них напрасное и бессмысленное если они еще не пытались заняцца проблемой автоуказателей. В процессе решения этой проблеммы вопрос "куда все пропало?" раскрываецца сам собой на базовом уровне точно также как и перед создателем первого парового двигателя открылся бы секрет движения нового баяна. А вы как бугалтера-колхозники: "По накладной под капотом должно быть сорок лошадей. Вытаскивайте их оттуда по одной — унас инвентаризация." И что вам на это ответить? Только одно — ложки несуществует.
Здравствуйте, TK, Вы писали:
TK>Hello, "_Artem_" >> >> И вообще нормально ли что .Net столько отъедает?
TK>А оно нормально 10000 записей в памяти держать? В остальном, надо учитывать TK>то, что сборка мусора выполняется в моменты когда это необходимо. Кроме TK>этого, надо учитывать то, как именно считается объем занимаемой памяти. TK>Значение в 40Mb совершенно не означает, что это именно физическая память.
Добавлю, что 40МБ также не означает что память эта выделена приложением, память может просто выделяться про запас и для более оптимального использования CLR'ом. При этом если приложение запросит несколько метров памяти, то размер занимаемой памяти может даже и уменьшится с 40 до 30 МБ.
Память выделяется про запас для того чтобы была проводить более эфективное по скорости выделение небольших блоков памяти (десятки килобайт). Кроме того резервное выделение памяти дает возможность CLR использовать память более эффективно с точки зрения фрагментации.
Таким образом, если Task Manager показывает 40 МБ для дотнетного приложения, это означает что приложение либо вообще не использует память либо использует не более 10-20 МБ... Остальное выделяется в целях оптимизации производительности и со временем (если не будет затребована приложением или если у системы начнет заканчиваться память) будет освобождена.
Здравствуйте, winmike, Вы писали:
W>Здравствуйте, _Artem_, Вы писали:
W>.Net сьедает сколько ему "позволят". Куда ушли 40 МБ можно посмотреть например при помощи CLRprofiler или SOS.DLL + debugger
чтобы не плодить топики на столь популярную тему, хочу спросить такую вещь:
В приложении подтекает память. Выглядит это следующим образом:
1) Формы (а может не только они, просто на на них это лучше видно) становятся в очередь на финализацию и не умирают без волшебных вызовов
Здравствуйте, <Аноним>, Вы писали:
А>2) Часть объектов продолжает висеть в очереди на финализацию. При чем ссылки на них держат не какие-то объекты, а события. А>как это можно интерпретировать?
Так, что нужно отписывать умирающие объекты от событий явно. Можно также погуглить по словам Weak Delegate насчет автоматических решений этой проблемы.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IceG, Вы писали:
IG>Отличный топик получился! Не поленился — прочитал все!
IG>1. Спасибо за то, что хорошо подискутировали на тему памяти — многое для себя устаканил в голове.
Вот только не понятно, кто прав а кто нет, кого слушать .
1.1.4 stable rev. 510
