RAM Clear - «оптимизатор» памяти

Итак, перед вами программа-оптимизатор памяти.
Всё, что скрывается за этими словами: мифы и предубеждения, срывание покровов чего-то там и разоблачения смехотворных обещаний.
Ну и, конечно, очередной оптимизатор памяти, который не даёт возможности того, что обещают другие, он не гарантирует чудес... зато он обеспечивает то, чего другие не делают.

Внимание: пост содержит нарвалью дозу сарказма по поводу и без оного.



Сначала краткие характеристики самой программы, потом - разоблачения, спасибы и прочее-прочее.

Скриншот предоставил MisterGrim
​

o Размер оптимизируемой памяти - теоретически не ограничен. При этом оптимайзер - 32-х битное приложение. Т.е., он работает на любом компьютере, выполняющем Win32 ОС, и при этом поддерживает память любого размера даже на 32-х битных операционных системах с включённым PAE (например, WinXP). На x64 ОСях оптимизатор, естественно, также не имеет ограничений на размер оптимизируемой памяти.
ВНИМАНИЕ: оптимизация памяти, размером большей 1-1,5 ГБ требует переключения алгоритма работы программы в Расширенный режим. За сим деянием - читайте справку.
o Алгоритм имеет 3 уровня и 2 главных босса агрессивности, и может работать в довольно жёстком/мягком режиме, когда эффективность/быстрота очистки (т.н. "оптимизации", хи-хи) повышается.
o Оптимизатор имеет относительно небольшой размер (что делает его скачку на более-менее современных каналах вполне возможной) и достаточную производительность.
o Не требует инсталляции. Вообще ничего не требует. Только Win32 совместимую ОС, и кампутер, который может эту животину тянуть. Единственное требование к железу - видеосистема должна работать в HighColor-режиме (65536 цветов, 16 бит на пиксель). А то никрасива будет.
o В отличие от множества оптимайзеров с более-менее приятным внешним видом, этот оптимайзер не потребляет немереное количество ресурсов лишь для того, чтобы явить взору пользователя свой интерфейс. Нет, более того, потребляемая оптимайзером память (и вообще ресурсы) очень скромна по размерам. Также он имеет настройку, которая позволяет ему при простое в трее потреблять ещё меньше.
o Удобный, по-настоящему легко читаемый индикатор свободной памяти или прогресса оптимизации в трее. Цвет шрифта процентов свободной памяти - белый, когда идёт оптимизация - цвет шрифта процентов ультрамариновый. Также в подсказке к значку в трее показывается, собственно, свободный объём, а не только проценты. У значка в трее есть меню, отзывающееся на правокнопочный мышиный щёлк, из коего доступны основные и удобные команды.
o Так как оптимайзер поддерживает память любого размера, то все эти размеры отображаются и вводятся в удобном формате, аналогичном применённому в MemInfoMicro®.
o Программа тестировалась на Win95 OSR2, Win98(SE), Win2000, WinXP 32bit, Win 7 x64. Но при всём при этом Автор

Я, бишь

ничегошеньки не гарантирует и не несёт ответственности за что-либо произошедшее по вине правильного или неправильного использования его

Автора, бишь

оптимайзера, на всевозможных аппаратно-программных конфигурациях всяческих ЭВМ и прочих арифмометров. Автор лишь гарантирует, что программа не содержит злонамеренный шпионский или вредоносный код, и писалась с целями самыми мирными. А что вышло... судить вам
o Программа поддерживает мультиязычный интерфейс. Пока что, за незнанием языков, организованы целых два языка: русский культурный (ДЛЛина, что лежит с программой, плагин), и английский, тоже культурный в виду меру скромных познаний оного. Английский "вшит" в экзешник программы, и, кстати, категорически не рекомендуется править сам экзешник - программа станет неработоспособной с большооой долей вероятности. Для её локализации нужно лишь изготовить ресурсный ДЛЛ-плагин с переведёнными частями интерфейса. Язык определяется программой автоматически при запуске, в зависимости от настроек ОС.
o Ну, и этот оптимайзер халявный. Любой абсолютно бесплатно может охаять его с bottom edge до сааамой title bar.

Срываем покровы реклам

Любой опытный пользователь компьютера скептически относится к классу программ "Оптимизатор памяти". А всё потому, что большинство авторов оных оптимайзеров, в справках к ним, да и просто так, рассказывают небылицы и обещают, что их оптимизатор может делать нечто из разряда фантастических триллеров. Как-то: дефрагментация памяти; выгрузка неиспользуемых драйверов; предотвращение утечки памяти; ускорение работы системы; улучшение работы процессора или ещё чего-то там, с непременным многомудрым названием. И многое, многое другое, из этого же разряда (das ist Fantastisch).
Рассмотрим эти "возможности".

