Лингвофорум

Нашел способ уменьшить количество пожираемой хромом оперативы
- поставил стандартную тему
- удалил три расширения из восьми
- поставил Chrome Canary

итого освободилось приблизительно 600 мб

Есть ещё один способ.

- удалить хром

Цитата: basta от июня 18, 2017, 20:14
- удалить хром

а то остальные не жрут, стоит наставить тех же нужных расширений и открыть столько же вкладок...

Opera 12.18. Открыто 10 вкладок (5 ЛФ, ВК, Гугль Транслейт, //godville.net и 2 локальных файла со скриптами по самое не могу).
~200 мегабайт. (Когда начинал писать, было 199.5, сейчас 200.1.)

Цитата: Bhudh от июня 18, 2017, 23:43
Opera 12.18. Открыто 10 вкладок (5 ЛФ, ВК, Гугль Транслейт, //godville.net и 2 локальных файла со скриптами по самое не могу).
~200 мегабайт. (Когда начинал писать, было 199.5, сейчас 200.1.)

не надо ретроградства

Надо жора оперативы, да. Надо ж куда-то 16 гигов девать. Или 32. Или 64.
Только миллионеры-то не все.

А на что вообще смотрят, когда говорят «N мегабайт RAM»?  Программа может зарезервировать хоть 10 гигабайт, но реально оперативка будет занята, только если в эти гигабайты начнутся активные чтение/запись. Если компутер не уходит в тормозный своп, то не надо и волноваться.

Цитата: Алексей Гринь от августа  6, 2017, 23:38
А на что вообще смотрят, когда говорят «N мегабайт RAM»? 

Диспетчер задач?

Я само собой в диспетчер. Причём с хромыми браузерами хочется ругаться матом, ибо объединять процессы с одним именем он не умеет и встроенного калькулятора там тоже нет.

640 КБ всем хватит

Цитата: Алексей Гринь от августа  6, 2017, 23:38Программа может зарезервировать хоть 10 гигабайт, но реально оперативка будет занята, только если в эти гигабайты начнутся активные чтение/запись.

Смотря как выделять.

Цитата: Upliner от августа  7, 2017, 12:48
Смотря как выделять.

Резервирование виртуальной памяти не затрагивает физическую RAM или pagefile до тех пор, пока не будет коммита. По поводу Java было много shitstorm'а, мол, используют кучу памяти ни за что ни про что. А на деле смотрели не туда: Java на старте резервирует память, чтобы иметь непрерывный кусок памяти для более простой адресации (compressed OOP's, определение валидности указателей, heap compaction и т.д.). ОС будет выделять страницы из RAM по мере доступа к страницам ("faulted-in"). В диспетчере задач есть большое количество столбцов с разными типами информации о памяти (Вид > выбрать столбцы), и не все одинаково полезны. Может выглядеть, будто бы приложение ест гигабайты, а реально из RAM взята пара мегабайт. Надо быть внимательным, куда смотришь.

Цитата: Алексей Гринь от августа  7, 2017, 13:14
ОС будет выделять страницы из RAM по мере доступа к страницам ("faulted-in")

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

Цитата: Toman от августа  7, 2017, 23:29В общем случае такое поведение недопустимо, поскольку может привести к мгновенному исчерпанию физической памяти в любой момент и соотв. отказу системы. Т.е. в общем случае, даже если процесс ничего не писал в какую-то область, то даже если страницы не выделены физически, соответствующее количество памяти должно быть записано за процессом, чтобы в общей сумме не могло быть выделено памяти больше, чем есть физической.

Увы, memory overcommitment -- это практически общепринятая практика. Используются различные эвристики, чтобы недопустить такого неожиданного исчерпания, но если оно всё-таки произойдёт -- заработает oom killer и убьёт какое-нибудь из приложений.
Кстати да, не нашёл в винде аналога линуксового MAP_POPULATE, так что пожалуй действительно единственный способ там выделить память физически -- занулить её после выделения.

Цитата: Toman от августа  7, 2017, 23:29
О какой именно ОС речь?

Так все с MMU.

Цитата: Toman от августа  7, 2017, 23:29
Т.е. в общем случае, даже если процесс ничего не писал в какую-то область, то даже если страницы не выделены физически, соответствующее количество памяти должно быть записано за процессом

Так запись-то виртуальная. Каждый процесс имеет своё адресное пространство. Если процесс зарезервировал много памяти, то другим процессам на это по барабану до тех пор, пока этот процесс не начнёт реально использовать эту память, т.к. тогда начнётся борьба за RAM и файл подкачки.

Цитата: Toman от августа  7, 2017, 23:29
соответствующее количество памяти должно быть записано за процессом, чтобы в общей сумме не могло быть выделено памяти больше, чем есть физической.

А вот тут зависит от ОС. Винда, насколько я помню, фейлит рано, а вот Линукс с радостью будет выделять память, заведомо обречённую на провал. Поэтому bad_alloc в C++ бесполезен в Линуксе, т.к. в итоге можно получить валидный указатель, но потом упасть на commit on demand.

Цитата: Алексей Гринь от августа  8, 2017, 00:07А вот тут зависит от ОС. Винда, насколько я помню, фейлит рано, а вот Линукс с радостью будет выделять память, заведомо обречённую на провал. Поэтому bad_alloc в C++ бесполезен в Линуксе, т.к. в итоге можно получить валидный указатель, но потом упасть на commit on demand.

Да, по этой причине в Линуксе свободно можно отключить своп, а вот если в винде отключишь своп -- неминуемо огребёшь проблем.

Цитата: Upliner от августа  7, 2017, 23:52
Кстати да, не нашёл в винде аналога линуксового MAP_POPULATE, так что пожалуй действительно единственный способ там выделить память физически -- занулить её после выделения.

А что MEM_COMMIT?

Цитата: Алексей Гринь от августа  8, 2017, 00:12А что MEM_COMMIT?

ЦитироватьAllocates memory charges (from the overall size of memory and the paging files on disk) for the specified reserved memory pages. The function also guarantees that when the caller later initially accesses the memory, the contents will be zero. Actual physical pages are not allocated unless/until the virtual addresses are actually accessed.

Так MEM_COMMIT гарантирует, что физ. памяти хватит, когда она понадобится.

Цитата: https://blogs.msdn.microsoft.com/oldnewthing/20110128-00/?p=11643MEM_COMMIT makes the memory manager guarantee that physical pages will be there when you need them

А иначе зачем форсить выделение физ. страниц?

Цитата: Алексей Гринь от августа  8, 2017, 01:07
Так MEM_COMMIT гарантирует, что физ. памяти хватит, когда она понадобится.

Цитата: https://blogs.msdn.microsoft.com/oldnewthing/20110128-00/?p=11643MEM_COMMIT makes the memory manager guarantee that physical pages will be there when you need them

А иначе зачем форсить выделение физ. страниц?

Для производительности, чтобы вместо page fault-а на каждые новые 4 килобайта был один системный вызов.

Цитата: Upliner от августа  8, 2017, 01:32
Для производительности, чтобы вместо page fault-а на каждые новые 4 килобайта был один системный вызов.

А есть ли реальный прирост производительности или это premature optimization? Нет разницы, когда происходит собственно сам маппинг — перед алгоритмом или on demand, т.к. суммарно будет потрачено то же время. Поэтому получается, что единственный оверхед — в прерываниях и обработчике. Судя по разным источникам, и на Виндовс, и на Линукс, средний оверхед варьируется где-то в районе 2000 циклов максимум, т.е. грубо говоря 1 цикл на каждые 2 холодных (!) байта при размере страницы в 4К. Неужто это так серьёзно? Если алгоритму нужно проходиться по огромному цельному массиву данных, задевая каждую страницу, то явно у нас какой-то number crunching, и тогда у нас на каждый байт и так приходится не по одной инструкции; 1 цикл как-то теряется в этой массе, не так ли?

But anyways, Виндовс имеет large page support, если уж приспичило: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366720(v=vs.85).aspx

Цитата: https://blogs.msdn.microsoft.com/oldnewthing/20110128-00/?p=11643Since very large pages have special physical memory requirements, the physical allocation is done up front so that the memory manager knows that when it comes time to produce the memory on demand, it can actually do so.

Цитата: Upliner от августа  7, 2017, 23:52заработает oom killer

Убийца ума?

Цитата: Upliner от августа  7, 2017, 23:52
Используются различные эвристики, чтобы недопустить такого неожиданного исчерпания, но если оно всё-таки произойдёт -- заработает oom killer и убьёт какое-нибудь из приложений.

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

Цитата: Алексей Гринь от августа  8, 2017, 00:07
Так запись-то виртуальная. Каждый процесс имеет своё адресное пространство. Если процесс зарезервировал много памяти, то другим процессам на это по барабану до тех пор, пока этот процесс не начнёт реально использовать эту память, т.к. тогда начнётся борьба за RAM и файл подкачки.

Как только начинается борьба и вообще какое бы то ни было использование подкачки - это почти наверняка означает отказ, поскольку приложение не может гарантированно ответить в пределах заранее оговоренного времени.

Ни винда, ни линукс не являются realtime системами, поэтому требовать от них "гарантированного ответа в пределах заранее оговоренного времени" просто глупо...

Цитата: Upliner от августа  8, 2017, 21:00
Ни винда, ни линукс не являются realtime системами, поэтому требовать от них "гарантированного ответа в пределах заранее оговоренного времени" просто глупо...

Точно. Эти ОС не гарантируют realtime.