Raspbian переходит в 64-битный режим

В этой странице официальное объявление RPi3 гласит:

  

Вам понадобится последнее изображение NOOBS или Raspbian с нашей страницы загрузки. При запуске мы используем одно и то же 32-битное пользовательское пространство Raspbian, которое мы используем на других устройствах Raspberry Pi; в течение следующих нескольких месяцев мы будем исследовать, есть ли значение при переходе в 64-битный режим.

Мой вопрос заключается в том, что процессор имеет 64 бита, не так ли очевидный , что работа с ОС на 64 бита будет лучше во всех отношениях? Что мне не хватает?

43 голоса | спросил zundi 11 MarpmFri, 11 Mar 2016 16:17:55 +03002016-03-11T16:17:55+03:0004 2016, 16:17:55

8 ответов


52
  

, учитывая, что процессор имеет 64 бита, не очевидно ли, что работа с ОС на 64 бита будет лучше во всех отношениях?

Нет, на самом деле это не так. В некотором смысле работа 64-разрядной операционной системы может ухудшить производительность малины.

Преимущества 64-разрядного :

Двумя основными преимуществами использования 64-разрядного процессора /операционной системы являются то, что устройство может обрабатывать более 4 ГБ ОЗУ и изначально обрабатывать целые числа, превышающие 2 ^ 32, без необходимости bignum.

У малины Pi не более 4 ГБ ОЗУ. При 1 ГБ оперативной памяти вы полностью потеряли первый из двух основных преимуществ. Что касается второго преимущества, то какой процент людей фактически использует достаточно гигантские цифры, что имеет смысл для фонда поддержать всю вторую операционную систему? Кроме того, RPi может использовать огромные числа с помощью программных методов, но похоже, что если вы будете последовательно в этом мире, вам все равно нужно использовать лучшее оборудование.

Проблемы с 64-разрядным :

Способность хранить большее количество не предоставляется магией. Скорее, размер объектов памяти должен быть увеличен. В C (и C ++) это означает изменение int на int64_t. Это не делается автоматически, поэтому комментарии о фундаменте не желают поддерживать две ветви.

Кроме того, многие приложения просто не обеспечивают преимущества (для большинства пользователей) при работе в режиме 64 бит. Обратите внимание, что большинство веб-браузеров, MS Office и целый ряд других популярных программ все еще отправляются и поддерживаются 32-битным способом. Конечно, вы можете получить 64-разрядную версию MS Office, но она редко используется.

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

Также обратите внимание :

Просто потому, что вы работаете на 64-битной машине, это не значит, что приложение не работает как 32 бит. Windows делает это очень ясно, имея два разных пути установки, C: \ Program Files и C: \ Program Files (x86).

Итак, будет ли основание, возможно, поддерживать 64-битную поддержку? :

Мы вернулись к тому же пункту: «Некоторые люди могут видеть выгоду, но большинство не будет». Вы, конечно же, увидите другие проекты, предлагающие 64-битные сборки, но если фонд не получит много незаслуженной (imo) flack, они, вероятно, не будут и не должны (imo). Создание и поддержка отдельной 64-разрядной ветви - это не маленькая задача, и, честно говоря, просто не стоит этого.

ответил Jacobm001 11 MarpmFri, 11 Mar 2016 19:17:42 +03002016-03-11T19:17:42+03:0007 2016, 19:17:42
16

Стоит отметить, что ситуация для ARM и Intel /AMD отличается. Это связано с тем, что переход на x86_64 также использовался в качестве возможности для обновления плохо устаревшей архитектуры, в основном искалеченной только наличием 8 регистров общего назначения и удвоенной в 64-битном режиме. Таким образом, переключение системы Intel /AMD на 64-битный режим также означает включение реальных функций, которые существенно влияют на производительность.

ARM не имеет этой проблемы для начала (хотя AArch64 добавляет регистры, 32-разрядные архитектуры не были голодными для них), поэтому преимущества в основном представляют собой более непосредственно адресуемую память и встроенную поддержку большого целого - менее значительная сделка и, возможно, противодействует недостатку (больше памяти используется для всего).

(В стороне, по этой причине, была некоторая работа по созданию "x32" abi для Intel /AMD Linux , сохраняя усовершенствования процессора, но используя 32-разрядные указатели.)