Дефрагментация памяти: у любого человека, более-менее знакомого с принципом работы x86 процессора в защищённом режиме со страничной адресацией и приблизительной теорией о написании операционных систем, этот термин вызовет лишь зубовный скрежет и истерический хохот. Тем более, когда заявляется, что память дефрагментирует какая-то там утилита, сторонняя, абсолютно фиолетовая для ОС, и совершенно не имеющая возможность каким-либо образом повлиять на логику работы менеджера памяти ОС, так как это часть её ядра.

Выгрузка неиспользуемых драйверов: то же самое - никакая третьесторонняя программа не может знать, нафига этот вот конкретный драйвер загружен в память, что он тута делает, и чаво ждёт. И выгрузить тоже не может, точнее, не имеет права, ибо это грозит, банально, синюшным экранищем.

Предотвращение утечки памяти: этого не может сделать даже сама ОС, которая выделила эту самую "утёкшую" память по запросу какой-то программы с реализацией фичи оной утечки. Если бы ОС это могла, то работать под ней было бы куда как приятнее. Но она не может, так как не может знать, какой именно из выделенных блоков уже не используется и потерян, а следовательно, не будет использован и в дальнейшем. Тем более не может этого сделать ни одна программа-оптимизатор, даже если её справка об этом заявляет.

Ускорение работы системы: неа, ни один оптимайзер не сделает из PI даже PII хотя бы. То же касается и ОС, в частности - вмешиваясь в её работу - оптимизатор не может ей помочь, не может её ускорить. Тем более это касается ОС, установленных на малом количестве ОЗУ. Очень часто в справках к другим оптимизаторам можно встретить слова, что мол, оптимизатор улучшает-де и ускоряет работу ОС на системах с небольшим объёмом оперативки. Читать это тем смешнее, что многие из этих самых оптимизаторов сами по себе, в простое (!), потребляют кучу памяти. Сразу представляется, как хорошо ускорит работу ОС на системе с, например, 64 МБ памяти, программа-"оптимизатор", которая сама жрёт 20 метров оперативки. Хехе, ускорители...

Улучшение работы железа: ничего подобного, даже наоборот, так как оптимизаторы памяти, попросту говоря, колбасят память до посинения тех пор, пока что-нибудь да не освободится, то процессор во время оптимизации, и его кэш, в частности, работают в crazy-mode, когда эффективность кэша снижается до нуля, а процессор удивляется всю дорогу, зачем его заставляют распихивать одни и те же байты по всей памяти, когда вокруг столько разных, не менее интересных, байт.
Т.е., как и любая дополнительная работа, незапланированная в ОС, оптимизация памяти подразумевает некоторые затраты ресурсов - в виде времени, например. Хотя нет, во время оптимизации, обычно отдыхает клавиатура, т.к. работа за компьютером, в данный момент выполняющим оптимизацию - мягко говоря - не очень удобна.

Многое-многое другое: куча-муча критически-саркастических знаков-буков...

Что предлагает этот оптимизатор

Впервые на ваших экранах оптимизатор, предлагающий единственно необходимую функциональность, без громких обещаний и миллиона фич "чтобы было"
Как уже было сказано, этот оптимизатор поддерживает теоретически неограниченный размер памяти. Хотя логический предел, конечно, существует, но до него ещё далеко.

Автор использует, и советует поступать так же, оптимизатор лишь для прямой цели - очистки какого-то объёма физической памяти под некие нужды, или из-за некоторых причин («— Дождик был, — пояснила Сова.»). Например: необходимо запустить виртуальную машину, а в данный момент на машине-хосте свободно меньше физической памяти, чем размер эмулируемой ОЗУ ВМ. Отчего ВМ запускаться не желает. Тут возможно несколько вариантов: позакрывать какие-нибудь программы, что не гарантирует того, что освободится необходимое количество памяти; перезагрузиться, что тоже нифига не гарантирует; создать в paint'е картинку, размером достаточную, чтобы вместить слона в масштабе 1:1, после чего закрыть paint, и большое количество свободной памяти гарантировано (этот способ всем хорош, за исключением того, что каждый раз придётся подыскивать подходящего по размеру слона, исходя из объёма необходимой к освобождению памяти); или можно использовать оптимайзер, желательно - RAM Clear
Или же, например, при копировании большого числа файлов, или большого(их) файла(ов), ОС буферизирует данные, и в конце концов, в памяти может оказаться действительно изрядная доза того, что было скопировано. Тут, опять же, чтобы освободить её (память) можно либо топать в paint, ведя припасённого в заначке слоника на поводке, либо использовать оптимайзер. Ясно, какой.

В общих чертах, класс оптимизаторов памяти представляется Автору как полезный, подходящий ко многим ситуациям инструмент, который всё же является узкоспециализированным, и без невероятных фич.

