на главнуюВсе эхи RU.INTERNET.ICQ
войти ?

Потребление памяти в ОС

От Eugene Muzychenko (2:5000/14) к George Hazan

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Привет!

25 Nov 13 03:02, you wrote to me:

EM>> По такому запросу гуглится описание работы с памятью в Win6,
EM>> которое принципиально не отличается от работы с нею в Win5.

GH> Ты как-то запоздал лет на семь с этим... Практически все форумы, где
GH> это обсуждалось, уже успели закрыться.

Вот не надо ля-ля, а? Крупные серьезные форумы существуют еще с 90-х, и практически все живы. Энное количество появилось в начале 2000-х - они тоже почти все живы. Google Groups, MS Social, OSROnline, наши iXBT и RSDN - еще более живы. Везде базы полностью доступны для поиска.

То, как ты изо всех сил изворачиваешься, не делает тебе чести.

GH>>> http://us.generation-nt.com/readyboost-readydrive-memory-manageme
GH>>> nt-wi ndows-vista-review-25047-1.html
EM>> Ты сам-то это читал?

GH> Читал, и не только лишь первую страницу, но и дальше (там их 4).

Угу, на остальных страницах обсуждаются SuperFetch и ReadyBoost. Каким боком они относятся к мифическим проблемам Win5, которые ты ей приписываешь?

EM>> А здесь вообще имеет место бред дилетанта, не понимающего даже
EM>> разницы между Free и Available.

GH> Hет, не бред :) и в комментариях много интересного.

Там комментарии в основном от таких, как ты - слышавших звон, но не знающих, где он. :) Я ж тебя просил привести первичную информацию - от MS или, хотя бы, от Руссиновича. Информация будет, или сойдемся на том, что ты это нафантазировал? :)

GH> В XP проигрыш по времени работы от 70 до 200% (на повторной
GH> компиляции), на том же железе.

Тебе сколько раз нужно объяснить, что этот проигрыш - следствие _комплекса_ факторов, присущих каждой из систем? В том числе и то, что новые студии, безусловно, оптимизируются именно под семерку, а не под XP. Хотя и такой серьезный проигрыш тоже крайне подозрителен - ну не бывает чудес, хоть ты тресни. Либо ты плохо собрал статистику, либо XP у тебя была слишком засрана и/или содержала искусственные тормозные факторы (тот же антивирус, проверяющий файлы на лету), или в ней стоял очень неэффективный драйвер диска, или ты когда-то крутил руками системные параметры и забыл об этом, и так далее.

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

GH> Тем, что не создают на ОС никакой нагрузки. Можно сравнить те 3-5
GH> МБ/сек, которые оно может читать из интернета, с в 10-20 раз большей
GH> линейной скоростью винтов.

Я напомню, что начинал ты с того, будто XP якобы просто так, без необходимости, выкидывает из памяти страницы, а свободную память под кэш не использует. Если это так - почему я этого не вижу? Я много лет вижу одно и то же: до тех пор, пока физической памяти хватает для всех процессов - из нее ничего не выкидывается.

Возможно, на твоих проектах (например, большие заголовки, но мелкие единицы трансляции) компилятор настолько быстро меняет свой рабочий набор, что ты визуально не успеваешь это отследить - попробуй приглядеться к дельтам и счетчику ошибок страниц в статистике. Если он за секунду успевает раздуться на несколько сотен мегабайт, а потом настолько же сдуться - неудивительно, что система будет ужимать файловый кэш гораздо быстрее, чем наполнять его, а в среднем ты будешь видеть минимум несколько сотен мегабайт, болтающихся впустую. Так в подобном поведении XP нет ни малейшего недостатка - это следствие неэффективной работы процесса компилятора. И если семерка умеет такое поведение определять/предсказывать - это не столько доблесть, сколько лихорадочные попытки залатать очередной косяк.

GH> А чем еще?.. скорострельность компилятора в решающей степени зависит
GH> от: - эффективности файлового кэша; - способности ОС пулять десятки
GH> процессов в параллель, отдавая им какую-то память; - способности
GH> балансировать между lazy write и чтением.

Ты в курсе, что компилятор C++ от MS вообще исключительно тормозной чисто в вычислительном плане? Посмотри, с какой скоростью он компилит даже небольшие проекты в цикле, когда все файлы уже всосаны в кэш? А с файлами он работает еще хуже - посмотри, сколько временных файлов оно создает при каждом запуске. Так что у тебя не столько "тяжелое", сколько кривое и неоптимальное приложение. Hе удивлюсь, если в Win6 приняты специальные меры для распознавания "родного" софта и посильного выпрямления его работы.

EM>> Даже если ты, сменив на одном и том же железе XP на семерку,
EM>> поставил туда в точности тот же самый набор софта, включая студию
EM>> - ты, во-первых, получил свежую установку относительно уже
EM>> загаженной.

GH> Это тут каким боком?

Э-э-э... Hикогда не видел, как свежепереустановленная система начинает летать, в то время как та же версия, поработавшая несколько лет, заметно тормозила?

GH> Твои подозрения можешь смело оставить себе :) Я вот подозреваю, что ты
GH> тупо валяешь дурака :)

А ты определенно валяешь, тут и подозрений не нужно. Сперва заявил о совершенно конкретной разнице в стратегиях управления памятью в XP и семерке, которые, якобы, всем известны, а как я попросил дать ссылки на документацию - уже который день тянешь.

EM>> По мере запуска процессов и раздувания их рабочих наборов объем кэша,
EM>> само собой, уменьшается.

GH> В какой пропорции?

Ровно настолько, насколько увеличивается commit.

EM>> Семерка точно так же высвопит или убьет standby-страницы, когда будут
EM>> исчерпаны free.

GH> Hет, не точно так же.

Ссылку на документацию, пожалуйста. Или на конкретные места в коде (напоминаю, исходники 2k тоже годятся, если ты действительно ядерщик - они у тебя обязаны быть). Или на пример, который можно запустить в XP и семерке без установки всей той кучи софта, которая установлена у тебя. Проще всего - в виртуалке, там гарантированно будет и одинаковое железо, и любой подходящий объем памяти. Без этого - только на правах фантазий.

EM>> и кончая лучшим параллелизмом работы драйверов в ядре (включая
EM>> дисковый).

GH> Это-то тут при чем? Hикаких сказей нет, все крутится на одном винте

А винт - тупой IDE, без NCQ?

EM>> Я, по странному совпадению, тоже ядерщик, и тоже представляю, как
EM>> оно там внутри работает, поэтому меня и удивляет твое упорство. :)

GH> И до сих пор сидишь на XP? :)

Э-э-э... У меня снова когнитивный диссонанс. Для ядерщика, вообще-то, требования к хостовой системе минимальны - лишь бы поддерживалась средствами разработки и тестирования. Ядерные проекты во много раз меньше прикладных. Я до прошлого года вполне успешно сидел на XP, держа в виртуалках 2k, XP, 2k3, Vista, Win7, Win8. Год назад наконец нашел подходящий по производительности ноутбук, теперь работаю на нем под Win7 x64.

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: Fox Tracks, Novosibirsk, Russia (2:5000/14)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.INTERNET.ICQ?msgid=2:5000/14+5292e6fe