Почему на Raspberry Pi4 стоит поставить 64-битную ОС


Предыдущая | Следующая
image

Одно из преимуществ работы на компанию, занимающуюся производством программ, заключается в том, что вам часто представляется возможность протестировать прототипы нового железа. Однако не в данном случае – я купил себе Raspberry Pi4 потому, что она очень дешёвая!

На Raspberry Pi4 стоит четырёхъядерный ARM Cortex A72, до 4 ГБ памяти и гигабитный порт Ethernet – и всё это всего за $35.

На Raspberry Pi4 есть ОС Raspbian (на основе Debian), и готовая библиотека продуктов, поэтому я вставил в неё SD-карточку, чтобы побыстрее загрузиться. Я искал syslog и заметил, что и ядро, и все пользовательские программы скомплированы как armv7 – то есть, для 32-битной памяти.

Я знаю, что Raspberry Pi4 поддерживает 64 бита, поэтому я не захотел запускать на ней 32-битную ОС. Я взял другую карту памяти и поставил на неё Debian. Debian, не содержащий ничего лишнего, скомпилированный как aarch64 – что означает 64-битную память.

Загрузив 64-битную ОС, я заинтересовался, насколько лучше она работает 32-битной, поэтому провёл несколько тестов.
 

Синтетические тесты скорости


Первое, что пришло мне в голову, был старый тест dhrystone, существующий с начала времён. Эту программу написали в 1988 году, и она занимается математическими вычислениями. Она вряд ли способна симулировать современную нагрузку, и мы можем использовать её только для того, чтобы сохранить некую связность со старым железом и программами.



Современное приложение, обрабатывающее цифры, лучше симулировать вычислением хэшей, поэтому я захотел провести тест с SHA1. К сожалению, утилита sha1sum скомпилирована без поддержки libssl или криптографических функций ядра, поэтому мне пришлось компилировать её из исходников.

Чтобы избежать узких мест в I/O, я подсчитываю хэш файла размером 2 Гб с опцией truncate -s 2GB, так что никакого ввода и вывода данных с карты не было:



SHA1 – более реалистичный тест, чем dhrystone, поскольку этот алгоритм используется в большом количестве приложений – торрентах, git, и т.п.
 

RAM


64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись. Я написал простую программу, размещающую большой буфер – она его пишет, а потом читает. Чтобы гарантировать реальное выделение памяти я использовал mlock(). В данном тесте объём буфера равен 2 ГБ: буфер в 3 ГБ работал в 64-битном режиме, а в 32-битном выдавал ошибку «недостаточно памяти».


 

Кодирование аудио


Я обратил внимание на то, что многие пользователи Raspberry Pi4 используют компьютер в качестве медиацентра, поэтому я запустил задачи на кодирование аудио с двумя самыми популярными кодеками.

Я кодировал композицию Pink Floyd «Echoes», потому что это довольно длинный трек, и с него можно получить измеряемые значения. Чтобы избежать I/O задержек, исходник и конечный файл хранились на ramfs:




 

Сетевые замеры скорости


Ещё один вариант использования Raspberry Pi4 – в качестве VPN или файервола. Не рекомендую использовать такие системы в подобных целях, но у многих людей всё ещё есть медленное подключение к интернету (менее 100 Мб), поэтому они могут не обращать внимания на медленную работу Raspberry Pi4.

Первый вопрос: сколько трафика способна обработать Raspberry Pi4? Нам нужно измерить чистую сетевую мощность компьютера, без ограничений физических интерфейсов, поэтому я запустил сессию iperf3 между двумя контейнерами. Однако контейнеры обмениваются данными через пару veth, а veth ускоряет трафик посредством ложных разгрузок.

Разгрузка подсчёта контрольной суммы IP осуществляется просто отказом от её подсчёта, а разгрузка сегментации TCP – отказом от сегментации и повторной сборки трафика: большой кусок данных на 64К просто передаётся в память как есть.

Чтобы избежать таких моментов, я запретил разгрузку командой

ethtool -K veth0 tx off rx off tso off gro off gso off


 

Firewall


Самое быстрое, на что способно сетевое оборудование – отбрасывать часть трафика, а быстрее всего это делать через правило TC. Чтобы не доходить до максимально возможной скорости, я использовал минимальный размер фрейма Ethernet, 64б.



Хотя обе системы не дошли до максимальной скорости передачи (1,5 Мб/с), 64-битное ядро показало чуть большую скорость, чем 32-битное. Если вы хотите использовать Raspberry Pi4 в качестве файервола, обязательно используйте ядро на 64 бита.
 

VPN


Ещё один частый вариант использования Raspberry Pi4 – VPN-сервер, а точнее, OpenVPN. Я же предпочитаю WireGuard, поэтому я проверил обе программы, поскольку они обе отличаются простотой установки:



Как и ожидалось, OpenVPN в 10 раз медленнее WireGuard. Чего не ожидалось, так это того, что OpenVPN работает с одинаковой скоростью на 32 и 64 б. WireGuard почти насыщает гигабитный порт в обоих случаях – возможно, мы достигли предела NIC.

Чтобы узнать, не может ли WireGuard работать ещё быстрее, я провёл ещё один тест с двумя контейнерами, не задействующий физический Ethernet. Единственная проблема была в том, что и клиент, и сервер iperf3 работали на Raspberry Pi4, загружая два ядра.



Как и ожидалось, OpenVPN и 32-битный WireGuard, ограниченный CPU, отработали хуже, а 64-битный WireGuard отработал лучше.
 

Заключения