Кстати, да, похоже на то, что это - единственный из оптимизаторов на планете, который не предлагает чудо-фичу "автоматическая оптимизация" Действительно, на взгляд Автора, найти более странную "полезность" очень непросто. Автоматическая оптимизация подразумевает, что оптимизатор (некий, не этот!) начинает сам по себе, там, в фоне, оптимизировать память по достижении ею какого-то, установленного пользователем, минимального свободного количества; или, возможно, по прошествии какого-то определённого промежутка времени. И, конечно же, срабатывает эта чудо-фича кааак раз тогда, когда это так необходимо: пользователь компьютера своим игровым героем врывается в помещение с монстрами, с бластером наперевес, или, возможно, фильм на экране подошёл к острому моменту, и тут... - ВДРУГ! - в бэкграунде некто начинает очищать память методом её вытеснения. Фильм, естественно, заикается, а игрок обнаруживает своего героя в желудке у ближайшего монстра. Да здравствует Очень, Очень Полезная Фича - Автоматическая Оптимизация!

Ну, а теперь - СПАСИБЫ!

Несмотря на то, что программа-то совсем мизерная и скушная, она создавалась при участии нескольких человек.


Самым-самым главным тестировщиком, советчиком (дававшим верные, и - что более важно - тёплые советы), и публикатором стал Александр Левин - www.levin.rinet.ru Он не только оказал неоценимую помощь в тестировании и отладке на Win7 x64 на машине с конфигурацией, очень подходящей для теста основного алгоритма, но и давал множество полезных советов относительно того, как должна бы работать программка с точки зрения пользователя. Абсолютно все плюсы юзабилити, что вы можете оценить в программе - заслуга А. Левина. Всё самое неудобное, что есть в программе - на совести лени неназванного лица.


Also, I wanted to thank my friend Frank, who with great patience and understanding helped me with building of MSVC10 rip, testing of optimizer on x64 system with 8 GB of RAM, and my experimental ports of other hardcore pure-api applications towards x64 world...

Frank, I hope all is OK with you!

...После чего у А. Левина появилась забота по тестам порта оптимайзера на x64 платформу. Порт был произведён, но публично он недоступен, по причине того, что основная, нокаутирующая фича оптимайзера - это то, что он, оставаясь совместимым со всеми Win32 системами, может-таки оптимизировать больше 1,5-2 ГБ памяти, чего не могут все остальные 32-х битные оптимайзеры, известные Автору.


Автор благодарит главного редактора издательства "Тролльиздат", Ltd. Хыхдуна II Повелителя Троллей, взявшегося прочитать невменяемую документацию, описывающую программу, и указать Автору на его ошибки.


Конечно же, огромная благодарность сайту Old-Games.RU, который предоставил тёплый светлый уголок для этой малютки.


Ну, и, собственно, хотелось бы поблагодарить виновника всех копирайтовых багов, а также корявостей в дизайне и Невероятно Красивом Интерфейсе программы

Кстати, да, про красивый интерфейс. В дизайне интерфейса не было никаких намеренных действий, расцветка окна - просто (почти)случайный градиент, взбрендивший Автору ни с того ни с сего, любит, понимаешь ли, Автор градиенты. Потуги на художественность даже не предполагались. Это просто сложноградиентное окно.

- Автора, бишь...

Техническая информация о программе

Каким таким образом 32-х битная программа умудряется оптимизировать память, большую 2 ГБ?
При стандартном алгоритме работы программа функционирует как все известные Автору оптимайзеры - она пытается выделить кусище памяти с заданным пользователем размером, после чего начинает этот кусище усерднейше колбасищить, делать проход по всему выделенному блоку, в результате чего ОС вынуждена сбрасывать данные (и код) других программ на диск или освобождать вообще (касается неизменённых данных/кода). Попросту говоря, этот метод - метод вытеснения: оккупируя память по-нахальному, оптимизаторы заставляют ОС очищать память в итоге - после того как оптимизация завершиться, и оптимизатор освободит этот самый кусок памяти, по которому он делал проход(ы).

Так вот, максимальный размер памяти, которую может оптимизировать 32-х битный оптимайзер с классическим алгоритмом, ограничен самой архитектурой. 32-х битный код не может иметь доступ к памяти, большей 4 ГБ, под Windows этот размер ограничен до 2 ГБ не непрерывной памяти (до 3 ГБ под системами на ядре XP), а, фактически же, на 32-х битной ОС 32-х битный классический оптимизатор памяти не сможет оптимизировать память большую, чем 1-1,5 ГБ. Под x64 ОС Windows (тестировано на Win7) 32-х битный классический оптимизатор может оптимизировать до 2 ГБ памяти. И это фактический предел.

