Фигней страдаешь.

Возможно мы на пороге важного открытия

Какого? Что 32-битные программы расходуют меньше памяти? Великое открытие.

Возможно мы на пороге важного открытия ;)

А потом сколько криков будет, что перестали выпускать 32-битные версии библиотек и софта :)

Для embedded еще доооолго 32-bit будут выпускать.

Возможно мы на пороге важного открытия ;)

Как сейчас, не знаю. Но было время, когда 32-х битный Хром жрал в 5-7(!!) раз меньше памяти, чем 64-х битный. Даже представить не могу, как они так умудрились :)

Говорят, можно по-другому

А что, можно было?

Дата регистрации: 04.09.2009 12:44:10
...
Первая созданная тема: 22.10.2018 9:26:26
Последняя созданная тема: 22.10.2018 9:26:26
...
Первый комментарий: 04.09.2009 12:52:17
...
Число комментариев: 26

Смотри лучше в сторону wget + костыли под ресурс.

было время, когда 32-х битный Хром жрал в 5-7(!!) раз меньше памяти, чем 64-х битный. Даже представить не могу, как они так умудрились :)

Я могу представить. Но это не они умудрились, а вы. Chrome, как и Firefox, может использовать свободную память для своих буферов (в них в основном хранится содержимое открытых вкладок). Больше свободной памяти - больше может использовать под свои буфера. Отсюда нескончаемые вопли о том, что Chrome якобы хавает слишком много памяти. На самом деле не слишком много, так как он использует свободную память. Если вы сравнили 32-битный Chrome на ПК с 1 ГБ памяти и 64-битный Chrome на ПК с 4 ГБ памяти, то могли увидеть, что во втором случае Chrome потребляет больше памяти. Но это было потому, что свободной памяти было больше. То же относится к нынешнему Firefox.

Идея автора лишена смысла. Если в 64-битном Linux с экономной графической оболочкой - LXDE, LXQt или XFCE - запустить 64-битный Firefox с небольшим количеством вкладок, то потребление памяти не превысит 1 ГБ, хотя для 64-битной Linux всё равно рекомендуется память от 2 ГБ.

Ну сэкономишь десять мегабайт из гигабайтов, дальше что?

Ты про стим из коробки что в 16.04 64бит?

Ты не сэкономишь так. Помимо того что 32 битные либы будут занимать очень много памяти в довесок к 64 битным (и они как правило очень хреново собраны), ты потеряешь 2/3 процессора, и прочие сайдэффекты. Собирай чистую no-multilib систему (уж точно не убанту), вот уж где экономия будет. Никаких 32 битов нигде, отключи их поддержку в ядре если не собираешься проприетарщину использовать.

А так конечно ты хочешь x32abi — возьми, собери, будь успешен. Принеси пользу комьюнити. Никто не скажет что ты хернёй страдал.

За столько лет на планку памяти не заработать. Типичный лор.

Ерундой занимаешься.

Держать не диске по сути две копии библиотек. Держать их же в памяти. Иметь очень ненулевой шанс словить веселые финты при вылезании программы за два гига адресного пространства.

Оно тебе надо?

Да не , 4 байта аффтар съекономил .

Больше свободной памяти

Очевидно, что речь о работе в равных условиях. При нехватке оперативки.

На самом деле не слишком много, так как он использует свободную память.

Ага. Такую свободную, что приложения в своп загоняются и машина в глубокий iow уходит :)

Если вы сравнили 32-битный Chrome на ПК с 1 ГБ памяти и 64-битный Chrome на ПК с 4 ГБ памяти

Не нужно каждого собеседника держать за идиота. В обоих случаях речь шла о забитой памяти на 3Гб машине.

важнее ставить расширения типатого

auto unload tab, unload tab on select.
а вообще мысль интереснаяа какими расширениями пользуетесь?

В моей системе 8 Гб оперативки. При запуске VirtualBox виртуалке с 2 Гб RAM и Firefox c 8 вкладками часто наступал момент когда система становилась неюзабельной-минут 20 (насколько хватало терпения) непрерывного своппинга.

Кстати, на это я нашел управу. Что-то с cgroups связанное, включающее еще и kernel boot time параметр. Сейчас отыскиваю в истории браузера решение.

Жду 16-битный ФФ.

auto unload tab, unload tab on select. - не знал что есть такие расширения. Я думаю Firefox должен сам понимать что система начала свопиться и «замораживать» скрипты на неактивных вкладках- чтобы они складывались в своп и не доставались от туда какое-то время.

AdBlock, FlashBlock, NoScript, ImgBlock, Grammarly, RescueTime, SaveTiddlers, Stylish!

