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

Архитектура память не потребляет.

скажите пожалуйста почему arm архитектура потребляет меньше оперативной памяти, чем x86?

По идее наоборот: в x86 более компактное кодирование инструкций и не требуется выравнивание для обращения к памяти.

В ARM есть более компактный Thumb, но его нет для 64 бит.

ок. исправлю

Архитектура память не потребляет.

Кодирование инструкций очень даже потребляет.

скажите пожалуйста вашу версию, почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

тогда скажите пожалуйста почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

Может быть на ARM нету/другое видеоускорение. Также надо уточнять как именно мерили память, какая ОС, что открыто во вкладках и т.д..

спасибо. в htop посмотрел Linux и там и там. Armbian(arm64) и Ubuntu(x86) ну это я так. не для того чтобы вы прям сказали точно. просто написал потому что вы спросили

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

почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

Код для RISC-процессоров обычно занимает больше места, чем для CISC. Arm — RISC, а Intel — CISC. Однако в наше время размер кода практически не играет никакой роли по сравнению со всем остальным. Особенно, когда речь идёт о браузере. Там куда больше потребляется выделяемой памяти для хранения кэшей, картинок и прочей фигни. Причём разные браузеры и память потребляют по-разному. Например, firefox резервирует относительно много памяти, а собираемый на его основе palemoon за счёт более частого обращения к диску — намного меньше. 1-е выгоднее для компов с большим объёмом памяти, на которых firefox будет работать быстрее, а 2-е — для слабеньких компов. Подозреваю, что браузеры для arm написаны так, чтоб изначально не потреблять слишком много памяти, т. к. сами компы на arm обычно слабее. Но к самой архитектуре arm это потребление не имеет отношения. Всё сказанное — чисто теоретические рассуждения, т. к. реально я не замерял, сколько потребляет браузер, скомпилированный для arm, и тем более не дебажил его код.

Попробуй что-то попроще. В гимпе проект открыть, например.

Я думаю, что и в gimp’е потребление памяти может быть разным и заточено под средние объёмы памяти для типичных arm’ов и intel’ов. Самым чистым, на мой взгляд, экспериментом было бы написать несколько собственных кросс-платформенных программулек, которые для всех архитектур резервировали бы одинаковые буферы или не резервировали бы их вообще, скомпилировать их для arm и intel одним компилятором с одинаковыми опциями компиляции и посмотреть.

почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

А какой объём памяти установлен на этих системах arm и x86?

Это понты всё. Ядро NT в оффтопике ест 46КБ(!). Всё зависит от компилятора той или иной платформы, кто сколько мусора добавляет. Сйчас нам показывают преимущество, а через время перестанут оптимизировать и станут столько же мусора пихать. Говорю как программист.

Сйчас нам показывают преимущество, а через время перестанут оптимизировать и станут столько же мусора пихать. Говорю как программист.

А можешь ли ты говорить как хороший программист?

Код для RISC-процессоров обычно занимает больше места, чем для CISC. Arm — RISC, а Intel — CISC.

А разве у Intel не RISC под капотом? CISC это ведь просто абстракция, и на самом деле CISC инструкции преобразуются в RISC ядра.

А разве у Intel не RISC под капотом? CISC это ведь просто абстракция, и на самом деле CISC инструкции преобразуются в RISC ядра.

А это уже не так важно. Бутылочное горлышко находится в шине памяти. Т.е. из-за большего объёма кода процессор может всасывать меньше данных при том же размере шины.

А разве у Intel не RISC под капотом?

То, что под капотом, память не занимает. Оно может занимать только внутренние кеши, которые ОС не видит.

Ну да, логично. Разницы нет, код то храниться в ОЗУ в CISC. Затупил :)

То, что под капотом, память не занимает. Оно может занимать только внутренние кеши, которые ОС не видит.

Да-да. Не знаю к чему я это сказал. В контексте темы значения не имеет.

Если речь про вкладки браузера, то явно не кодом забита память. Если malloc(1024 * 1024) на x86 и на arm будет не 1 мегабайт и отличаться, то можно будет удивиться

arm-2G x86-8G

это хоть как-то для меня объясняет происходящее. спасибо

Есть ощущение, не знаю насколько близко к истине, что браузеры могут «позволять себе» потреблять больше памяти на системах, в которых этой памяти изначально больше.

скажите пожалуйста вашу версию, почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

1. Браузер показывает страницу в десктопном или мобильном виде?
2. В десктопном бромзере точно нет места для оптимизаций?
   А то могли там расплодить мусора.