Чтобы преодолеть это ограничение, существует 2 пути - использовать специфические API для работы с памятью, большей 4 ГБ, в основе которых лежит технология PAE (Pentium Pro +), или использовать "distributed processing".
Первый вариант, фактически, хорошо подходит лишь для программ обработки больших объёмов малосвязанных данных, ибо основан на переключении "окон", которые ОС отображает на 32-х битное адресное пространство программы. Для программ-оптимайзеров данный метод не годится в принципе (по мнению Автора), т.к. для эффективного вытеснения памяти необходимо колбасить её синхронно по всему обрабатываемому объёму.

В данной программе использован второй метод, который одинаково хорошо (или одинаково плохо, смотря как оценивать) работает как на 32-х битных системах, так и на 64-х битных системах. А именно, при переключении алгоритма работы оптимайзера в Расширенный режим, оптимайзер становится многоруким чудищем, которое запускает от одной до множества подсистем оптимизации (так Автор предпочитает обзывать каждую копию запущенного процесса оптимайзера в режиме, когда он управляется основным процессом - тем, с интерфейсом которого работает пользователь), каждая из которых выделяет возможно больший кусок памяти из полного объёма, заказанного пользователем к оптимизации, и каждая же подсистема работает со своим блоком памяти независимо от другой, в результате чего достигается возможность оптимизации теоретически неограниченной по размеру памяти. Т.е., в Расширенном режиме алгоритма, то, что вы лицезреете на экране - лишь интерфейс полной системы оптимизации, и его руководящее ядро. Задачи этого ядра: получить от пользователя команду к оптимизации какого-то объёма памяти; проверить пользовательский ввод (на предмет правильности параметров); запустить необходимое число подсистем, количество которых определяется в реальном времени, в зависимости от возможностей системы; подождать инициализации и готовности к работе всех подсистем; одновременно запустить подсистемы в работу, и, что самое главное, обеспечить их синхронную работу. Синхронная работа подсистем - одно из главных требований, потому что необходимо, как уже было сказано, делать проход по всему заказанному объёму памяти. И алгоритм обеспечения оной синхронности - одна из самых spaghetti-style и частей программы, потому что требуется организовать, собственно синхронность - подсистемы не должны работать вразнобой и устраивать т.н. гонки (за вычислительными ресурсами системы), что имеет ещё большее значение на системах с несколькими исполнительными ядрами (многоядерный процессор/многопроцессорная система); также этот алгоритм должен всё время проверять: "А не грохнулась ли там какая-нибудь подсистема?", в случае чего - элегантно завершить процесс оптимизации, помимо чего (в данной версии эта часть алгоритма изменена, по сравнению с первым релизом программы), должно быть обеспечено быстрое прерывание процедуры оптимизации в случае такового желания пользователя.

Короче, говоря попросту: алгоритм Расширенный (Enhanced) - просто дикое количество всевозможных проверок, синхронизационных и временных блокировок, с кучей возможных ветвей развития событий и нескольких вариантов завершения подсистем (включая обработку краха какой-либо подсистемы). Кстати, да, если рабочий интерфейс (то, что вы видите на экране - т.е. руководящую систему оптимизации) сам, ВДРУГ, ни с того ни с сего грохнется, то все колбасящие память подсистемы будут автоматически завершены, т.е. - оптимайзер является в некоторой степени крахозащищённым - крах какой либо части общей системы оптимизации не приведёт к неуправляемой её работе. Так, во всяком случае, задумано



Оптимизатор полностью написан на C++, исходники заточены под MSVC, и адаптированы под x64 системы. Бинарники собраны с помощью "кастомной версии" MSVC10.

Список (не)известных багов программы...

...бесконечен

Автор будет искренне благодарен

Вляпает -1 во "Мнения" сильно усердного багоискателя. Шутка, конечно.

сообщениям об обнаруженных в программе ошибках, которые следует тихонько послать в ЛС и помалкивать в дальнейшем постить тут. Быстрое исправление багов не гарантируется... оно вообще не гарантируется (читать третий снизу пункт в разделе "кратких" характеристик программы). Но сам факт нахождения оного непременно следует обнародовать, зафиксировать в протоколе и , в конце концов.



Не рекомендуется использовать программу под Wine.
Под Windows 2000 возможно снижение эффективности оптимизации (читай - очистки) в связи с её политикой выделения памяти.
Возможны проблемы отображения окна оптимайзера на системах, настоенных на очень крупное масштабирование шрифтов. Программа нормально выглядит со 120% масштабизацией шрифтов, но при дальнейшем увеличение масштаба корректность отображения окна не гарантируется, ибо попросту не проверялась. Этот "баг" упомянут просто так, ибо 99% пользователей вообще вряд ли когда-то масштабировали шрифты.

Этот список будет пополняться. В данный момент Автору просто надоело уже писать и писать этот пост. Вот.

Ах, да, ещё. Справка весьма лаконичная, ибо программа выкладывается в месте, где находится опытный контингент.