ответил mattdm 11 MarpmFri, 11 Mar 2016 20:49:12 +03002016-03-11T20:49:12+03:0008 2016, 20:49:12
5

В рамках публичной рекламы запуска я заметил, что одна проблема - это усилия, необходимые для поддержки двух отдельных кодовых баз (32 и 64 бит). в видеоролике Adafruit PI3 Launch также упоминалось, что переход на 64-битный процессор связан с увеличением тактовой частоты нового чипа, кроме использования 64-битного режима.

ответил Steve Robillard 11 MarpmFri, 11 Mar 2016 16:21:39 +03002016-03-11T16:21:39+03:0004 2016, 16:21:39
5

Я уверен, что уже есть люди, которые запускают Debian Aarch64 (ARMv8) на Pi 3; это, конечно, было бы не так сложно для многих людей ( см. здесь для некоторых подсказок о том, что это может сработать) 1 , хотя для пользователей most это, вероятно, немного растягивается.

Однако, если Raspbian и /или Foundation не выходят с 64-разрядной версией, вы все чаще будете видеть людей с блогами и т. д., объясняя, как запускать один и все еще получать полезные свойства.


Теперь существует версия Fedora aarch64 для Pi 3.


1. Будут некоторые осложнения с 32-битным /opt /vc материалом, я не уверен, насколько это преодолено; Раньше существовали 32-разрядные совместимые libs для x86-64, но Aarch64 ... может быть, нет.

ответил goldilocks 11 MarpmFri, 11 Mar 2016 18:21:49 +03002016-03-11T18:21:49+03:0006 2016, 18:21:49
2

Адресация утверждения о том, что 64-разрядные собственные программы больше (больше памяти для данных и указателей), и что нет заметных преимуществ для 64-разрядной 32-разрядной ОС на ARMv8 с объемом памяти менее 4 ГБ, я хочу поднимите несколько очков.

Есть некоторые существенные различия в том, как делаются в ARMv7 (и раньше) и ARMv8, архитектурно, что делает выполнение ARMv8 более эффективным. Некоторые из них относятся к более широким внутренним маршрутам данных, некоторые - к устранению особых случаев и к значительно более глубокому конвейеру). Эти же изменения делают ARMv8 лучше при запуске ARMv7 (32-битного) кода.

Нативные 64-разрядные приложения используют 64-разрядные указатели, а 'size_t' - 64 бит, поэтому элементы, использующие их, становятся больше. Остальная часть данных будет иметь одинаковую величину. Однако значимость этого незначительна для размера исполняемых изображений.

В тех случаях, когда 64-битный native действительно светит (если вы не заботитесь о больших целых и с плавающей запятой) имеет большее виртуальное адресное пространство:

  • ОС может разделить виртуальное адресное пространство на все более крупные разделы, позволяя упростить управление разделяемыми ресурсами, более упрощенные контекстные переключатели между разными уровнями привилегий и т. д.
  • Если вы включили подкачку, вы можете запускать все больше и больше процессов, превышающих пределы физической памяти (это действительно так и в 32-битном режиме, но вы менее ограничены в 64-битной версии).

В настоящее время ОС использует это или нет, это будет иметь значение, поскольку основной поток удаляется от 32 бит.

Я думаю, что лучшим аргументом для перехода на собственное 64-битное ядро ​​AArch64 является переносимость: основной рабочий стол переместился в основном 64-разрядные процессоры, и я вижу больше пакетов, которые принимают 64 бита, и переносит такой код на 32 бит сложнее, чем перенос от 32 до 64 бит. В пользовательском пространстве вы можете запускать 32-разрядные приложения и 64-разрядные приложения бок о бок, предполагая, что вы установили многоадресные библиотеки, поэтому не требуется переносить 32 до 64 бит, где это не дело. 64-разрядная ОС просто собирается предоставить вам больший выбор программного обеспечения.

Я не говорю, что создание 64-битного ядра для Raspberry PI 3 простое - есть существенные различия, требующие изменений на низком уровне, не все драйверы устройств имеют 64-битную чистоту (особенно драйверы для конкретных графических процессоров ARM) , Возможно, Raspberian останется 32-битной ОС, но я считаю, что (в дальнем диапазоне) это недальновидно.

