Нашел способ уменьшить количество пожираемой хромом оперативы
- поставил стандартную тему
- удалил три расширения из восьми
- поставил 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»? :??? :-\ :srch: Программа может зарезервировать хоть 10 гигабайт, но реально оперативка будет занята, только если в эти гигабайты начнутся активные чтение/запись. Если компутер не уходит в тормозный своп, то не надо и волноваться.
Цитата: Алексей Гринь от августа 6, 2017, 23:38
А на что вообще смотрят, когда говорят «N мегабайт RAM»? :??? :-\ :srch:
Диспетчер задач?
Я само собой в диспетчер. Причём с хромыми браузерами хочется ругаться матом, ибо объединять процессы с одним именем он не умеет и встроенного калькулятора там тоже нет.
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 и убьёт какое-нибудь из приложений.
Т.е. произойдёт отказ системы. В принципе нет никакой разницы - убивать какое-нибудь из приложений или просто выключить и перезагрузить систему с нуля, в обоих случаях происходит отказ. А это недопустимо - чтобы происходил отказ при исправной аппаратуре и без ошибок в ПО, при штатном функционировании того и другого.
Цитата: Алексей Гринь от августа 8, 2017, 00:07
Так запись-то виртуальная. Каждый процесс имеет своё адресное пространство. Если процесс зарезервировал много памяти, то другим процессам на это по барабану до тех пор, пока этот процесс не начнёт реально использовать эту память, т.к. тогда начнётся борьба за RAM и файл подкачки.
Как только начинается борьба и вообще какое бы то ни было использование подкачки - это почти наверняка означает отказ, поскольку приложение не может гарантированно ответить в пределах заранее оговоренного времени.
Ни винда, ни линукс не являются realtime системами, поэтому требовать от них "гарантированного ответа в пределах заранее оговоренного времени" просто глупо...
Цитата: Upliner от августа 8, 2017, 21:00
Ни винда, ни линукс не являются realtime системами, поэтому требовать от них "гарантированного ответа в пределах заранее оговоренного времени" просто глупо...
Точно. Эти ОС не гарантируют realtime.
Цитата: Upliner от августа 8, 2017, 21:00Ни винда, ни линукс не являются realtime системами, поэтому требовать от них "гарантированного ответа в пределах заранее оговоренного времени" просто глупо...
Смотря какие. RTLinux (https://ru.wikipedia.org/wiki/RTLinux) и Windows CE (https://ru.wikipedia.org/wiki/Windows_CE) являются ОС реального времени. А для десктопных вариантов Windows есть RTX (http://www.rtsoft.ru/press/articles/detail.php?ID=1946).
Цитата: Lodur от августа 8, 2017, 22:14
Windows CE
Моё понимание — она не столько realtime, сколько урезанная и оптимизированная, чтобы летать на тормозных девайсах конца 90-х/начала 2000-х (что сейчас не совсем актуально). Там, конечно, хошь не хошь, а напишешь ОС прямолинейную, но при этом и весьма урезанную в фичах (тех, что можно найти на десктопе). Правда, я давно смотрел в CE, не знаю, как сейчас.
В любом случае, речь была о нехватке памяти (борьба процессов за RAM и файл подкачки). В CE хвалятся стабильностью context switches, queue operations, interrupt handlers и т.д. — то есть работа системы в штатном режиме. Но если в девайсе памяти нет, то её магическом образом больше не появится от того, что система "realtime". Программы так же начнутся валиться от нехватки памяти, таким образом не давая "гарантированного ответа в пределах заранее оговоренного времени"...
Цитата: Алексей Гринь от августа 8, 2017, 22:50
Но если в девайсе памяти нет, то её магическом образом больше не появится от того, что система "realtime". Программы так же начнутся валиться от нехватки памяти, таким образом не давая "гарантированного ответа в пределах заранее оговоренного времени"...
Это неправильно написанные (с точки зрения реалтайма) программы. Правильно написанные должны сразу при попытке старта отказываться запускаться, говоря, что не хватает памяти - даже если она как бы не нужна именно в данный момент.
А
в общем случае требования к работе десктопного компьютера в его современных применениях - именно реалтаймовые. Вся работа со звуком и музыкой - принципиально реалтаймовая, с видео - тоже. Компьютерные игры в очень значительной своей части (те, где симулируется какая-то более-менее правдоподобная физика, в частности, да и просто самые тупые аркады на скорость реакции) - тоже реалтаймовые по требованиям.
Я не знаю, как разработчикам фокса удалось всё сломать, но последние полгода-год хром у меня жрёт памяти лишь чуть больше, чем фокс. (А раньше фокс ел в разы меньше, чем и был хорош.) И к тому же, фокс стал дико тормозить. Поэтому я окончательно мигрировал на хром. К сожалению. Ведь все самые удобные для меня расширения и фичи остались в фоксе.
Проблему нехватки ОЗУ решил установкой 8ГБ в ноутбук вместо 4-х. :-) Плюс, в линуксе в хром воткнул расширение Tab Suspender, которое выгружает неиспользумые вкладки по таймауту. В винде хром, видимо, как-то иначе подходит к управлению памятью, и там и без этого расширения памяти хватает на всё.
Цитата: wandrien от августа 9, 2017, 15:31
Я не знаю, как разработчикам фокса удалось всё сломать, но последние полгода-год хром у меня жрёт памяти лишь чуть больше, чем фокс. (А раньше фокс ел в разы меньше, чем и был хорош.) И к тому же, фокс стал дико тормозить. Поэтому я окончательно мигрировал на хром. К сожалению. Ведь все самые удобные для меня расширения и фичи остались в фоксе.
Проблему нехватки ОЗУ решил установкой 8ГБ в ноутбук вместо 4-х. :-) Плюс, в линуксе в хром воткнул расширение Tab Suspender, которое выгружает неиспользумые вкладки по таймауту. В винде хром, видимо, как-то иначе подходит к управлению памятью, и там и без этого расширения памяти хватает на всё.
palemoon. Сижу на 4ГБ и никуда не уйду.
Цитата: Toman от августа 9, 2017, 15:17
Это неправильно написанные программы
Вот поэтому realtime нельзя гарантировать (системы в целом, не только ядра ОС), если есть userspace, написанный third-party разработчиками.
Цитата: Toman от августа 9, 2017, 15:17
А в общем случае требования к работе десктопного компьютера в его современных применениях - именно реалтаймовые. Вся работа со звуком и музыкой - принципиально реалтаймовая, с видео - тоже. Компьютерные игры в очень значительной своей части (те, где симулируется какая-то более-менее правдоподобная физика, в частности, да и просто самые тупые аркады на скорость реакции) - тоже реалтаймовые по требованиям.
Одно дело — «как бы realtime», другое дело — «гарантированно realtime» :)
Цитата: Алексей Гринь от августа 9, 2017, 17:49
Одно дело — «как бы realtime», другое дело — «гарантированно realtime» :)
С какой бы это стати оно "как бы"? Если, например, всякая задержка с реакцией от заранее оговоренного интервала времени приводит "всего лишь" к потере пары часов рабочего времени (не говоря о нервах - и возможной невоспроизводимости в принципе потерянной работы) этак сотни человек, да даже и десятка, да даже и одного - имхо, это достаточная причина считать приложение требующим реального реалтайма, а не "как бы". Например, записывается целый оркестр, играли минут 40 без перерыва - и вдруг тут оказывается, что что-то, дескать, пошло не так, один блочок отсчётов не записался - и всё надо переписывать заново.
Или вот собрались с полсотни-сотню человек на мультиплеер по сети - и вдруг выясняется, что у кого-то одного из-за задержки в расчётах произошло физически невозможное или просто неадекватное реакции игрока событие принципиального характера - и все должны останавливать игру и возвращаться в лучшем случае к точке времени перед сбоем, а то и начинать всё с самого начала. Хотя, понятно, сетевые игрушки должны изначально уметь как-то обрабатывать задержки в сети (и это огромная принципиальная проблема), но за исключением физического столкновения игроков между собой это более-менее понятно, как разрешить, а вот локальный обсчёт физики, подразумевающий постоянную возможность реакции игрока (т.е. ускоренный обсчёт физики после задержки для нагона общего времени в принципе возможен - но не даёт возможности игроку адекватно реагировать в такие "нагоняемые" периоды времени)...
Цитата: Toman от августа 10, 2017, 01:19за исключением физического столкновения игроков между собой
Мордобоя, что ли? :what:
Это всё фигня. У людей минимальная реакция 80 мс, поэтому всё, что связано с десктопами, играми, и прочим — хренотайм, т.к. 80 мс это целых 5 квантов, что вечность для ОС. Другое дело фондовые биржи или управление ядерным реактором.
Цитата: Алексей Гринь от августа 10, 2017, 06:06
Это всё фигня. У людей минимальная реакция 80 мс, поэтому всё, что связано с десктопами, играми, и прочим — хренотайм, т.к. 80 мс это целых 5 квантов, что вечность для ОС. Другое дело фондовые биржи или управление ядерным реактором.
Не надо недооценивать говнокодеров. Просрать хоть 80 мс, хоть 8000 мс для программиста - раз плюнуть. 8-)
Цитата: wandrien от августа 10, 2017, 06:10
Не надо недооценивать говнокодеров. Просрать хоть 80 мс, хоть 8000 мс для программиста - раз плюнуть. 8-)
Но зато в играх, если время просрано, то можно пересинхронизировать с сервером, синтерполировав позиции, или просто телепортировав, потому что «и так сойдёт». Игрок поплюётся на лаги и всё этим закончится. Другое дело ядерный реактор...
С играми ситуация сложная, т.к. между клиентом и сервером среда передачи данных с непредсказуемой задержкой.
А вот когда в компьютере мышка тормозит, в консерватории что-то не так.
Цитата: Алексей Гринь от августа 10, 2017, 06:06
Это всё фигня. У людей минимальная реакция 80 мс
Деятельность человека не состоит только из реагирования на неожиданно (внезапно) возникшие стимулы. Очень большая часть движений просчитывается заранее и согласуется с другими предшествующими движениями - и там допуски гораздо строже. В музыке короткие ноты имеют продолжительность менее 80 мс - и при этом всё равно должны играться либо ровно, либо с точно дозированной исполнителем агогикой, какое-нибудь гениальное исполнение от какого-нибудь скучно-механистичного может отличаться на первые единицы миллисекунд. А ошибка на 80 мс - это уже ошибка такого масштаба, которая выражается другим написанием нотами того, что прозвучало. Аналогично, такого размера ошибка при передаче морзянкой - это гарантированно ошибочный код.
Или если задержаться с каким-то движением на 80 мс при ходьбе, беге или танце - падение практически неизбежно.
Цитата: Алексей Гринь от августа 10, 2017, 06:06
хренотайм, т.к. 80 мс это целых 5 квантов, что вечность для ОС
Но даже если для какого-то конкретного применения время реагирования приложения в пределах порядка 1 мс или меньше не требуется, но таки требуется гарантированное время реагирования порядка 100 мс или даже секунды - это всё равно настоящий реалтайм, поскольку нереалтаймовая система не гарантирует и 100 мс, и вообще никакого гарантированного времени. Вообще-то говоря, при наборе текста задержка показа набранного даже в 100 мс заметна и раздражает, однако вот хотя бы тут на ЛФ в форме ответа задержка показа набранного частенько достигает секунды-двух (как сейчас как раз), нескольких секунд, а порой и нескольких десятков секунд (видимо, как раз когда ФФ выжирает достаточно много памяти).