Список используемых сокращений

Автор - АВТОР.

лень - совокупность таинственных факторов, влияющих на оценку Автором той или иной фичи (см. ниже) как необходимой к реализации.

фича - нечто, нуждающееся в реализации, но отложенное по причине "см. выше", или уже - а вдруг! - реализованное.

оптимайзер - оптимизатор памяти (от англ. memory optimizer - штука, напичканная фичами, и написанная ленивым Автором), на самом деле - всего лишь её очиститель, освободитель, Рембо среди программ.

Обновление программы: ~31 марта ~2012 года.
Количество предыдущих скачек: 89
​

 

Почему же "никто не понимает"? Здесь, в этой теме, речь идёт об одной конкретной программе, функции которой предельно ясно и полно расписаны выше. И в рамках этих функций она работает успешно. Если угодно, можно назвать её "ненастоящим оптимизатором" - от этого ничего не изменится, и хуже она работать не станет.

P. S. Мы внимательны.

 

Скорее, он просто приводит доводы, почему оптимизаторы памяти не могут таки именно ускорить работу системы, хоть их авторы (за исключением, как минимум, RAM Clear ) это утвержают. Как бы сильна ни была неприязнь к подобным нечестным обещаниям, сомневаюсь, что кто-то из "оппозиции" настооолько суров, что - из принципа! - полноценно работает (точнее, пытается) за компом, отключив файл подкачки.

А если эта программа - какой-нибудь редактор? Да тот же Ворд. Вставил юзер картинку в текст - программа стала чуть больше памяти потреблять. Перешёл на новую страницу, вводя текст, опять программа стала больше потреблять. Опять там вставил крупную картинку, и т.п. А ведь сколько других, более требовательных приложений...

Или завалить авторов баг-репортами

Чаще всего - это с приложениями что-то не так, как-то: фича утечки памяти
А оптимизатор может заменить любая программа, способная создавать большой объём данных, и сделать по ним, так сказать, проход. В шапке темы упоминался paint для этой цели, но может сгодится что угодно - но далеко не всё будет так удобно в использовании, как маленькая, хорошо со всеми осями разом совместимая, специально для этого написанная программка-оптимизатор.

Настоящих(тм) очистителей памяти нет
Убивать процессы - не лучший способ что-то, кхм, выключить. Лучше просто убрать из автозагрузки и т.п. тонкие, но мелкие работы - да, для этого есть софт, но то же самое можно сделать с помощью софта, предоставленного самой Виндой (скажем, "Редактором реестра"). К тому же, например, отключение программ из автозагрузки не гарантирует того, что посреди работы не появится необходимость освободить какой-то объём памяти. Например, для запуска ВМ. Это, опять же, то же было написано в шапке темы. Наверное, автору больше делать нечего было, как только писать тот здоровый пост, и выкладывать программу с теми же намерениями и объяснениями, как у всех остальных, автору известных, авторов других оптимайзеров.

Буквально удалить что-то из памяти - тоже не имеет "морального" права никакая левая третьесторонняя программа - никто не может знать, зачем это "что-то" в памяти находится. Например, да, можно вполне взять, и выгрузить из процесса какую-нибудь динамически в него загруженную библиотеку, нооо... ведь она зачем-то тут была? Если её выгрузить - вероятность краха процесса чуть менее, чем 100%. Тоже самое с освобождением "предположительно неиспользуемых" блоков выделенной памяти - может, служебный поток процесса чего-то ждёт, потому долго не обращался к этой области памяти, а вовсе не потерял её. Лучше просто окончательно выпихнуть этот блок в свап-файл (используя, к примеру, "оптимизатор памяти" ), откуда он в случае чего опять будет перекачен в оперативку, при обращении к нему. Эта надёжная тактика.

Всё это можно проделать стандартными средствами Винды, так же (в данном случае - апплетом управления службами) Так же, например: [Win]+[R], ввести msconfig.exe и нажать [Enter].

Но, опять же, в основном посте темы написано, что назначение оптимайзеров памяти - не в этом, и что конкретно в RAM Clear нет фич "лишь бы было". Его основные достоинства - совместимость (вроде того) - работает как на древных предревних виндах и компах так и на самоновых, и - в то же время - масштабируемость (так скажем): соптимизировать (освободить) 6 ГБ памяти на компе с 8-ю её гигами (и не отключенным свапом ) - для него не проблема, хотя он 32-х битная программа. Других таких оптимизаторов автор не встречал, может, просто плохо искал. Потому и написал свой

 

Cels
Оптимизатор может помочь в случае если нужен большой непрерывный кусок памяти, а ОС говорит что нету. Оптимизатор выгружает приложения в своп и все начинает работать. Нужна такая работа с памятью как правило для VM и архиваторов (вообще такие проги обычно и сами умеют так делать), либо для кривых приложений где большой непрерывный кусок памяти не нужен, но запрашивается.