desktop. про опимизацию не знаю. я не оптимизоровал, это точно

интересно

Chromium и там и там

В десктопном бромзере точно нет места для оптимизаций? А то могли там расплодить мусора.

Pinkbyte, расскажи нам пожалуйста про USE флаги хромиума и огнелиса.

Я выше задал вопрос, думаю что лучше гентушников тебе никто не ответит, разве что сами разработчики браузеров.

скажите пожалуйста вашу версию, почему браузер с 12 открытыми вкладками на arm потербляет 1,3G оперативной памяти, а на x86 3.4G ?

arm-2G x86-8G

Ну как бы в первом случае выделить 3.4 arm не может. Так что он работает в более экономном режиме. Оставь на x86 только 2ГБ и сравни

не могу. одна планка на 8G

cпасибо

не могу. одна планка на 8G

Исследование процессорных архитектур уровня толксов)

Так что он работает в более экономном режиме.

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

я не исследую. тема в Talks. просто делимся предположениями.

Ещё моё личное наблюдение. что все программы поголовно, может DE в Линуксах и в оффтопике, когда есть своп и ОЗУ достаточно 4 и >4, то он зачем-то обращается к диску, снижая работу всех программ. Было замечено на P4 3ГБ ОЗУ на оффтопике 7 и GNU / Linux Debian не помню какой версии с KDE. Эта фантастика необъяснима...
Отключаешь своп и работа всего ускоряется на 20%

а swap вы как отключали? в ядре?

mem=2G ядру

а swap вы как отключали? в ядре?

Уже не помню, может просто не монтировал, х3, нужно почитать
А в оффтопике, чтобы обратиться к конкретному файлу, чтобы открыть на запись или чтение, то все проги или Delphi судорожно обращается ко ВСЕМ дискам по 10 раз и только потом открывает нужный файл, может указывать, что все языки программирования пишуться для наиболее быстрого убийства всего железа. Через ProcessMonitor следил за своей или чужой прогой. Уже в 16 лет я начинал понимать, что что-то в этом мире не так и начал снимать «розовые очки». Так же и с АРМ создают видимость прогресса, скорее всего.

очень локанично. еще бы пониять что вы хотели сказать.

Код ерунду потребляет по сравнению с данными

объём памяти можно уменьшить не только физически
так понятно?

Параметр ядра при загрузке.

А чего я-то сразу? Я ни разу не мейнтэйнер браузерных пакетов, я без понятия о внутренней кухне соответствующих проектов. Могу только судить с позиции обычного разработчика о том, что в тех же ебилдах Firefox/Chromium кладут прибитые гвоздями версии разных библиотек «абы чего не вышло», что намекает на то, что там всё достаточно хрупкое(куча юзов вида «system-*» тому подтверждение).

Современный ARM - это 64-битная архитектура, также как и amd64.

Учитывая что речь идет о браузере, то скорее всего какое-то кеширование прибили гвоздями к x86/amd64

Добавь параметр ядра mem=2G (в дебиане это в /etc/default/grub в переменной GRUB_CMDLINE_LINUX_DEFAULT) и из твоих 8 ГБ будет использоваться 2.

в x86 более компактное кодирование инструкций

Безосновательное утверждение. В данном вопросе лучше измерять.

$ find . -type f -printf "%s bytes, %p\n" | sort
4932340 bytes, ./gimp-2.10-armhf
7566928 bytes, ./gimp-2.10-arm64
7570720 bytes, ./gimp-2.10-amd64
8810916 bytes, ./gimp-2.10-i386

$ file *
gimp-2.10-amd64: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6a5a97bae87bb0f73723f01ce5cbe0006522e8fd, stripped
gimp-2.10-arm64: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=1e67f73938ff83fbab1dbe23b25d82572cd7fb60, stripped
gimp-2.10-armhf: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=365dbef3327b448c87e82e78e7eab64e57177a57, stripped
gimp-2.10-i386:  ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=5a56cddb418553f4e42eb66a0c9148bb7543ddcd, stripped

Безосновательное утверждение.

Я исхожу из этих документов.

В данном вопросе лучше измерять.

Конкретные результаты сильно зависят от флагов компиляции и используемого кода.

./gimp-2.10-armhf

Thumb-2?

этих документов.

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

Опять-таки, нужно измерять на реальных примерах.

Конкретные результаты сильно зависят от флагов компиляции и используемого кода.

Конечно зависят! Поэтому в этом вопросе нужно измерять, а не теоретизировать.

Thumb-2?

Не знаю. Я с этим вопросом так и не разобрался, а потом забил.