Я часто читаю заявления типа «оно того не стоит», «ты выиграешь несколько миллисекунд», и т.д., просто из-за того, что Raspberry Pi4 не особо мощный компьютер. Это не так! Как знает любой человек, занимающийся встраиваемым оборудованием, на медленном железе оптимизация софта ещё важнее, чем на быстром.

Я уже знал, что 64-битная ОС будет лучше работать на Raspberry Pi4, но я не знал, насколько лучше. Поэтому я провёл все эти тесты. Надеюсь, вам понравилось!
 

Комментарии 106

  • Goron_Dekar
    +3
    Забыли главное: 64 битный указатель в 2 раза больше. И поэтому современные программы, обильно внутри себя усеянные указателями, начинают занимать существенно больше оперативной памяти.
     
     
    • maaGames
      +1
      С одной стороны — правда. С другой — из-за выравнивания данных объём занимаемой памяти может и не поменяться. Смотря как компилировалось.
       
       
    • mistergrim
      +9
      Больше — да, существенно — вряд ли.
       
       
      • uanet
        0
        Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза. Поэтому, на 64бит фре порой приходилось выбирать: если нужна скорость — комиплим и используем 64бит бинарники, иначе (много-много непроцессорозависимых процессов) — 32бит. 64бит было быстрее благодаря большему количеству доступных регистров проца (это очень существенно), новым инструкциям. Очевидно, если бы эти фишки были доступны в 32бит приложениях — разница в скорости была бы меньше.
        Выравнивание — нередко означает снижение эффективной пропускной способности памяти. Грубо говоря, если для доставания двух 32-бит аргументов физически нужно прочитать 2 участка по 64бит — мы ничего не выигрываем, а если они ещё и выравниваться все должны — то расход памяти для данных растёт вдвое.
         
         
        • klirichek
          0

          Я видел, как это широко используется в solaris. Разные системные бинари, типа chmod, passwd и прочее нересурсоёмкое — 32-битное. При этом ядро 64-битное. При сборке своей программы надо всего лишь указывать флажок в gcc.

           

          А с выравниванием — отдельная тема. Надо понимать, что оно не всегда безопасно. Если на x86 можно положить 32-битное целое по нечётному адресу и это не вызовет проблем, кроме замедления, то уже атомик того же размера так не положишь. В подавляющем случае за этим всем следит компилятор. Но если вдруг стоит задача управлять этим вручную (например, компактно сериализовать данные без промежутков), то там кроме кастомного выравнивания обычно заодно применяются и другие штуки, вроде vbl-сжатия.

           
           
        • redsh0927
          0
          Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза.

          amd64 — закостыленный монстр, где инструкции раздуваются за счёт размазывания опкода и операндов по этим уродливым префиксам.
          Врядли имеет смысл сравнивать их с арм/арм64 с фиксированной длиной команды.
           
           
      • Goron_Dekar
        +1
        Проверить легко. Качаем Virtualbox, ставит 2 инстанса (32,64), качаем по Firefox/Chrom и смотрим потребление при открытии 4-5 страничек gmail/docs в виртуалках. Попробуйте, делов на 1.5 часа. Результат того стоит. У меня в тестах разница в потребляемой памяти была в 1.8 раз, но это было в 2014. Сейчас должно вырасти больше.
         
         
        • mistergrim
          0
          Ну если нам не хватает четырёх Гб на Pi4, то, наверное, мы вообще выходим за пределы возможностей малинки. А при достаточном объёме памяти — автор демонстрирует нам преимущества.
           
           
    • MaM
      0
      devblogs.microsoft.com/oldnewthing/20031008-00/?p=42223 или нет, ктож его знает
       
       
    • blackjack88
      0
      Зато регистры стали в два раза толще, что может спасти от лишних обращений к памяти.
       
       
      • mistergrim
        0
        Если рассматривать конкретно x86, то регистров стало ещё и больше.
         
         
  • kikiwora
    0
    Отличные тесты!
    Довольно наглядно видна разница.

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

    Вопрос только — а насколько хорошо будет реализована поддержка софтом?

    Что вообще можно поставить на четверку из систем под 64 без самостоятельной сборки, просто чтобы поставил и работало?

    Ubuntu?
     
     
    • remzalp
      +1
      По большей части все крупные, у кого есть aarch64 — AltLinux, Centos, Debian + все наследники, Fedora, Freebsd. Вопрос конечно в наполнении репозиториев и в поддержке периферии конкретно распберри в ядре, но попробовать уже есть что
       
       
      • IRT
        0
        Вопрос о наличии готового образа (для записи на microsd) Debian остается открытым. Поскольку на странице вики wiki.debian.org/RaspberryPi написано:
        Raspberry Pi 4
        Announced in 2019, this system adds a second HDMI port, more memory, true Gigabit Ethernet and USB3. There is no support for it in the Debian kernels yet.


        Вот здесь китайцы вроде как что-то сделали:
        github.com/openfans-community-offical/Debian-Pi-Aarch64

        Но у меня их образ не хочет грузиться на малинке.
         
         
        • roller
          +1
          armbian же
           
           
      • arkamax
        +1
        Раз пошел такой разговор — как умные люди в наше время защищают малинки от погибели при бросках питания? Мои малинки (пробовал вторую и третью версии), убивали системный раздел после бросков питания, причем даже сидя под адекватным БП (2.5+ А) и бесперебойником (Back-UPS Pro) — видимо какие-то импульсы все же пролезали, и система потом просто не грузилась, жалуясь на ошибки с диском. При этом на моих обычных системах даже стандартная десктопная Убунту чаще всего переносит аварийную перезагрузку без катастрофических последствий. SD-карты — Sandisk Pro (сравнительно неубиваемые), система во всех случаях была последней на тот момент версией Raspbian. В итоге плюнул и потратил в 10 раз больше денег на младший NUC — этот хотя бы не падает раз в два месяца. Что я делаю не так с малинками?
         
         
        • uanet
          +1
          Berryboot+iSCSI. Или berryboot+USB2SATA+SSD (старинные тормозные SLC с потреблением в 0.2А). Иначе вообще не живут сколь-нибудь долго флэшки — если они не «специальные», то данные на ФС «самоизменяются», причем совсем не те, которые ты перезаписываешь. Типа «перестал работать хром и куча софта», хотя никаких повреждений ФС вроде не было.
           
           
          • arkamax
            0
            данные на ФС «самоизменяются», причем совсем не те, которые ты перезаписываешь

            А можно подробнее про эту черную магию? Просто я с серией Sandisk Pro / Extreme неплохо знаком, использую их годами в зеркальных фотокамерах, видеокамерах, диктофонах, еще черт знает где — никогда данные сами собой не слетали, кроме как в малинках. Но симптомы в духе «оно работало, а теперь нет» — очень знаком именно применительно к малинам, и пока я не нашел, чем это объяснить, кроме как столь нелюбимым мной полтергейстом.
             
             
            • vladkorotnev
              0

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

               
               
            • klirichek
              0

              Можно разбить флешку пополам на два раздела, в один записать тестовые данные и скрыть. И дальше использовать только как флешку двукратно меньшего объёма (можно и на полку положить, но это уже чуть другие условия, хотя бы по температуре).
              Через 3-4 года можно попытаться прочитать архивный раздел и неприятно удивиться...

               

              На флешке в "малинке" похожие условия: есть множество системных файлов, которые никогда не меняются, а какие-то даже читаются достаточно редко. Есть активные секторы, которые изнашиваются записью. И плюс это всё в рабочем состоянии при повышенной температуре. И внезапно даже никакие особые броски напряжения не нужны, оно само со временем вдруг умрёт…
              Раньше, когда только появились Asus EEEpc с тормозными ssd на борту было целое направление оптимизаций, чтоб продлить ресурс. Например, unionfs/aufs с нижним слоем из squashfs, отключение логов и при желании периодический ребилд read-only слоя для актуализации.

               

              Нынче подобная модель используется практически во всех роутерах: грузимся с read-only раздела, пишем в память. Но там это ещё проще, покуда пользовательских данных, которые нужно сохранять, как правило, вообще нет.

               
               
              • arkamax
                0
                ОК, т.е. на «настоящих» SSD этот вопрос с внезапным вылетом секторов как-то по-другому решается? Ну и в моем случае оно умирало за 2-3 месяца.
                 
                 
                • klirichek
                  0

                  На настоящих та же проблема.
                  Данные, к которым долго не обращаются — "забываются". Заряд уходит из ячеек. Особенно при повышенной температуре (т.е. при эксплуатации).
                  В принципе, профилактическое чтение всего хранилища где-нибудь раз в полгода может помочь (типа, dd if=/dev/sdX of=/dev/null...). Где-то, возможно, это уже делает сам контроллер. Но в целом мысль такова, что для долговременного ("вечного") хранения ssd не годится.

                   
                   
                  • arkamax
                    0
                    Понятно, спасибо. Т.е. особенных альтернатив внешним винтам нет. USB флэшки чем-то отличаются в этом плане? Сомневаюсь, но… вдруг.
                     
                     
                    • klirichek
                      0

                      У флешек обычно другая память на борту. И совершенно другая манера использования (они обычно бОльшую часть времени всё же лежат на полке, а не торчат в порту). Соответственно, температура ниже, данные стареют медленнее.
                      У ssd, который на борту, особенно где-нибудь в замкнутом пространстве ноутбука всё гораздо печальнее.

                       
                       
                      • arkamax
                        0
                        Я бы с вами согласился, если бы не многолетний опыт использования SSD (от Intel до Samsung) в ноутбуках — разумеется, бекапы делаются, но тьфу-тьфу, ничего не летело еще, при сроках использования 4-5 лет. Видимо все же есть какие-то способы устаканить хранение информации на SSD. На малинках тогда попробую USB флэшки и BerryBoot.
                         
                         
                        • klirichek
                          0

                          Ну вот я тоже понадеялся на опыт и пролетел.
                          Всё зависит от использования.
                          У меня раздел с неиспользуемой убунтой стоял нетронутым лет около пяти. А потом я попытался в неё загрузиться, и не смог.
                          Здесь сложились факторы, что к данным вообще не обращались (даже случайно). Плюс, это рабочий ssd в ноуте, включённом 24х7, т.е. постоянно тёплый/горячий. Вот оно и "выстрелило".
                          Но покуда есть такая явная зависимость от условий, лучше эти факты сразу учитывать.

                           
                           
                          • rPman
                            0
                            можете сказать модель ssd или ноута, если оно запаяно?
                             
                             
            • Ryppka
              0
              Посмотрите на темы NAND read disturb и NAND write disturb.
               
               
        • kurec
          0
          Аналогичная проблема. Не смогли внедрить систему из-за того что малинка падала раз в неделю после перезагрузок. Greatly appreciate any advise.
           
           
          • mmMike
            0

            То же с этим помучился (установка "из коробки") — любой сбой по питанию 10..20% вероятность порчи fs и невозможность перезапуститься малине заново.

             

            Но нашел решение.
            Для своей системы видеонаблюдения сделал весь SD readonly. Причем смысла делать честь физического диска rd-only, а часть rw. Это не спасает (с SD картой, по крайней мере). Нужно все тома на SD загнать в rd-only режим.
            Пришлось повозится, но оно того стоило. За много месяцев эксплуатации с нередкими сбоями по питанию и перезагрузками по выключению питания, проблем нет.

             

            Все что нужно писать (логи, временные файлы с данными) — пишется в tmpfs. После дополнительной настройки вполне хватает небольшого размера tmpfs.

             

            В принципе, можно и отдельный (физически) 2-й диск примонтировать для rw данных. Начиная от USB диска, кончая SPI флеш памятью. И востанавливать его автоматически/программно после сбоя (хотя бы переформатированием).
            Но, мне не актуально (второй rw диск), все одно данные тут же в облако сливаются и tmpfs как буфера вполне хватает.

             
             
        • mmMike
          0

          решается переводом SD в read-only режим.
          Мне помогло.

           
           
    • Vindex
      0

      Можно попробовать Manjaro: https://manjaro.org/download/#raspberry-pi-4
      Я уже пару дней экспериментирую с этим дистрибутивом. Работает всё на удивление хорошо в сравнении даже с Raspbian (на сайте Raspbian можно почитать про множество багов, появляющихся после обновлений). Замеров никаких не делал. Только вижу, что KDE практически не тупит в сравнении с Raspbian (туда я ставил KDE только для эксперимента).

       
       
    • KillerSkiller
      +1
      Вопрос только — а насколько хорошо будет реализована поддержка софтом?

      Вполне ок. Все что есть под armv7l — собирают под arm64, в тч сразу куча готовых вещей в имаджах на dockerhub. На моей дома крутится ubuntu (не snappy, а та которая с «легаси» apt) на ней docker в котором qbittorrent-nox, plex server, homeassistant, pihole, пара пет проектов, база под них, traefik для роутинга на все это дело.
      image
      Была единственная трабла — vcgencmd пришлось из сорцов собирать, но там тред на гитхабе в каком-то из малиновых репо — по нему минут за 5 находится рабочий вариант, запускается билд скрипт — минут 10 компиляции C и C++ на малине — и все готово.

      А да, еще советую сразу забить на все эти sd карты, купить за 25 баксов kingston на 120gb и подрубить по usb3. На него /, на sd /boot (без этого пока низзя). Причем sd самую маленькую которую ток дома нашел под это дело вставил, насколько я понимаю вообще пофигу что там под /boot стоит, но мб комментаторы поправят.
       
      медиа

      Есть проблемы с транскодингом у того же plex на arm. По dlna все бегает збс, на iphone в plex приложении многие раздачи стримятся тоже ок — но некоторые оно по ходу не может стримить в оригинале и начинает транскодить. На PS4 plex все транскодит, даже то что нa iphone играет оригинальный стрим. По dlna там смотрю, dlna не грузит так систему. Если транскодить — это 100% CPU на всех ядрах и если попробуешь перемотать — проще идти ребутать pi тк иногда виснет намертво. На реддите в /homelab и /selfhosted все еще советуют любой intel под это дело — plex умеет в quicksync на нем. NUC тот же. Хотя эту уже другой ценовой диапазон. Но пока plex не научится нормально транскодить на arm — это будет или dlna или через-раз виснущий стрим (на ps4 вообще оч плохо)
       
       
      • DaemonGloom
        0
        Если у вас есть PlexPass, можете попробовать github.com/UnicornTranscoder/UnicornTranscoder — это позволит делать транскодинг силами аппаратного ускорения и для arm плат. По крайней мере, я видел такие отзывы.
        В крайнем случае — можно будет вынести транскодинг на другое устройство, которое включать только по необходимости.
         
         
  • Shtucer
    +2
    что означает 64-битную память.

    Я, конечно, всё понимаю, но этого я понять не могу. И даже не только потому что в оригинале "which means 64 bit ARM".

     
     
    • Sartor
      –2
      Да всё нормально. Адресация на 32-битной шине ограничена чуть больше 2ГБ. Поэтому автор говорит, что 64 бита дадут полный доступ к 4ГБ памяти, которые есть на плате.
       
       
      • Areso
        0
        Почему? 2^32 это чуть больше 4ГБ.
        Даже Винда 32-битная (далеко не лучший пример) может из коробки адресовать 3 с чем-то гигабайт.
         
         
        • Sartor
          0
          Да, подзабыл уже, вроде 3.28 было. Но это всё равно не все 4ГБ
           
           
          • uanet
            +1
            Это от чипсета и биоса зависело, часть пространства «загребали» всякие порты ввода-вывода и т.п.
            А как удалить коммент?
             
             
        • Siemargl
          +2
          OMG. 2 << 32 это и есть _ровно_ 4ГБ
           
           
          • VEG
            0
            Может быть он имел в виду десятичные гигабайты? =)
             
             
          • netch80
            +2
            > OMG. 2 << 32 это и есть _ровно_ 4ГБ

            OMG.
            2**32 это объём адресного пространства 32-битного процессора в байтах. В то же время это пространство расходуется, кроме собственно RAM, на ROM и доступ к периферии. Даже на x86 современном, у которого есть ещё два отдельных адресных пространства — I/O и PCI configuration, в пространство памяти замаплены крупные куски ресурсов устройств (а самый крупный, обычно — память видеоадаптера), а у ARM отдельного адресного пространства I/O вообще нет: оно всё лежит рядом с памятью.

            Поэтому, если у вас 4GB RAM и 4GB адресное пространство — эта память не может быть вся одновременно доступна через адресацию в этом пространстве. Чудес тут не бывает, нельзя усилием воли совместить разные сущности в одном и том же адресе. На x86 при 4GB установленной RAM 32-битные ОС могли использовать, в зависимости от чипсета и комплектации периферии, от 3.2 до 3.5GB — границы разные, но верхняя получалась достаточно жёстко потому, что под «полкой» 4GB всё занято ROM (постоянным адресом), пространствами APIC и прочей стандартной периферией, а под ней — тем же видео.

            (Полноты ради, надо упомянуть, что есть ещё метод переключения банков памяти… но это всё равно не даёт одновременной доступности памяти, и создаёт такой гимор для программиста, что после компьютеров типа «Агата» его не использовали всерьёз. EMS (не EMM386), который аппаратный, для x86 — прожил ровно до распространения i386 процессоров.)

            Это был фактор раз. А теперь фактор два: тот, кто писал ОС, знает про такие чудесные проблемы, как необходимость иметь в адресном пространстве постоянную часть — виртуальную память ядра, сменную — виртуальную память текущего процесса — и те же области I/O. И чтобы не возиться с дорогими переключениями для ввода-вывода в области ядра, перегонкой данных через bounce buffers — должна быть возможность отобразить всё RAM+ROM+I/O на половину адресного пространства (стандартно, верхнюю — для ядра, чтобы нижнюю оставить процессу). Это значит, что иметь 64-битную адресацию становится выгоднее даже не от ~3.2GB RAM, сказанных ранее, а от 1.2-1.5GB. Для x86, ARM, многих других — именно так. Этой проблемы нет на z/Arch или Sparc, где виртуальная трансляция может отключаться при переходе простым прерыванием в режим ядра, но не думаю, что вы легко найдёте такую машинку в доступе (и вас устроит цена).
             
             
            • Siemargl
              –1
              Не буду таким же занудным, но таки напомню про PAE
               
               
              • netch80
                +3
                PAE, да, в каком-то смысле решает первую проблему (предположим, что LPAE существует для нужных версий ARM/32 — вы про контекст не забыли? я сильно не уверен, что его дали для ARMv8 процессоров). Но PAE только усугубляет вторую проблему: смотрение через узкую щель 4GB виртуального пространства (а точнее, даже 1-2GB, учитывая стандартное построение с делением адресного пространства) на более широкое пространство. Все проблемы с доступом к данным в памяти — когда надо для того, чтобы сделать страницы доступными, сначала установить для них маппинг… для следующего кусочка снова менять маппинг… и так далее… те же bounce buffers, если какие-то компоненты не умеют 64 бита… сами адреса физической памяти уже становятся 64-битными и их арифметику надо поддерживать на 32-битном процессоре… вы реально хотите все эти хлопоты? Те, кто их испытали на себе — не хотят такого.

                И причём это не первый раз: сначала был PDP-11, с его 16-битным окном в 18- или 22-битный мир — и переход на VAX с его 32-битными виртуальными адресами. Потом 8086 с сегментами — и 80386 с 32-битными виртуальными адресами во времена RAM в единицы мегабайт. Теперь то же массово на границе 32/64. Ну не хотят программисты мучаться со всеми этими far-адресами, категориями памяти «до» и «после» границы, частыми переключениями пейджинга, выглядываниями через узкое окошко… они массово и с обычной плоской памятью-то еле справляются, а вы хотите ещё более странного.

                Так что тут лучше честное занудство, чем предложение другим взваливать на себя подобные марудные хлопоты…
                 
                 
                • Siemargl
                  0
                  Ну это не я притащил в топик архангелов, пидипи11, ваксы и х86…
                  И пае прозрачен для приложений, если используется системой.

                  Точно так же для 64бит системы, 32-бит приложение может _прозрачно_ использовать 4Гб. Как минимум на x64

                  У кого то прст слишком богатая фантазия.
                   
                   
                • marsianin
                  0

                  На ARMv8-A обязательно должно быть реализовано LPAE для 32-битного режима. Ну, если 32-битный режим вообще поддерживается чипом, конечно. Это описано в ARMv8 architecture reference manual.

                   
                   
          • Temtaime
            +1
            OMG, но 2<<32 это 8ГБ.
             
             
            • Siemargl
              +1
              ну конечно же. но 32бита адресуют ровно 4ГБ, именно это имелось в виду
               
               
      • Shtucer
        0

        Что нормально-то? В оригинале говорится про 64-битную архитектуру ARM, которая в переводе превратилась в, видимо, RAM. То что у нас теперь имеется доступ к большему объёму памяти, не меняет разрядность памяти.

         
         
  • Jogger
    +4
    Ну вот что за несправедливость.
    Я взял другую карту памяти и поставил на неё Debian.

    При том, что на сайте дебиана написано:
    Raspberry Pi 4

    Announced in 2019, this system adds a second HDMI port, more memory, true Gigabit Ethernet and USB3. There is no support for it in the Debian kernels yet.

    Почему вместо действительно интересной темы «как поставить Debian на Raspberry Pi 4» человек пишет статью с какими-то невнятными бенчмарками?

    Вопрос риторический, я понимаю что это перевод. Но обидно.
     
     
    • safari2012
      0
      Есть дистрибутив дебиана (которого для малинки, к стати, тоже нет, raspbian это тоже порт), а есть исходники. Автор ясно и чётко написал, что собрал aarch64 из исходников.
       
       
      • Jogger
        +1
        Для старых малинок дебиан вполне себе есть, ссылка выше. Исходники — это понятно, но само их наличие не гарантирует что они соберутся под произвольную платформу. Поэтому статья о том, что и как собирать чтобы запуститься на четвёртой малинке — была бы полезна. Особенно для людей, которые не собирают линукс из исходников каждый день.
         
         
  • KentSilver
    +5

    На Raspberry Pi4 стоит четырёхъядерный ARM Cortex A72, до 4 ГБ памяти и гигабитный порт Ethernet – и всё это всего за $35.
    Враньё чистой воды — этот конфиг стоит не 35!

     
     
    • barbos6
      0
      Враньё чистой воды — этот конфиг стоит не 35!

      За столько, сколько он стоит, можно взять Orange pi 4 на rk-3399.
      Поинтереснее железка.
       
       
      • KentSilver
        +8

        Нет, нет и нет.
        Выбор между малиной и китайским нонеймами очевиден (рассмотривать стоит лишь пайн, одройды, тинкерборды, невидию, интель, etc)
        Не знаю, как дела обстоят с рокчипом, но с всепобедителем не было ни работающей оси, ни работающих дров, ни поддержки ядром, ни поддержки вендором, ни комьюнити.

         
         
        • safari2012
          0
          загляните сюда: www.armbian.com
           
           
          • KentSilver
            0

            Для того, чтобы что? Я малиной пользуюсь

             
             
            • safari2012
              +2
              да пользуйтесь сколько угодно, но ерунду про другие одноплатники не пишите.
               
               
        • Gordon01
          0
          Подозреваю, что китайцы подразумевали «ПолнаяПобеда»
           
           
        • quwy
          0
          с всепобедителем не было ни работающей оси, ни работающих дров, ни поддержки ядром

          Уже года три, как все в mainline. Некоторые моменты вызывают вопросы, но оно уже давно просто работает. Без плясок, без бубна.
           
          ни комьюнити.

          Вам шашечки, или ехать?
           
           
    • safari2012
      +2
      до 4Гб же, а так да, можно было более корректно перевести.
       
       
    • dmsss
      0
      к сожалению за эти деньги только алюминиевый корпус
       
       
    • uanet
      –1
      На распродаже 11.11 — 30 «за всё»: малинку (42 была модель с 2ГБ в одном из лотов у Landzo на али) +корпус (короче, добивка до 50$), минус купон 20/50 (а то ещё и ландзовский купон 3/9). Логично предположить, что её цена без пересылки находится в окрестностях 35$.

      Медный радиатор за 1,49 неплохо справляется с ней в пассиве, если не грузить все 4 ядра+видео (openssl speedx4+glxgears).

      У Распберри есть грмадное коммьюнити, до которого зоопарк других одноплатников «не дорос» — именно из-за зоопарковости.
       
       
    • iproger
      0

      Правда. Я еще замечу что малина 4гб + переферия в виде оф набора чуть дешевле наков от Интела. Только они на голову выше малины.

       
       
  • VBKesha
    +5
    64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись.

    Как бы да, но на самой плате стоит чип памяти DDR4(k4f8e304hb для 1Gb версии) и у него 32 битная шина, поэтому не все так гладко.
     
     
    • beeruser
      0
      DDR расшифровывается как Double Data Rate.
      Это означает что за такт шины передаётся 2 бита. Таким образом передаётся 64 бита по 32-битной шине :)
       
       
      • VBKesha
        0
        Может я и ошибаюсь но ИМХО это работает по другому. За такт шины данные передаются два раза, но это не делает ширину шины 64-битной. Ведь у DDR есть две частоты реальная и «эффективная». И вот на эффективной частоте мы имеем всё теже 32бита.
         
         
        • beeruser
          0
          это не делает ширину шины 64-битной

          И где я это утверждаю? Я сказал «по 32-битной шине».
           
          Ведь у DDR есть две частоты реальная и «эффективная»

          «Эффективная частота» это абстрактное понятие. Вы же понимаете, что интерфейс тактируется одной частотой?

          При использовании DDR SDRAM достигается удвоенная скорость работы, нежели в SDRAM, за счёт считывания команд и данных не только по фронту, как в SDRAM, но и по спаду тактового сигнала. За счёт этого удваивается скорость передачи данных без увеличения частоты тактового сигнала шины памяти.
           
           
           
          • VBKesha
            0
            Ага и именно по этому пишут что дескать DDR400 хоть тактовая там 200. И в DDR обычно смотрят именно эффективную частоту. Так вот на на своей эффективной частоте она имеет ширину шины 32 бита.
            Или мы просто друг друга не поняли, я лишь имел ввиду что 64 битная работа с памятью, при 32 битном интерфейсе самой памяти не даст никаких преимуществ, а не что она не возможна.
             
             
            • beeruser
              0
              Так вот на на своей эффективной частоте она имеет ширину шины 32 бита.

              Нет никакой эффективной частоты. Это абстракция.
              Шина физически 32-битная. И это не абстракция, а 32 проводника на плате.
              И по каждому проводнику за 1 такт передаётся 2 бита. Ровно это я и написал в своём первом посте.
              До сих пор не ясно?
               
              64 битная работа с памятью, при 32 битном интерфейсе самой памяти не даст никаких преимуществ

              Это не так. Вы не работает с памятью напрямую, а работаете с кэшем.
              Команда ldr, к примеру, прочитает 8 байт за такт в 64-битном режиме.
              Так что преимущество вполне очевидное.

              Именно об этом говорится тут:
              64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись.

               
               
               
              • VBKesha
                0
                Нет никакой эффективной частоты. Это абстракция.

                Как минимум это общепринятая абстракция.
                И по каждому проводнику за 1 такт передаётся 2 бита. Ровно это я и написал в своём первом посте.
                До сих пор не ясно?

                И как это превращает 32 бита в 64? Правильно никак.
                 
                Это не так. Вы не работает с памятью напрямую, а работаете с кэшем.
                Команда ldr, к примеру, прочитает 8 байт за такт в 64-битном режиме.
                Так что преимущество вполне очевидное.

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

                Ну так вот такое чтение можно сделать только за два такта эффективной частоты DDR, а не за один если бы разработчики поставили 2 чипа DDR(если конечно проц умеет работать с 64 битной шиной).
                 
                 
                • khim
                  0
                  А не могли бы вы перед продолжением спора всё-таки уточнить — о чём именно вы смотрите, а?

                  О том, что двухканальный доступ к памяти быстрее однократного? Так так оно было и в первых Pentium'ах — где о 64-битах никто и не заикался.

                  О том, что доступ в кеш происходит в 64-битном процессоре быстрее, чем в 32-битном? Это тоже очевидно.

                  И от интерфейса, которым проц соединён с памятью это не зависит никак.

                  О каком вообще измеримом эффекте вы спорите, я понять не могу?

                  Потому что спорить о том, сколько ангелов помещается на кончике иглы (при топ, что ничего измеримого про этих ангелов узнать нельзя) — можно до бесконечности.
                   
                   
                  • VBKesha
                    +1
                    Я лишь написал о том что несмотря на 64 битность процессора, данные не могут считываться по 8 байт за один раз, из за 32 битности шины памяти.
                    О том, что двухканальный доступ к памяти быстрее однократного?

                    Про двухканал вообще никто не говорил.
                     
                     
                • beeruser
                  0
                  Как минимум это общепринятая абстракция.

                  Само понятие «эффективной частоты в МГц» применительно к модулям памяти — дилетантство.

                  В спецификации JEDEC есть замечание, что использовать термин «МГц» в DDR некорректно, правильно указывать скорость «миллионов передач в секунду через один вывод данных».

                  Иначе говоря «MT/s» или «Mbit/s на контакт»
                   
                  И как это превращает 32 бита в 64? Правильно никак.

                  За 1 такт передаётся 2 бита. 32*2 = 64. Повторение — мать учения :)
                  Но для оценки преимущества 64-битного режима это не имеет никакого значения.
                  Как в 32-битном режиме, так и в 64-битном режиме работы CPU, подсистема памяти Raspberry-Pi обеспечит сравнимую ПСП, потому что скорость работы с кэшем гораздо выше чем ПСП.
                   
                  Для этого как минимум надо чтобы данные были уже в кеше.

                  Кэш на то и придуман, чтобы в подавляющем большинстве случаев данные там были.
                  К тому же для этого их не всегда нужно читать из памяти. Можно записать данные в кэш-строку и сразу прочитать (в т.ч. из очереди записи процессора).
                   
                  Ну так вот такое чтение можно сделать только за два такта эффективной частоты DDR
                  У частоты не бывает тактов. Такт это промежуток (период) между двумя импульсами тактового генератора, который в данном случае подаётся на интерфейс модуля памяти. Как бы вы не напрягались с абстракциями, но этот период составляет строго определённую величину. Его нельзя поделить на два. Что увеличивается, так это data rate, что и указано в названии технологии DDR.
                   
                   
                  • VBKesha
                    0
                    За 1 такт передаётся 2 бита. 32*2 = 64. Повторение — мать учения :)

                    А нету нету никаких тактов, есть операции чтения и записи. И вот за одну операцию чтения мы получаем 32 бита.
                    За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.
                     
                    И в 32-битном режиме и в 64-битном режиме работы CPU, подсистема памяти Raspberry-Pi обеспечит сравнимую ПСП, потому что скорость работы с кэшем гораздо выше чем ПСП.

                    И потому что доступ к памяти 32битный.
                    У частоты не бывает тактов. Такт это промежуток (период) между двумя импульсами тактового генератора, который в данном случае подаётся на интерфейс модуля памяти. Как бы вы не напрягались с абстракциями, но этот период составляет строго определённую величину. Его нельзя поделить на два. Что увеличивается, так это data rate, что и указано в названии технологии DDR.

                    Зато его можно умножить на два производя операции как фронту сигнала и так и по спаду(в отличии от SDR). И вот умножив мы тут и получим ту самую эффективную частоту.
                     
                     
  • fougasse
    –2
    Raspberry Pi4 в качестве embedded ограниченно применим. Конечно, для прототипов и домашнего применения — отличная штука, но в других случаях, особенно с отрицательной/высокой температурой сложновато.
    Проблема указателей преувеличена, как мне кажется.
     
     
    • lingvo
      0

      Ничем RPi особо не ограничен. Если хочется широкого диапазона температур, то берется Rpi Compute Module — он от -20° до +85°C.
      На них даже вполне индустриальные ПЛК уже есть.

       
       
      • Dima_Sharihin
        0

        У RPi периферии с гулькин нос, какой профит от такого ПЛК?

         
         
  • alex-khv
    0
    Может еще кто-то не видел данный обзор «Большой тест мини-ПК 2019»
     
     
    • homocomputeris
      +1
      Odroid N2, к сожалению, нет. Он вроде как разрыватель по сравнению с другими.
       
       
  • GBK
    0

    Хоть кто то Pink Floyd слушает)

     
     
    • arkamax
      0
      Хм. В моем кругу (далеко не хиппарей и всем сильно меньше 50) PF не только слушают, но и считают классикой.
       
       
  • vagran
    +2
    Pi 3 тоже 64 бита.
     
     
  • eugene08
    0
    > Не рекомендую использовать такие системы в подобных целях, но у многих людей всё ещё есть медленное подключение к интернету (менее 100 Мб), поэтому они могут не обращать внимания на медленную работу Raspberry Pi4.
    а почему не рекомендуете? и что порекомендуете взамен? как раз рассматриваю rpi4 как файрвол + wireguard впн для домашней сети, обычные роутеры которые видел — все равно сильно слабее.
     
     
    • safari2012
      +2
      нормально потянет, ещё и wi-fi можно оттуда же раздавать.
       
       
  • mpa4b
    0

    А в этой распи всё еще езернет подключён через USB?

     
     
    • eugene08
      +2
      нет, там теперь 2 отдельных контроллера для ethernet и usb
       
       
    • Dima_Sharihin
      0

      <sarcasm>нет, там теперь usb через ethernet подключен</sarcasm>

       

      Таки воткнули PCIe, по которому уже проброшен и 1GbE, и USB3.0.
      Но вообще показательно, у большинства промышленных SoC это (RGMII+USB3.0) помещается прямо в камне, правда, говорят, что с маленькими нанометрами 5-вольтовая природа USB уже дает сбой и из-за этого придумали eUSB

       

      А так, 4-гиговая RPi4 очень приятная железка, даже на распбиане, ждем полной поддержки железа на ARM64

       
       
  • blind_oracle
    +1

    А потом выясняется что всяких библиотек, например для работы с камерой Pi, под 64 бита либо нет, либо они не работают даже если соберутся. Плавали, знаем.

     

    Так что нужно аккуратно к этому вопросу подходить. А я подожду пока оно не стабилизируется.

     
     
  • Tangeman
    +1
    Я часто читаю заявления типа «оно того не стоит», «ты выиграешь несколько миллисекунд», и т.д.

    В зависимости от роли и загрузки железки оно действительно может того не стоить.

    К примеру, у меня RPi 4 нагружена только netdata с мониторингом пачки сервисов, load average там в среднем меньше 0.1, загрузка процессоров (всех) в худшем случае не более 5%, по сетке едва-ли больше мегабита ходит — выигрыша от перехода на 64bit вообще никакого.

    Если это будет супернагруженный web/nas/vpn-server, причём с гигабитным траффиком — другое дело, но тут уже возникнет вопрос, стоит ли для такой роли использовать RPi?
     
     
    • safari2012
      0
      Недостатки платформы часто являются обратной стороной её достоинств. Уже столько легаси под 32бита, что комьюнити, видимо, считает, что оно того пока не стоит.
      Что касается серьезных задач, то и Intel NUC её не заменит, т.к. точек отказа ровно столько же, а производительности на Ватт, наверное тоже.
       
       
  • aliend
    +1

    Уже месяца два как перевел свой домашний роутер RPI3b+ на Fedora 31 64bit
    (начинал с: Raspberry Pi + CentOS = Wi-Fi Hotspot (или малиновый роутер в красной шляпе))
    Думаю поделиться в ближайшее время с общественностью, но если вкратце, то:
    быстрее/холоднее/удобнее/ и приятнее...

     
     
    • IGHOR
      0
      А Bluetooth там работает?
       
       
      • aliend
        0

        За ненадобностью не проверял

         
         
  • RedSun-ops
    0

    Та можно ставить и ubuntu и kali и другие
    А если мало места в флешке (2 GB и больше) ставьте Risc OS
    А если еще меньше то установливайте Risc OS Pico (BASIC) (16 MB и больше)

     
     
    • aliend
      +2

      2GB на флешке вполне достаточно для той же Fedora, а sd меньшего размера еще придется поискать...

       
       
  • Peter1010
    0
    Был бы ещё raspbian 64х битный… А так, ubuntu слишком тяжелая… А lubuntu и Xubuntu под pi нет :)
    Нет, конечно можно скачать server версию а потом
    sudo aptinstall lubuntu-desktop
     
     
    • arkamax
      0
      apt{space}install, извините.
       
       
  • apro
    +1
    64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись

    Непонятно что имеется ввиду. Физически и логически битность ОС к тому сколько максимум можно за раз записать отношения не имеет. Физически там LPDDR4 память, сколько бит из нее раз может забрать процессор никак не меняется от битности ОС.
    Логически для 32битного arm есть инструкции STRD/LDRD, с помощью них можно запустить запись чтение сразу 8 байт.

     
     
    • khim
      0
      Считать/записать можно и более широкими командами — сколько там vld4 за раз могёт? А сколько ldm на 10 регистров? Как раз, кстати, одной командой загрузить десяток регистров в ARM64 нельзя…

      А вот дальнейшая обработка — уже только по 32 бита «за раз». Даже сложить пару 64-битных чисел в ARM32 одной иструкцией не получится.

      Но не знаю как это отличие правильно описать короткой фразой.
       
       
  • AlexAV1000
    0
    А образ-то где взять 64-битный? Самому что ли собирать?
     
     
  • Suveren
    +1
    Достаточно наглядное сравнение производительности, спасибо за перевод, однако ARM — это всё-таки не память, а процессор :-)
    … что означает 64-битную память.

    Оригинал: «which means 64 bit ARM.»
     
     
  • kovserg
    0
    Очень интересно сравнение энергопотребления для 32 и 64бит кода, выполняющего одинаковые задачи.
     
     
    • khim
      0
      ARM64 будет греться чуть больше при полной загрузке, но будет потреблять чуть меньше в рассчёта «на байт обработанных данных».

      То есть практически — ARM64 тут тоже выигрывает при правильно написанном софте.
       
       
      • kovserg
        +1
        Хочется реальных данных
         
         
  • Pilat
    +1
    Есть такая фирма FriendlyElec (FriendluARM). Она делает те же процессорные платы, но без видео (и с видео тоже делает) и с кучей очень разных плюшек, вот на них и надо запускать подобные тесты. А RaspberryPI это уже какой-то комбайн без понятного позиционирования, зачем на нём запускать тест кодирования звука? Что, кто-то будет этим заниматься? Тестировать надо практические задачи, а они для RPi — медиасервер и всё, остальное только от незнания о существования альтернатив.