Если действительно нужна память то рекомендую выгрузить explorer. Помнится во времена windows95/98 это было популярно. Я даже писал собственную замену вся функция которой заключалась в том чтобы запускать приложения. Профит - несколько мегабайт и знание что из твоего кода уж точно ничего не течет ))

Ну для Word такое нафиг не нужно. Если программа запускается изредка и ненадолго то для пользователя неважно течет память или нет т.к. после закрытия приложения память вернется обратно в систему. Нужно следить за приложениями с которыми работаешь долго.

 

Я использую эту программу больше всего именно для Word. Запускаю его часто, как правило, одновременно открыты сразу несколько документов, в течение длительного времени и параллельно с другими программами. Эффект от оптимизатора очень заметен.

 

Я извиняюсь, но налицо полное непонимание функционирования подсистемы управления памятью. Понятие «непрерывный кусок» здесь лишено смысла.

 

Можно запросить память чтобы она обязательно располагалась непрерывным куском в реальной памяти

Манипуляции с MEM_LARGE_PAGES в VirtualAlloc

для повышения быстродействия, а можно запросить как обычно. wtf?

 

В десктопных приложениях это часто используется? Ни разу не видел, чтобы программа написала «не хватает памяти».

 

Два идиота. В 64битных ОС уже давно по дефолту 4М размер страницы и так.

 

Ну может, речь о гигабайтных страницах?

 

А выше не имеет значения. Всё равно пойдёт по VM_*_PAGE_SIZE.

 

Познакомьтесь с FreeArc. Наиболее актуальный пример. Подавляющее большинство репаков на трекерах собираются с его помощью.

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

В окне "О программе" специально высвечивается текущее значение, доступное в системе.

Прекрасная статья от egor23, своим оформлением и внушительной историей правок демонстрирующая всю важность наличия подобного блока для данного архиватора.

http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html#p3

 

Это используется в 7zip как минимум. Как часто такая проблема возникает - вопрос не ко мне, а к автору.

ОС используют такие размеры страницы только для себя, а не для приложений.
К тому же вопрос не в том какой размер по дефолту, а то что это можно заюзать если присутствует возможность использовать PAGE_SIZE большего размера.

 

Ворд был просто примером. Также в той цитате были слова "А ведь сколько других, более требовательных приложений...". Перезапускать 100500 раз приложение, с которым плотно работаешь - не самая лучшая из идей. Нет, конечно, это делать никто не запрещает, но работая в массивных прогах, не всегда есть желание приостанавливать процесс работы ради того, чтобы перезапустить приложение - проще выпихнуть весь "мусор", который оно насоздавало в процессе утечек, чуть потерпеть некоторые тормоза после этого, и продолжать работу. Конечно, это тактика не для каждодневного использования, и, более того, не для каждого пользователя. Но эта программа и не предназначается для массового широкого потребления - она для тех, кто хорошо понимает, что делает (потому что иначе любой оптимизатор памяти лишь вредит производительности системы) и для чего делает.



Всё-таки возникла некоторая (весьма частая) путанница в терминологии.
Это о термине "непрерывный блок памяти". Под ОС защищённого режима со страниченой адресацией он имеет два возможных смысла, каждый из которых является верным в своём контексте.

Первый смысл - о непрерывном блоке физической памяти. В данном контексте подразумевается то, что определённый блок выделен в физической (реальной, железной - как угоднее) памяти действительно таким образом, что выделенные страницы этого блока следуют одна за другой на физическом уровне - т.е. их физические адреса (подающиеся на шину) на самом деле последовательны.
Благодаря этому, доступ к такому блоку памяти становится несколько быстрее, т.к. процессору, банально, необходимо выполнить меньше работы по вычислению физического адреса страницы из виртуального (все user-mode приложения под Виндой работают исключительно с виртуальными адресами).
Выделение блока памяти в таком контексте (смысле) и опысывается здесь: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs.85).aspx

Второй смысл - о непрерывном блоке виртуальной памяти. Все user-mode приложения под Виндой работают с виртуальной памятью. В данном контексте это означает то, что для самого приложения блок "выглядит" как непрерывный - выделенные байты этого блока следуют один за другим. В действительности же, физические страницы этого блока могут быть разбросаны по железной памяти как угодно, но user-mode программам это "прозрачно", т.к. процессор выполняет работу по трансляции виртуального адреса страницы в физический на основании таблиц.