Один загрузочный носитель (например, SD-карта) может содержать как 64, так и 32-разрядные версии ОС, а дополнительное программное обеспечение для загрузки (u-boot, arm-boot и другие) может определить, какой из них загружать. Более жесткая часть - userland - файловая система должна быть многоархивой, даже на 32-битных системах, где 64-битные вещи будут бесполезны. Я хотел бы обратиться к этому с помощью скрипта или утилиты, которая может быть запущена после начальной загрузки, чтобы удалить ненужные библиотеки и исполняемые файлы программы на 32-разрядных системах.

ответил Daniel Glasser 19 Maypm16 2016, 17:04:22
2

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

  • Когда PHP обрабатывает временные метки Unix, целочисленный размер в 32-битной дуге устанавливает верхний предел дат, так что они не могут выйти за рамки конкретный день в 2038 году . Я ожидаю, что это проблема для всех языков, которые обрабатывают временные метки. (К счастью, большинство подсистем с обработкой даты, которые не используют временные метки Unix, такие как DateTime для PHP, специально не предназначены для этой проблемы даже для старых процессоров).
  • Mongo ограничена базами данных размером 2G по этой арке, а 32-разрядные сборки скоро будут устаревать. Из руководства :

      

    Начиная с MongoDB 3.2, 32-битные двоичные файлы устарели и будут недоступны в будущих выпусках.

         

    Хотя 32-разрядные сборки существуют для Linux и Windows, они не подходят для производственных развертываний. 32-разрядные сборки также не поддерживают механизм хранения WiredTiger.

ответил halfer 11 J000000Monday16 2016, 12:09:07
2

64-разрядная адресация может быть полезна, даже если у вас не более 1 ГБ памяти.

Он позволяет вам хранить большие файлы памяти, поэтому у вас есть указатель, и пусть ОС делает I /O прозрачно. Еще один способ делать I /O. Для больших файлов вам нужна 64-разрядная адресация.

Другим примером, где я вижу это может быть полезно, чтобы позволить процессам иметь более 2 ГБ адресного пространства, используя пространство подкачки. Недавно у меня возникла проблема с 32-разрядным NAS с большим количеством хранилищ и поврежденной файловой системой. В процессе fsck закончилась нехватка памяти, даже при включенном кешировании. Добавление пространства подкачки не могло решить проблему, 32-разрядное адресное пространство было жестким пределом. Поэтому просто не было возможности запустить fsck на этой большой поврежденной файловой системе с 32-битным двоичным кодом. С 64-битным двоичным и некоторым местом подкачки он должен был работать.

ответил GTC 2 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 02 Sep 2016 04:26:48 +0300 2016, 04:26:48
-4

Мои мысли по этому поводу: Хотя я точно не знаю, как ARM-процессор обращается к памяти, я могу рассказать об этом из предыдущих нескольких архитектур процессора, которые я запрограммировал (SPARC /Alpha /i386 /AMD64 /X86_64): при использовании разделяемой памяти и адресации по ее «реальному» указателю виртуального адреса переход на 64-битный не является тривиальным. Хотя memcpy делает то, что он должен делать, вам нужно учитывать, что в 64 бит данные хранятся как это (бит назад):

HGFEDCBA
HGFEDCBA
HGFEDCBA

еще в 32 бит выглядит так:

ABCD
ABCD
ABCD

Итак, в 32 битах, когда вы храните, скажем, jpeg в ОЗУ, вы можете читать его байты заголовков или обнаруживать грани, без каких-либо проблем линейным способом, скажем, путем перехода байта вперед. Но в 64-битной архитектуре это изменяется:

32bit:

 for (i = 0; i <img_length /4; i ++)
{
    адрес = shm_start + I;
    для (c = 0; c <4; c ++)
    {
        byte = ((* address> c) & 15)
    }
}

64bit:

 для (i = -; i <img_length /8; i ++)
{
    адрес = shm_start + I;
    для (c = 7; c> = 0; c--)
    {
        byte = ((* address> c) & 15)
    }
}
ответил bobx 14 MarpmMon, 14 Mar 2016 13:37:56 +03002016-03-14T13:37:56+03:0001 2016, 13:37:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132