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



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, но я не знал, насколько лучше. Поэтому я провёл все эти тесты. Надеюсь, вам понравилось!




Комментарии (131):

  1. Goron_Dekar
    /#21269332

    Забыли главное: 64 битный указатель в 2 раза больше. И поэтому современные программы, обильно внутри себя усеянные указателями, начинают занимать существенно больше оперативной памяти.

    • maaGames
      /#21269424

      С одной стороны — правда. С другой — из-за выравнивания данных объём занимаемой памяти может и не поменяться. Смотря как компилировалось.

    • mistergrim
      /#21269678 / +2

      Больше — да, существенно — вряд ли.

      • uanet
        /#21272800

        Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза. Поэтому, на 64бит фре порой приходилось выбирать: если нужна скорость — комиплим и используем 64бит бинарники, иначе (много-много непроцессорозависимых процессов) — 32бит. 64бит было быстрее благодаря большему количеству доступных регистров проца (это очень существенно), новым инструкциям. Очевидно, если бы эти фишки были доступны в 32бит приложениях — разница в скорости была бы меньше.
        Выравнивание — нередко означает снижение эффективной пропускной способности памяти. Грубо говоря, если для доставания двух 32-бит аргументов физически нужно прочитать 2 участка по 64бит — мы ничего не выигрываем, а если они ещё и выравниваться все должны — то расход памяти для данных растёт вдвое.

        • klirichek
          /#21274364

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


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

        • redsh0927
          /#21274664

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

          amd64 — закостыленный монстр, где инструкции раздуваются за счёт размазывания опкода и операндов по этим уродливым префиксам.
          Врядли имеет смысл сравнивать их с арм/арм64 с фиксированной длиной команды.

          • khim
            /#21276000

            А почему нет? В x86-64 префиксы добавили, в ARM64 (официальное название — Aarch64), наоборот — убрали.

            Теперь ввесто префикса нужна отдельная команда перехода.

            Конечный результат-то всё равно один: 64-битный код немного больше. Но не в 1.5 раза, это какая-то анамалия.

        • slonopotamus
          /#21278162

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

          Допустим, но при чём здесь указатели?

      • Goron_Dekar
        /#21274160 / +1

        Проверить легко. Качаем Virtualbox, ставит 2 инстанса (32,64), качаем по Firefox/Chrom и смотрим потребление при открытии 4-5 страничек gmail/docs в виртуалках. Попробуйте, делов на 1.5 часа. Результат того стоит. У меня в тестах разница в потребляемой памяти была в 1.8 раз, но это было в 2014. Сейчас должно вырасти больше.

        • mistergrim
          /#21274586

          Ну если нам не хватает четырёх Гб на Pi4, то, наверное, мы вообще выходим за пределы возможностей малинки. А при достаточном объёме памяти — автор демонстрирует нам преимущества.

          • Goron_Dekar
            /#21275326

            На 4-х гигах вернее отбросить ~700MByte памяти и ставить 32 бита, чем ставить 64. Только это я и хотел сказать.
            И, да, при условии когда у данной малинки важнее не свободная память, а скорость работы с 64-битными целыми или float, вероятно, всё-таки вернее ставить 64бит ось. Но этот случай гораздо реже при использовании малины, чем нехватка памяти и уход в свап. И уж точно ближе к формулировке «выходим за пределы возможностей малинки»

            • mistergrim
              /#21275340

              На 4-х гигах вернее отбросить ~700MByte памяти и ставить 32 бита, чем ставить 64. Только это я и хотел сказать.
              Что лучше: потратить лишние 700 Мб памяти на 64-битные приложения (хотя это какой-то очень суровый случай) и получить прирост производительности или просто выкинуть 700 Мб в никуда?

              • khim
                /#21276018

                Лучше всего вспомнить про первые 64-битные Sparc'и и использовать 64-битное ядро с 32-битными программами.

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

              • Goron_Dekar
                /#21276442

                Если не упадём в swap. Если упадём — про производительность можно забыть.

    • blackjack88
      /#21274274

      Зато регистры стали в два раза толще, что может спасти от лишних обращений к памяти.

      • mistergrim
        /#21274598

        Если рассматривать конкретно x86, то регистров стало ещё и больше.

        • khim
          /#21276020

          В ARM их тоже стало больше.

  2. kikiwora
    /#21269430

    Отличные тесты!
    Довольно наглядно видна разница.

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

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

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

    Ubuntu?

    • remzalp
      /#21269600

      По большей части все крупные, у кого есть aarch64 — AltLinux, Centos, Debian + все наследники, Fedora, Freebsd. Вопрос конечно в наполнении репозиториев и в поддержке периферии конкретно распберри в ядре, но попробовать уже есть что

      • IRT
        /#21269818

        Вопрос о наличии готового образа (для записи на 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

        Но у меня их образ не хочет грузиться на малинке.

      • arkamax
        /#21272958 / +1

        Раз пошел такой разговор — как умные люди в наше время защищают малинки от погибели при бросках питания? Мои малинки (пробовал вторую и третью версии), убивали системный раздел после бросков питания, причем даже сидя под адекватным БП (2.5+ А) и бесперебойником (Back-UPS Pro) — видимо какие-то импульсы все же пролезали, и система потом просто не грузилась, жалуясь на ошибки с диском. При этом на моих обычных системах даже стандартная десктопная Убунту чаще всего переносит аварийную перезагрузку без катастрофических последствий. SD-карты — Sandisk Pro (сравнительно неубиваемые), система во всех случаях была последней на тот момент версией Raspbian. В итоге плюнул и потратил в 10 раз больше денег на младший NUC — этот хотя бы не падает раз в два месяца. Что я делаю не так с малинками?

        • uanet
          /#21273752 / +1

          Berryboot+iSCSI. Или berryboot+USB2SATA+SSD (старинные тормозные SLC с потреблением в 0.2А). Иначе вообще не живут сколь-нибудь долго флэшки — если они не «специальные», то данные на ФС «самоизменяются», причем совсем не те, которые ты перезаписываешь. Типа «перестал работать хром и куча софта», хотя никаких повреждений ФС вроде не было.

          • arkamax
            /#21273772

            данные на ФС «самоизменяются», причем совсем не те, которые ты перезаписываешь

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

            • vladkorotnev
              /#21274348

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

            • klirichek
              /#21274384

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


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


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

              • arkamax
                /#21274464

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

                • klirichek
                  /#21274488

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

                  • arkamax
                    /#21274492

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

                    • klirichek
                      /#21274494

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

                      • arkamax
                        /#21274510

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

                        • klirichek
                          /#21274550

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

                          • rPman
                            /#21275032

                            можете сказать модель ssd или ноута, если оно запаяно?

                            • klirichek
                              /#21276648

                              MacBook air, early 2014.
                              SSD его штатный

                              • Ava256
                                /#21288394

                                Очень странная ситуация. В современных SSD потеря данных из-за потери заряда может произойти только если не включать ноутбук пол года или вытащить из него SSD и положить на полку на пол года.Если же ноут постоянно работает, то не используемые ячейки периодически перезаписываются контроллером.Очень странная ситуация.
                                Может быть просто диск был изношен сильно? Какой у него был объем и какой объем записанной информации?

                                • klirichek
                                  /#21289784

                                  Ну, наверное всё же не перезаписываются (а с чего вдруг?). Или недостаточно.


                                  Ноут свежий, диск на нём тоже.
                                  Был включён практически 24/7 (хотя на макбуке с его достаточно глубокой спячкой это не сильно принципиально).
                                  На полдиска стояла ubuntu (очевидно — 14.04). В 2016-м её использование прервалось и я перешёл на родную макось. Осенью 2019-го загрузиться в неё уже не смог (скорость чтения упала до <900кб/с, а где-то вообще выскакивала ошибка чтения). В итоге нужное с трудом таки выцарапал, разделы чуть-чуть подвигал, и вроде всё вылечилось. Но осадок остался ).

                      • netch80
                        /#21275094

                        > У флешек обычно другая память на борту.

                        «Другая» это в чём отличие от SSD?
                        Cпособность забыть без чтения это специфика собственно версии ячейки из транзистора с плавающим затвором, или нет? Вряд ли тут влияет NAND vs. NOR, поэтому что это организация доступа к ячейкам. Или у них ещё и кросс-влияние?

                        • klirichek
                          /#21276714

                          Флешки появились всё же гораздо раньше ssd "на борту". Как и всевозможные memory stick/sdcard. Думаю, это как раз издержки технологии, которая сперва не давала возможность сделать память с достаточным ресурсом перезаписи.
                          Кажется, что и нынешние экземпляры — они тоже скорее предназначены для переноса файлов и хранения "на полке", чем для использования в качестве постоянно включенного основного диска, куда постоянно что-то пишут.
                          Казалось бы, можно в телефон вместо встроенной прошивки приспособить microsd-карту. Но по факту я видел очень много внезапно умерших карт. И всего один телефон, у которого вдруг полетела внутренняя память.

            • Ryppka
              /#21274876

              Посмотрите на темы NAND read disturb и NAND write disturb.

        • kurec
          /#21274276

          Аналогичная проблема. Не смогли внедрить систему из-за того что малинка падала раз в неделю после перезагрузок. Greatly appreciate any advise.

          • mmMike
            /#21274632

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


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


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


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

            • khim
              /#21276084

              Ну вот вроде и нашли проблему: поскольку стираются данные на флешке куда большими блоками, чем пишутся, то при записи на флешку даже те данные, которые, вроде как, вы не трогаете — могут потеряться (потому что вот именно их контроллер решил перенести с одного места на другое «для надёжности»).

              Соотвественно если вы не можете обеспечить, чтобы в момент перезагрузки на SD-карту ничего не писалось (а это тяжело сделать если туда, скажем, пишутся логи) — то готовьтесь через некоторое время «огрести».

              А если ничего не писать — данные хранятся годами (но не десятилетиями… со временем всё-таки содержимое с SSD «утекает»… про это нужно не забывать).

              • mmMike
                /#21276344

                Ну вот вроде и нашли проблему: поскольку стираются данные на флешке куда большими блоками, чем пишутся, то при записи на флешку даже те данные, которые, вроде как, вы не трогаете — могут потеряться (потому что вот именно их контроллер решил перенести с одного места на другое «для надёжности»).

                Так это известная вещь. Размер блока на SD 512 байт. Но даже их сразу никто не пишет, поскольку через SDIO интерфейс пишут не на прямую, а с использованием DMA. Не знаю, какой у драйвера linux типичный DMA буфер для записи на карту. Но даже на контроллерах меньше 2Кб смысла обычно нет.


                Вероятность проблем, если дернуть питание при записи, — 100%. просто иногда эти проблемы остаются скрытыми (попортилось не в критическом для работы OS месте).

        • mmMike
          /#21274634

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

        • nlykl
          /#21284242

          У меня на F2FS и старой флешке из телефона все работает исправно. /tmp/ лежит в оперативной памяти.

      • Adik3945
        /#21276710

        Как показывает практика, софта под aarch64 достаточно, всякие хромиумы и VLC присутствуют, если будет заметен дефицит софта, то всегда есть AUR, хотя найти IDE всё ещё проблематично.
        По моему скромному и субъективному, (не)самой большой проблемой для Raspberry Pi 4B является недостаток различных дистрибутивов, выбирать приходится между Arch/Manjaro, Gentoo, Ubuntu и Raspbian/Debian. Т.е., всё настолько скудно, что я даже не получился их всех перечислить, ибо перечислять толком нечего.

    • Vindex
      /#21272176

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

    • KillerSkiller
      /#21274278 / +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
        /#21274610

        Если у вас есть PlexPass, можете попробовать github.com/UnicornTranscoder/UnicornTranscoder — это позволит делать транскодинг силами аппаратного ускорения и для arm плат. По крайней мере, я видел такие отзывы.
        В крайнем случае — можно будет вынести транскодинг на другое устройство, которое включать только по необходимости.

  3. Shtucer
    /#21269694

    что означает 64-битную память.

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

    • Sartor
      /#21272826 / -2

      Да всё нормально. Адресация на 32-битной шине ограничена чуть больше 2ГБ. Поэтому автор говорит, что 64 бита дадут полный доступ к 4ГБ памяти, которые есть на плате.

      • Areso
        /#21272852

        Почему? 2^32 это чуть больше 4ГБ.
        Даже Винда 32-битная (далеко не лучший пример) может из коробки адресовать 3 с чем-то гигабайт.

        • Sartor
          /#21272900

          Да, подзабыл уже, вроде 3.28 было. Но это всё равно не все 4ГБ

          • uanet
            /#21273770 / +1

            Это от чипсета и биоса зависело, часть пространства «загребали» всякие порты ввода-вывода и т.п.
            А как удалить коммент?

        • Siemargl
          /#21273396 / +2

          OMG. 2 << 32 это и есть _ровно_ 4ГБ

          • VEG
            /#21273550

            Может быть он имел в виду десятичные гигабайты? =)

          • netch80
            /#21273568 / +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
              /#21273890 / -1

              Не буду таким же занудным, но таки напомню про PAE

              • netch80
                /#21273970 / +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
                  /#21274200

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

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

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

                • marsianin
                  /#21274396

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

                  • netch80
                    /#21275154

                    Спасибо :)

                    Если вы осилили этот толстенный документ, задам вопрос в совершенно другую сторону. Пусть есть пара инструкций LDAXR + STXR (например, захват спинлока). Сказано ли где-нибудь явно, что acquire semantics из LDAXR (в отличие от LDXR) распространяется на парную ему успешно сработавшую STXR?

          • Temtaime
            /#21274020 / +1

            OMG, но 2<<32 это 8ГБ.

            • Siemargl
              /#21274174 / +1

              ну конечно же. но 32бита адресуют ровно 4ГБ, именно это имелось в виду

      • Shtucer
        /#21273032

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

  4. Jogger
    /#21269876

    Ну вот что за несправедливость.

    Я взял другую карту памяти и поставил на неё 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
      /#21271408

      Есть дистрибутив дебиана (которого для малинки, к стати, тоже нет, raspbian это тоже порт), а есть исходники. Автор ясно и чётко написал, что собрал aarch64 из исходников.

      • Jogger
        /#21271716

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

  5. KentSilver
    /#21269890

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

    • barbos6
      /#21270194

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

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

      • KentSilver
        /#21270376 / +1

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

        • safari2012
          /#21271440

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

          • KentSilver
            /#21271476

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

            • safari2012
              /#21271628

              да пользуйтесь сколько угодно, но ерунду про другие одноплатники не пишите.

        • Gordon01
          /#21272024

          Подозреваю, что китайцы подразумевали «ПолнаяПобеда»

        • quwy
          /#21274386

          с всепобедителем не было ни работающей оси, ни работающих дров, ни поддержки ядром

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

          ни комьюнити.

          Вам шашечки, или ехать?

      • evgenyk
        /#21276116

        Полгода назад я купил Orange pi 3. Соблазнился на интересное железо. Теперь буду покупать только Raspberry. На Orange pi 3. все интересное не работает или не поддерживается (PCIE не работает, GPU работает только для Android).
        Тем более появился Raspberry Pi 4.

    • safari2012
      /#21271424

      до 4Гб же, а так да, можно было более корректно перевести.

    • dmsss
      /#21272546

      к сожалению за эти деньги только алюминиевый корпус

    • uanet
      /#21273798 / -1

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

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

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

    • iproger
      /#21273830

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

  6. VBKesha
    /#21270282 / +2

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

    Как бы да, но на самой плате стоит чип памяти DDR4(k4f8e304hb для 1Gb версии) и у него 32 битная шина, поэтому не все так гладко.

    • beeruser
      /#21270978

      DDR расшифровывается как Double Data Rate.
      Это означает что за такт шины передаётся 2 бита. Таким образом передаётся 64 бита по 32-битной шине :)

      • VBKesha
        /#21271756

        Может я и ошибаюсь но ИМХО это работает по другому. За такт шины данные передаются два раза, но это не делает ширину шины 64-битной. Ведь у DDR есть две частоты реальная и «эффективная». И вот на эффективной частоте мы имеем всё теже 32бита.

        • beeruser
          /#21272890

          это не делает ширину шины 64-битной

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

          Ведь у DDR есть две частоты реальная и «эффективная»

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

          При использовании DDR SDRAM достигается удвоенная скорость работы, нежели в SDRAM, за счёт считывания команд и данных не только по фронту, как в SDRAM, но и по спаду тактового сигнала. За счёт этого удваивается скорость передачи данных без увеличения частоты тактового сигнала шины памяти.

          • VBKesha
            /#21272914

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

            • beeruser
              /#21273354

              Так вот на на своей эффективной частоте она имеет ширину шины 32 бита.

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

              64 битная работа с памятью, при 32 битном интерфейсе самой памяти не даст никаких преимуществ

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

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


              • VBKesha
                /#21273450

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

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

                И как это превращает 32 бита в 64? Правильно никак.

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

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

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

                Ну так вот такое чтение можно сделать только за два такта эффективной частоты DDR, а не за один если бы разработчики поставили 2 чипа DDR(если конечно проц умеет работать с 64 битной шиной).

                • khim
                  /#21273718

                  А не могли бы вы перед продолжением спора всё-таки уточнить — о чём именно вы смотрите, а?

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

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

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

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

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

                  • VBKesha
                    /#21273762

                    Я лишь написал о том что несмотря на 64 битность процессора, данные не могут считываться по 8 байт за один раз, из за 32 битности шины памяти.

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

                    Про двухканал вообще никто не говорил.

                    • khim
                      /#21276148

                      Я лишь написал о том что несмотря на 64 битность процессора, данные не могут считываться по 8 байт за один раз, из за 32 битности шины памяти.
                      Но это как раз и есть те самые пресловутые «ангелы на кончике иглы»!

                      С вашим подходом получится, что вичестер вообще в принципе не может больше одного бита раз раз передавать. А видеокарта — может только 16 бит передавать, не более. Потому что в первом случае у вас один провод, во втором — не более 16.

                      Bred of very sif Cable.

                      На Raspberri pi используется, насколько мне известно, DDR3 память. За один цикл работы данной памяти из процессора в память (или обратно) передаётся, на минуточку, 256 бит данных. Да, они передаются по восемь бит по одному проводу — но это всё можно увидеть только и исключительно на осциллографе. «С толчки зрения софта» эта шина — передаёт 256 бит «за раз».

                      Потому и с спрашиваю про наблюдаемые эффекты. Какой смысл обсуждать то, что на программы ровным счётом никак не влияет?

                • beeruser
                  /#21273874

                  Как минимум это общепринятая абстракция.

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

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

                  Иначе говоря «MT/s» или «Mbit/s на контакт»

                  И как это превращает 32 бита в 64? Правильно никак.

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

                  Для этого как минимум надо чтобы данные были уже в кеше.

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

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

                  • VBKesha
                    /#21273902

                    За 1 такт передаётся 2 бита. 32*2 = 64. Повторение — мать учения :)

                    А нету нету никаких тактов, есть операции чтения и записи. И вот за одну операцию чтения мы получаем 32 бита.
                    За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.

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

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

                    Зато его можно умножить на два производя операции как фронту сигнала и так и по спаду(в отличии от SDR). И вот умножив мы тут и получим ту самую эффективную частоту.

                    • khim
                      /#21276240

                      А нету нету никаких тактов, есть операции чтения и записи.
                      Ура.

                      И вот за одну операцию чтения мы получаем 32 бита.
                      Опять 25. Нет. За одну операцию мы получаем 512 битов. Ибо так DDR4 устроена. Она собирает данные с 16 (восьми) ячеек памяти, потом мультиплексирует эти данные и отсылает в CPU по одному проводу. Последовательно, да.

                      За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.
                      С точки зрения софта — делает. А что там у вас осцилограф показывает — дело десятое. PCI-Express начиная с 3й версии вообще 128 бит пересылает как 130 бит на шине. Будем теперь это 130-битной шиной называть? Зачем?

                      Зато его можно умножить на два производя операции как фронту сигнала и так и по спаду(в отличии от SDR). И вот умножив мы тут и получим ту самую эффективную частоту.
                      Зачем вы обсуждаете то, что уже давно кануло в лету? В Raspberri Pi не DDR, а DDR4. Там уже давным-давно нет только двух фронтов сигнала. Там просто тупо выше частота шины, чем частота ячеек памяти. И потому — происходит мультиплексирование. Ну вот просто в табличку, блин, посмотрите: частота ячеек памяти — 200Mhz, частота шины — 1600Mhz. Не эффективная, а просто — вот на такой частоте оно работает. А смысл во всём этом появляется только из-за того, что одна транзакция, единичный акт передачи данных — пересылает не 32 бита, а больше. 512 бит конкретно в Raspberri Pi.

                      О каком 32-битном доступе при таких раскладах можно говорить — мне неведомо. По крайней мере на уровне софта эту 32-битность нельза прочувствовать никак.

                    • beeruser
                      /#21278098

                      А нету нету никаких тактов, есть операции чтения и записи.

                      Теперь вы отрицаете наличие тактового сигнала? o_O

                      И вот за одну операцию чтения мы получаем 32 бита. За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.
                      Так, так, и что мы получаем? 2*2 = 2?
                      Вы написали что за одну операцию происходит чтение 32бита, и что за такт выполняется 2 операции, так сколько же бит память передаёт за такт? ;)
                      32 * 2 = ???

                      И вот умножив мы тут и получим ту самую эффективную частоту.

                      WAT? Во-первых, период это величина обратная к частоте.
                      Во-вторых, вы проигнорировали моё замечание относительно некорректности термина.

                      Знаете что это напоминает? Людей, которые упорно называют системный блок «процессором», ведь это «общепринятая абстракция» в их круге общения.
                      Впрочем, говорите как хотите.

                      • VBKesha
                        /#21279308

                        Теперь вы отрицаете наличие тактового сигнала? o_O

                        Тактовый сигнал есть, но роль его может очень сильно меняться.
                        Так, так, и что мы получаем? 2*2 = 2?

                        Я могу пройти 100 метров за 100 секунд шагами по 1 метру делая 1 шаг в секунду.
                        Могу пройти 100 метров за 50 секунду шагами по 1 метру делая два шага в секунд.
                        И могу пройти 100 метров за 50 секунд делая 1 шаг в секунду, но шагая по два метра.
                        Скорость в двух последних случаях одна и таже. Но вот длинна шага(ширнина шины) от этого одинаковой не станет.
                        Во-вторых, вы проигнорировали моё замечание относительно некорректности термина.

                        Да как бы ru.wikipedia.org/wiki/DDR_SDRAM
                        «Таким образом, при работе DDR на частоте 100 МГц мы получим эффективную частоту 200 МГц (при сравнении с аналогом SDR SDRAM).»

                        en.wikipedia.org/wiki/DDR_SDRAM
                        «PC3200 is DDR SDRAM designed to operate at 200 MHz using DDR-400 chips with a bandwidth of 3,200 MB/s. Because PC3200 memory transfers data on both the rising and falling clock edges, its effective clock rate is 400 MHz.»
                        Вы меня извините но в двух версиях википедии данный неправильный термин во всё используется.
                        И даже если сделать вид что все кто используют термин неправы то Double Data Rate это всё таки не Double Data Width

                        • khim
                          /#21279584

                          Могу пройти 100 метров за 50 секунду шагами по 1 метру делая два шага в секунд.
                          И могу пройти 100 метров за 50 секунд делая 1 шаг в секунду, но шагая по два метра.
                          Скорость в двух последних случаях одна и таже. Но вот длинна шага(ширнина шины) от этого одинаковой не станет.
                          Я правильно понимаю, что обсуждение маразма, с которого всё началось (якобы невозможности считывания по 8 байт за одно чтение/запись из-за 32 битной шины) окончено?

                          И даже если сделать вид что все кто используют термин неправы то Double Data Rate это всё таки не Double Data Width
                          Это уже начались подсчёты «ангелов на кончике иглы». Как оно там называется — в принципе интересная дискуссия, но к исходному вопросу отношения не имеющая. За одно чтение/запись вы получаете гораздо больше 32 бит, а как это всё называть — это уже другой вопрос.

                          • VBKesha
                            /#21280088 / +1

                            Двое на одного, это уже перебор.
                            Всё вы меня затролили, я сливаюсь.

                            • Jogger
                              /#21283796

                              А можно я, можно я тоже?

                              Всё вы меня затролили, я сливаюсь.

                              Цель тролинга — спровоцировать горячую дискуссию (в идеале — вообще без дальнейшего участия троля). Если вы слились — значит как раз затролить не удалось.

  7. fougasse
    /#21270450

    Raspberry Pi4 в качестве embedded ограниченно применим. Конечно, для прототипов и домашнего применения — отличная штука, но в других случаях, особенно с отрицательной/высокой температурой сложновато.
    Проблема указателей преувеличена, как мне кажется.

    • lingvo
      /#21272250

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

      • Dima_Sharihin
        /#21274622

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

  8. alex-khv
    /#21270690

    Может еще кто-то не видел данный обзор «Большой тест мини-ПК 2019»

    • homocomputeris
      /#21272056

      Odroid N2, к сожалению, нет. Он вроде как разрыватель по сравнению с другими.

  9. GBK
    /#21270966

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

    • arkamax
      /#21272994

      Хм. В моем кругу (далеко не хиппарей и всем сильно меньше 50) PF не только слушают, но и считают классикой.

  10. vagran
    /#21271182

    Pi 3 тоже 64 бита.

  11. eugene08
    /#21271204

    > Не рекомендую использовать такие системы в подобных целях, но у многих людей всё ещё есть медленное подключение к интернету (менее 100 Мб), поэтому они могут не обращать внимания на медленную работу Raspberry Pi4.
    а почему не рекомендуете? и что порекомендуете взамен? как раз рассматриваю rpi4 как файрвол + wireguard впн для домашней сети, обычные роутеры которые видел — все равно сильно слабее.

    • safari2012
      /#21271462

      нормально потянет, ещё и wi-fi можно оттуда же раздавать.

  12. mpa4b
    /#21271342

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

    • eugene08
      /#21271416

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

    • Dima_Sharihin
      /#21271568

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


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


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

  13. blind_oracle
    /#21271354

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


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

  14. Tangeman
    /#21271600

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

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

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

    Если это будет супернагруженный web/nas/vpn-server, причём с гигабитным траффиком — другое дело, но тут уже возникнет вопрос, стоит ли для такой роли использовать RPi?

    • safari2012
      /#21271658

      Недостатки платформы часто являются обратной стороной её достоинств. Уже столько легаси под 32бита, что комьюнити, видимо, считает, что оно того пока не стоит.
      Что касается серьезных задач, то и Intel NUC её не заменит, т.к. точек отказа ровно столько же, а производительности на Ватт, наверное тоже.

  15. aliend
    /#21271990

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

    • IGHOR
      /#21272514

      А Bluetooth там работает?

      • aliend
        /#21272610

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

  16. RedSun-ops
    /#21272544

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

    • aliend
      /#21272704

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

  17. Peter1010
    /#21272908

    Был бы ещё raspbian 64х битный… А так, ubuntu слишком тяжелая… А lubuntu и Xubuntu под pi нет :)
    Нет, конечно можно скачать server версию а потом

    sudo aptinstall lubuntu-desktop

  18. apro
    /#21273388 / +1

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

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

    • khim
      /#21273744

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

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

      Но не знаю как это отличие правильно описать короткой фразой.

  19. AlexAV1000
    /#21273484

    А образ-то где взять 64-битный? Самому что ли собирать?

  20. Suveren
    /#21273600 / +1

    Достаточно наглядное сравнение производительности, спасибо за перевод, однако ARM — это всё-таки не память, а процессор :-)

    … что означает 64-битную память.

    Оригинал: «which means 64 bit ARM.»

  21. kovserg
    /#21273662

    Очень интересно сравнение энергопотребления для 32 и 64бит кода, выполняющего одинаковые задачи.

    • khim
      /#21273750

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

      То есть практически — ARM64 тут тоже выигрывает при правильно написанном софте.

      • kovserg
        /#21274074 / +1

        Хочется реальных данных

  22. Pilat
    /#21273778 / +1

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