За наводку на x32abi спасибо, не знал что есть такая инициатива. Это может сработать.

Я думаю программы, использующие кучу указателей, должны сами позаботиться чтобы хранить 64-битный адрес начала memory pool (например, заводить по одному memory pool на вкладку) и 32-битные смещения в нем вместо прямых указателей. Т.е. в регистрах процессора будут 64-битные адреса, а в памяти у древовидных структур, хранящих DOM деревья, java script и прочее- 32-битные смещения только.

в носкрипте есть опция останавливать скрипты на закрытых вкладках

еще есть смысл все worker отключать из конфига.
первый из названных в настройке блокирует загрузку страниц при возобновлении сессии

поставил, норм, автору спасибо для youtube еще это поставил https://addons.mozilla.org/ru/firefox/addon/youtube-classic/?src=search

А так конечно ты хочешь x32abi — возьми, собери, будь успешен.

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

[[ ${ABI} == x32 ]] && myconf+=( --disable-asm )

У меня установлен NoScript 10.1.9.9 - в нем нет настройки чтобы останавливать скрипты на закрытых вкладках.

Возможно была раньше- с переходом на Firefox 52 им же (и всем остальным) пришлось переписать свое расширение. Теперь для написания расширений используется Хромовский API для единообразия, а свой мозиловский они решили забросить.

я не совсем точно описал опцию, что не сказать совсем не..

-автоматически перезагружать страницЫ при изменении разрешений
-презагружать только текущую страиницУ

по умолчанию они отмечены. это в general - основной вкладке

но есть другой баг

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

Не нужен нам ваш асм, нам экономным некуда спешить, оставим файрфокс рендерить страницу на ночь!

Все правильно торопятся вперед бати линуксов и не нужно

Я запускал виртуалку с 3 гигами (ну мне одно приложение, я знаю что меньше 8 нельзя выделять) и жирнолис жравший под 5 гигов памяти рядом себя вполне комфортно чувствовал. И это кеды с плазмой и всем остальным. Когда он 6+ начинал выжирать у меня кончался своп и виртуалка падала (можно успеть убить жирнолис когда своп только кончился и пошли затупы) через несколько минут. Или жирнолис. Никаких cgroups, ничего. У тебя точно был линукс на хосте?

Может ты своп забыл включить? Пока он есть, никаких проблем. Более серьёзно что виртуалку с ionice приходилось запускать, чтобы хост не тупил.

Возможно мы на пороге важного открытия ;)

Ага, и называется оно x32.

Маргинальщина из 10. Надо было по умолчанию так делать, а long pointer оставить в спец режиме для серверных поделок и ядра.

У меня на хосте Ubuntu 16.04 x64

Виртуалка- другое дело. Она хоть и уходит в глубокий своп, то так как хост имеет много памяти, то, что для виртуалки своп, на хосте кешируется, и поэтому свопится виртуалка быстро.

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

x32abi ... Принеси пользу комьюнити.

/0

Никто не скажет что ты хернёй страдал.

Я скажу.

Случайно заглянув в исходники OpenSSL 1_0 заметил такой любопытны комментарий (кстати, в master бранче этого уже нет):

#if defined( OPENSSL_SYS_VMS) && (__INITIAL_POINTER_SIZE == 64)
    /*-
     * 2011-03-22 SMS.
     * If we have 32-bit pointers everywhere, then we're safe, and
     * we bypass this mess, as on non-VMS systems.  (See ARGV,
     * above.)
     * Problem 1: Compaq/HP C before V7.3 always used 32-bit
     * pointers for argv[].
     * Fix 1: For a 32-bit argv[], when we're using 64-bit pointers
     * everywhere else, we always allocate and use a 64-bit
     * duplicate of argv[].
     * Problem 2: Compaq/HP C V7.3 (Alpha, IA64) before ECO1 failed
     * to NULL-terminate a 64-bit argv[].  (As this was written, the
     * compiler ECO was available only on IA64.)
     * Fix 2: Unless advised not to (VMS_TRUST_ARGV), we test a
     * 64-bit argv[argc] for NULL, and, if necessary, use a
     * (properly) NULL-terminated (64-bit) duplicate of argv[].
     * The same code is used in either case to duplicate argv[].
     * Some of these decisions could be handled in preprocessing,
     * but the code tends to get even uglier, and the penalty for
     * deciding at compile- or run-time is tiny.
     */

Видимо где-то уже делали 64-битный ABI с 32-битными указателями и наверняка огребли чего-нибудь. Так что может не такие уж они и раздолбаи, разработчики linux64-ABI.

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/apps/openssl.c#L234