Непрерывный большой блок любой памяти действительно сказывается положительно (или даже необходим) на многих алгоритмах, таких как компрессия данных. У известного архиватора-чемпиона paq8p уровень компрессии вообще задаётся на основании объёма используемого блока, и может доходить размера более полутора гигабайт (во всяком случае, в версии 2008 года).
Но, в user-mode, этой "любой" памятью, для создания большого непрерывного блока памяти, становится виртуальная память.
На самом же деле, что kernel-mode, что в user-mode при использовании API для выделения блока из нескольких физически непрерывных страниц, создание большого непрерывного физически блока памяти невозможно в принципе (и крайне нерекомендуется создавать даже относительно большие такие блоки) в ОС общего назначения защищённого режима со страничной адресацией. Получить доступ к большому физически непрерывному блоку, размер которого ограничен только размером железной памяти (ну, т.е. ОЗУ) можно лишь в т.н. "unreal-mode", или написав собственную ОС, целью которой будет предоставление этого блока определённому приложению.

Кстати, некоторая информация об ограничениях и возможностях выделения блоков памяти под виндой было, таки, упомянуто в треде: http://www.old-games.ru/forum/showthread.php?p=787853#post787853 а так же в шапке темы, в разделе "Техническая информация о программе".



Прирост производительности при выделении физически непрерывных блоков памяти не так уж велик, куда большее значение имеет правильная организация доступа к данным так, чтобы кэш работал с максимальной эффективностью. Но, т.к. сделать это на ЯВУ в сколь-нибудь полном объёме невозможно, то появляются такие вот API, которые могут для user-mode приложений на ЯВУ предоставить "ну хоть что-то".
Отрицательные же последствия использования физически непрерывных блоков (тем более - больших) памяти гораздо больше, если говорить не о каком-то коде for fun, а о стабильной высоконадёжной системе по какой-либо обработке данных.
В Линуксе, кажется, при вызове, стрек драйвера ограничен всего в одну физическую страницу - как раз из-за возможных проблем при выделении нескольких последовательных физических страниц памяти, возникающих из-за неизбежной фрагментации памяти (не ручаюсь за свежесть информации, почёрпнута была в книге Роберта Лава "Разработка ядра Linux", 2-е издание).

 

Эффект настолько слаб что эту фичу реализовали в VirtualBox (см May 18, 2010). В linux есть такая вещь как hugetlb.

Честно говоря я думал что менеджер памяти windows фэйлит при подобной работе с памятью в силу чего ему может помочь оптимизатор. Если вы на такой случай не рассчитывали то в чем профит? Очистить память предварительно чтобы во время работы приложения не происходило выгрузок в своп?
А что насчет нехватки памяти VM для описанного случая в первом посте?
Т.е. менеджер памяти фэйлит настолько что не может освободить память самостоятельно выгрузив лишнее?

 

Andrey_P, Профит сего топика вообще то в том, что объясняются принципы работы подобных программ и бессмысленность надежд возлагаемых на них юзерами мечтающими некой чудотворной программулиной "из гига физической памяти сделать два, что бы поиграть в новую гейму требующую шесть".

 

A.P.$lasH, Andrey_P, приведённые вами примеры применимы к: а) программам, которые используют large pages, б) они 32-битные и работают в 32-битной среде, в) память они используют по максимуму, близко к практическому пределу для 32-битных приложений. Я по ссылке почитал — там такая камасутра, что гораздо проще перейти на 64-битную систему, если уж нужно. О чём, собственно, там прямым текстом и говорится.
Кстати, 7-zip в любом случае лучше использовать 64-битный.
Короче, не убедили.

 

Во-первых, обратите внимание но то, что там написано:

"New Large Page support – Reducing the size and overhead of key system resources, Large Page support delivers increased performance by enabling faster lookups and shorter table creation times. "

Здесь говориться, что начинается поддержка "больших страниц", ни слова о последовательных областях памяти, о чём говорится в той моей цитате (напомню: "Прирост производительности при выделении физически непрерывных блоков памяти ..."), которую вы привели. Это действительно так захватывающе - хватать первую попавшуюся цитату, и отвечать на неё несвязно? Надо попробовать. Ну, вот, хотя бы, а Virtual PC вообще юзает такую функцию ядра винды: MmAllocateContiguousMemory. Если перевести её, то это будет МенеджерПамятиВыделитьПоследовательнуюПамять. И что дальше? Запуск любой ВМ, вообще, "несколько" сказывается на хосте, это о чём-нибудь говорит?


И, во-вторых, повторяюсь, эффект использования упомянутых буферов в плане производительности - незначительный. Кстати, да, если говорится, что благотворный эффект - незначительный, это вовсе не значит, что нужно отказаться от его использования - даже если производительность увеличиться "всего" на несколько процентов - это увеличение производительности. Поэтому это:

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


