LINUX.ORG.RU
решено ФорумTalks

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

 ,


0

2

здрасьте здрасьте уважаемые форумчане

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

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



Последнее исправление: Assembler (всего исправлений: 1)

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

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

Assembler
() автор топика
Последнее исправление: Assembler (всего исправлений: 1)
Ответ на: комментарий от Assembler

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

Assembler
() автор топика
Ответ на: комментарий от Assembler

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

pinus_nigra
()
Ответ на: комментарий от Assembler

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

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

aureliano15 ★★
()
Последнее исправление: aureliano15 (всего исправлений: 1)
Ответ на: комментарий от pinus_nigra

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

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

aureliano15 ★★
()
Ответ на: комментарий от Assembler

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

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

greenman ★★★★★
()

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

xwicked ★★☆
()
Ответ на: комментарий от xwicked

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от aureliano15

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

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

Stack77
()
Ответ на: комментарий от Stack77

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от Stack77

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

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

X512 ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

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

Stack77
()
Последнее исправление: Stack77 (всего исправлений: 1)

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от xwicked

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

Assembler
() автор топика
Ответ на: комментарий от Assembler

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

PolarFox ★★★★★
()
Ответ на: комментарий от Assembler

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

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

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

Assembler
() автор топика
Ответ на: комментарий от torvn77

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

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

torvn77 ★★★★★
()
Ответ на: комментарий от Assembler

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

arm-2G x86-8G

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

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

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

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

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

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

Assembler
() автор топика

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

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Ответ на: комментарий от Assembler

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

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

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 2)
Ответ на: комментарий от X512

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

cobold ★★★★★
()
Ответ на: комментарий от Assembler

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

kott ★★★★★
()
Ответ на: комментарий от torvn77

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

Pinkbyte ★★★★★
()

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Assembler

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

ArkaDOSik ★★
()
Ответ на: комментарий от X512

в 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
i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

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

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

./gimp-2.10-armhf

Thumb-2?

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 2)
Ответ на: комментарий от X512

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

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

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

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

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

Thumb-2?

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

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.