Вообще, максимальные проблемы с производительностью возникают у кода, когда он, образно говоря, переходит границу между этими самыми страницами. Т.е., для примера, если, скажем, цикл побайтно работает с памятью, то самая сильная задержка (stall) может возникнуть тогда, когда цикл после работы с последним байтом текущей страницы, запросит первый байт следующей страницы. Учитывая то, что в странице на x86 железе, как минимум, 4 КБ, этот самый сильный stall может возникнуть лишь один раз в 4096 итераций цикла.
Этот пример должен сделать понятнее, почему же большие страницы (4 МБ, к примеру), полезны - они позволяют циклу отработать аж овер4000000 итераций, прежде чем будет stall при доступе к следующей странице, или её подгрузки из свапа (самая сильная задержка возможна именно в случае, если страницу системе пришлось подгружать из свапа).
Опять же, трудности с оптимальной организацией доступа к данным в контексте кэша - куда более сильны, так как кэш имеет "страницу" (линию), сейчас (и насколько мне известно), всего в 32/64 байта - и каждый раз, при неоптимальном преодолении этой границы, возникает весьма неиллюзорный stall.

Многократно в теме было сказано много чего, но уж точно не было сказано, что менеджер памяти фэйлит. Это вообще одна из самых древних, отработанных, и тщательно вылизываемых подсистем ядра. Но её поведение - инертно. Т.е., менеджер памяти не станет в срочном порядке сбрасывать любые данные, если на то нет причины. Если Вам вдруг захочется запустить ВМ, но свободной ОЗУ для этого недостаточно (кстати, нужна имеено свободная ОЗУ, не виртуальная память, а физическая - это как бы намёк на то, что ВМ - не лучший пример программ, использующих "хардкорные буфера" (большие страницы; последовательное выделение памяти); они, вообще-то, для своей работы требуют драйвера, что как бы намекает). Так вот, если свободной ОЗУ недостаточно для запуска ВМ - то ОС не в курсе того, что Вам срочно нужно запустить ВМ. Для ОС - все программы одинаково важны, и поэтому она не станет сурово отнимать пространство в ОЗУ у одних программ по первому писку любой другой программы. Программа получит блок загруженным в ОЗУ тем быстрее, чем будет более настойчива и агрессивна, так скажем. Вы можете заменить любой оптимизатор paint'ом, как уже было много раз сказано, а можете просто упорно делать попытки запустить ВМ. Через раз, эдак, 5...50, ОС заметит настойчивые попытки (которые инициируете Вы) ВМ запуститься, и может быть соблаговолит выделить нужную ВМ память, в результате того, что при каждой попытке запуска ВМ ОС по чуть-чуть (инертно, инертно) осовобождала ОЗУ.

Вообще, для "оптимизации" (очистки) памяти нужно запросить память не в ОЗУ, а просто виртуальную память, тогда, если размер виртуальной памяти достаточен (обычно - всегда достаточен, если только зачем-то не отключить файл подкачки). После чего нужно начать делать проход по ней. Буквально. Начать читать/писать во все байты выделенного в ВП блока. Это вынудит ОС в авральном порядке выделять железную память (ОЗУ) для размещения данных агрессивно обрабатываемого блока. Для чего ОС будет вынуждена очищать дисковые кэши и сбрасывать данные других программ в свап. Посли чего программа-оптимизатор освободает блок, с которым агрессивно работала, и в системе весьма кстати появляется количество свободной железной памяти (ОЗУ), равной размеру только что освобождённого блока.

Это, в общих, но полных, чертах, и есть алгоритм работы всех оптимизаторов памяти, что известны автору. И он был таки, таки был он, был он таки описан в шапке темы, только ещё более шутливым языком. Таки был

 

http://www.osp.ru/win2000/2004/01/176611/
С этим чуваком лучше точно не спорить.

 

Как ни странно, только сейчас заметил этот пост.
С этим "чуваком" никто и не спорит, ибо, если внимательно прочитать то, что написано в той статье, и сравнить с тем, о чём на протяжении всей темы разглагольствовал многоуважаемый Автор программы, то станет ясно, что смысл немножечко идентичен. Но то, что написано в этой теме, написано гораздо более лёгким для понимания языком. Другое дело, что мало кто удосужился, видимо, прочесть основной пост, и большинство постов в теме повторяют одно и то же, на разные лады.

В статье написано, что Марк Руссинович не встречал "оптимизаторов памяти", которые бы выполняли то, что обещают - он прав, в те времена, когда была опубликована статья, RAM Clear не была опубликована. Если кто-то наберётся смелости и переведёт основной пост темы на английский один-в-один, и ознакомит Руссиновича с ним, есть сомнения, что тот скажет, что там написана ложь.

Как же все любят срывать покровы. Смущает только, что Автор темы вроде бы пытался сделать то же самое. Клуб разоблачителей-самолюбователей какой-то получился.

 

А какой смысл в этом оптимизаторе??
Ну заставляет он винду выкинуть из памяти все, что там закешированно, и что? Винда и сама сделает ровно то же самое, если какому-то приложению понадобится память.