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

Original author: Matteo Croce
  • Translation
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, но я не знал, насколько лучше. Поэтому я провёл все эти тесты. Надеюсь, вам понравилось!
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 143

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

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


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

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

              amd64 — закостыленный монстр, где инструкции раздуваются за счёт размазывания опкода и операндов по этим уродливым префиксам.
              Врядли имеет смысл сравнивать их с арм/арм64 с фиксированной длиной команды.
                0
                А почему нет? В x86-64 префиксы добавили, в ARM64 (официальное название — Aarch64), наоборот — убрали.

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

                Конечный результат-то всё равно один: 64-битный код немного больше. Но не в 1.5 раза, это какая-то анамалия.
                +1
                Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза.

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

                +1
                Проверить легко. Качаем Virtualbox, ставит 2 инстанса (32,64), качаем по Firefox/Chrom и смотрим потребление при открытии 4-5 страничек gmail/docs в виртуалках. Попробуйте, делов на 1.5 часа. Результат того стоит. У меня в тестах разница в потребляемой памяти была в 1.8 раз, но это было в 2014. Сейчас должно вырасти больше.
                  0
                  Ну если нам не хватает четырёх Гб на Pi4, то, наверное, мы вообще выходим за пределы возможностей малинки. А при достаточном объёме памяти — автор демонстрирует нам преимущества.
                    0
                    На 4-х гигах вернее отбросить ~700MByte памяти и ставить 32 бита, чем ставить 64. Только это я и хотел сказать.
                    И, да, при условии когда у данной малинки важнее не свободная память, а скорость работы с 64-битными целыми или float, вероятно, всё-таки вернее ставить 64бит ось. Но этот случай гораздо реже при использовании малины, чем нехватка памяти и уход в свап. И уж точно ближе к формулировке «выходим за пределы возможностей малинки»
                      0
                      На 4-х гигах вернее отбросить ~700MByte памяти и ставить 32 бита, чем ставить 64. Только это я и хотел сказать.
                      Что лучше: потратить лишние 700 Мб памяти на 64-битные приложения (хотя это какой-то очень суровый случай) и получить прирост производительности или просто выкинуть 700 Мб в никуда?
                        –1
                        Лучше всего вспомнить про первые 64-битные Sparc'и и использовать 64-битное ядро с 32-битными программами.

                        Впрочем там была шибко уважительная причина: поддержка 64-битных программ была небезопасной из-за ошибок в железе (в поздних stepping'ах вроде поправили, но подход на несколько лет остался).
                          +1
                          Если не упадём в swap. Если упадём — про производительность можно забыть.
                  0
                  devblogs.microsoft.com/oldnewthing/20031008-00/?p=42223 или нет, ктож его знает
                    0
                    Зато регистры стали в два раза толще, что может спасти от лишних обращений к памяти.
                      +1
                      Если рассматривать конкретно x86, то регистров стало ещё и больше.
                        0
                        В ARM их тоже стало больше.
                    0
                    Отличные тесты!
                    Довольно наглядно видна разница.

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

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

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

                    Ubuntu?
                      +1
                      По большей части все крупные, у кого есть aarch64 — AltLinux, Centos, Debian + все наследники, Fedora, Freebsd. Вопрос конечно в наполнении репозиториев и в поддержке периферии конкретно распберри в ядре, но попробовать уже есть что
                        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

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

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

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

                                  0

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


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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

                                      +2
                                      Посмотрите на темы NAND read disturb и NAND write disturb.
                                    0
                                    Аналогичная проблема. Не смогли внедрить систему из-за того что малинка падала раз в неделю после перезагрузок. Greatly appreciate any advise.
                                      +1

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


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


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


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

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

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

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

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


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

                                      +1

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

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

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

                                        0

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

                                          +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 вообще оч плохо)
                                            0
                                            Если у вас есть PlexPass, можете попробовать github.com/UnicornTranscoder/UnicornTranscoder — это позволит делать транскодинг силами аппаратного ускорения и для arm плат. По крайней мере, я видел такие отзывы.
                                            В крайнем случае — можно будет вынести транскодинг на другое устройство, которое включать только по необходимости.
                                          +2
                                          что означает 64-битную память.

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

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

                                                    Серверные Windows 2003-2008 x86 могут работать с 4-128 ГБ памяти.
                                                    А в пользовательских ОС MS из-за маркетинга могло определяться всего 2,75-3,25 при 4ГБ установленных. С внешней видеокартой.
                                                    И на эту тему есть неофициальный патч fix128 на rutracker.org.

                                                      0
                                                      А в пользовательских ОС MS из-за маркетинга могло определяться всего 2,75-3,25 при 4ГБ установленных.
                                                      К сожалению или к счастью — но нет, это не просто маркетинг. Для того, чтобы нормально работать в системе, где невозможно замапировать всю память одновременно драйвера должны это учитывать.

                                                      Драйвера от Microsoft и для серверного железа, конечно, к этому готовы, а вот драйвера от производителей разных странных китайских железок… не очень.
                                                        0
                                                        Отчасти разделение между Home и Enterprise редакций, было по причине наличия/отсутствия физических линий шины контроллера памяти в северном мосту.
                                                        Это было во времена DDR1.
                                                        К тому же, уже говорилось что серверные ОС могли адресовать всю память через PAE. Помню ставили 2003 на домашний комп с 4Гб, но заканчивалось зависанием системы после загрузки драйверов для NVidia.
                                                      +1
                                                      OMG. 2 << 32 это и есть _ровно_ 4ГБ
                                                        0
                                                        Может быть он имел в виду десятичные гигабайты? =)
                                                          +3
                                                          > 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, где виртуальная трансляция может отключаться при переходе простым прерыванием в режим ядра, но не думаю, что вы легко найдёте такую машинку в доступе (и вас устроит цена).
                                                            –2
                                                            Не буду таким же занудным, но таки напомню про PAE
                                                              +5
                                                              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-адресами, категориями памяти «до» и «после» границы, частыми переключениями пейджинга, выглядываниями через узкое окошко… они массово и с обычной плоской памятью-то еле справляются, а вы хотите ещё более странного.

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

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

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

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

                                                                    0
                                                                    Спасибо :)

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

                                                                      Acquire-Release семантика про другое.
                                                                      The basic principle of both Load-Acquire and Load-AcquirePC instructions is to introduce order between the memory access generated by the Load-Acquire or Load-AcquirePC instruction and the memory accesses appearing in program order after the Load-Acquire or Load-AcquirePC instruction, such that the memory access generated by the Load-Acquire or Load-AcquirePC instruction is Observed-by each PE, to the extent that the PE is required to observe the access coherently, before any of the memory accesses appearing in program order after the Load-Acquire or Load-AcquirePC instruction are Observed-by that PE, to the extent that the PE is required to observe the accesses coherently.


                                                                      Простыми словами, LDAR должен стать глобально видимым раньше, чем все обращения в память, находящиеся в program order позже LDAR. Например, рассмотрим следующую последовательность инструкций:
                                                                      LDR Rx, [A]
                                                                      LDAR Rz, [B]
                                                                      AFTER:
                                                                      STR Ry, [C]

                                                                      В этом коде семантика Acquire гарантирует, что результат STR Ry, [C] будет глобально видимым не раньше, чем будет глобально видимым результат LDAR.

                                                                      Аналогично, семантика Release: все обращения в память, находящиеся в program order раньше STLR, должны стать глобально видимыми до того, как глобально видимым станет результат STLR.

                                                                      Эта семантика позволяет избавиться от DMB в некоторых случаях, в частности, в захвате спин-лока.

                                                                      Более подробно смотрите в «Arm Architecture Reference Manual®. Armv8, for Armv8-A architecture profile», редакция E.a (от 5 июля 2019), главы B2.3.7, K11.2 и K11.6
                                                                        0
                                                                        Спасибо за ответ, но он не о том, что я спрашивал. Видимо, надо было расширить исходный вопрос.
                                                                        Я уже спрашивал на SO, но там ответ по сути был только «раз работает — значит, об этом подумали», но хотелось прямого подтверждения. Переложу тут.

                                                                        Представим себе спинлок, где 0 — свободен, 1 — захвачен, и данные под ним. Если ядро поработало с данными и освобождает спинлок (записью 0 по его адресу), оно должно обеспечить, что все операции с данными, которые делаются до освобождения спинлока, должны быть увидены другими до того, как они увидят эту запись 0. Это делается или через (почти полный) барьер «RW — до, W — после», или через пометку release semantics на операции записи в спинлок (тогда барьер будет только между чтениями-записями до и одной конкретной записью).

                                                                        Теперь перейдём к захвату спинлока. Для ARM это будет: load-acquire-exclusive; проверка, что прочлось 0 (иначе идём на следующую попытку); store-exclusive значения 1 (ядро проверяет, что этот адрес никто не тронул, и тогда атомарно допускает запись); не получилось — на следующую попытку. Всё типа хорошо? Но: для других ядер признаком захвата спинлока будет операция записи 1 по его адресу. Значит, мы не можем работать с данными под ним, если не обеспечим, что эта операция увиделась другими прежде, чем мы начнём работать с защищаемыми данными. Это опять же или барьер «W — до, RW — после», или — для одной конкретной операции — называется acquire semantics. Но флаг acquire semantics можно ставить только на чтение! а чтение из спинлока ещё не даёт никакого захвата, это просто чтение. И вот тут логический разрыв: acquire semantics нужна для записи по адресу спинлока, а не чтения (чтобы остальные ядра увидели, что он захвачен), но ставить флаг можно только на операции чтения!

                                                                        Я погуглил, нигде не нашёл ответа, и предположил, что тут какое-то тайное знание, которое подразумевается, но не высказывается. Спросил на SO. Ответ был таким же по сути — из обратной индукции: «раз оно не глючит — значит, это предусмотрели; а раз предусмотрели — значит, acquire semantics для exclusive load автоматом распространяется на парное ему exclusive store». Но я хотел увидеть это написанным явно.

                                                                        То, что вы описали и пояснили, не даёт всего нужного именно потому, что вы пишете

                                                                        > В этом коде семантика Acquire гарантирует, что результат STR Ry, [C] будет глобально видимым не раньше, чем будет глобально видимым результат LDAR.

                                                                        во-первых, лучше таки говорить про exclusive варианты операций, чтобы не запутывать сами себя; во-вторых, видимость LDAXR (которая прочитала 0) другим участникам совершенно пофиг — мне нужно, чтобы видимость этой парной ему STXR (которая пишет 1 по адресу спинлока) была обеспечена другим до экспорта всех последующих операций данного ядра с памятью.

                                                                        > Аналогично, семантика Release: все обращения в память, находящиеся в program order раньше STLR, должны стать глобально видимыми до того, как глобально видимым станет результат STLR.

                                                                        Тот код, который находится в доступных источниках и который предназначен (и) для ARM, не компилируется в запись через STLXR; там генерируется STXR. И оно явно работает как надо (иначе бы таки давно исправили).

                                                                        То ли я в упор не вижу нужное утверждение в документации, то ли его таки нет :(
                                                                          0
                                                                          Давайте рассмотрим следующий пример:
                                                                          ; Spinlock Acquire
                                                                              PRFM PSTL1KEEP, [X1] ; preload into cache in unique state
                                                                          Loop
                                                                              LDAXR W5, [X1] ; read lock with acquire
                                                                              CBNZ W5, Loop ; check if 0
                                                                              STXR W5, W0, [X1] ; attempt to store new value
                                                                              CBNZ W5, Loop ; test if store succeeded and retry if not
                                                                          ; loads and stores in the critical region can now be performed
                                                                              STR X25, [X10]
                                                                          ; Spinlock Release
                                                                              STLR WZR, [X1] ; clear the lock with release semantics
                                                                          


                                                                          Здесь возможны варианты:
                                                                          1. Спинлок был свободен и мы смогли его захватить. Тогда не важно, в каком порядке другие потоки будут наблюдать захват спин-лока. Они всё равно не смогут его захватить и, соответственно, исполнить STR X25, [X10].
                                                                          2. Нам не удалось захватить спин-лок. Тогда мы не сможем исполнить STR пока спин-лок не освободят. В этом случае мы гарантированно увидим STXR и STR до того, как спинлок освободят. Это нам гарантирует семантика Release в освобождении спинлока.

                                                                          Впрочем, соглашусь, это описано в документации недостаточно явно. Но при этом документация прямо говорит, что такая реализация спинлока правильная. Описано в главе K11.3.
                                                                            0
                                                                            > В этом случае мы гарантированно увидим STXR и STR до того, как спинлок освободят.

                                                                            Хм, получается, что гарантия тут собственно за счёт результата проверки exclusive write. Процессор её не отложит не потому, что вводится какое-то левое упорядочение, а потому, что он вообще не пойдёт выполнять чтение-запись данных под локом, если нет подтверждения на корректность записи. Только если мы таки захватили лок, эти операции начнут реально выполняться. Это уже из серии «слона-то я и не заметил» (tm).

                                                                            > Описано в главе K11.3.

                                                                            Надо будет перечитать. Но как оно спрятано под невнятным названием :) спасибо! будет чтиво на долгие зимние вечера.
                                                              +1
                                                              OMG, но 2<<32 это 8ГБ.
                                                                +1
                                                                ну конечно же. но 32бита адресуют ровно 4ГБ, именно это имелось в виду
                                                            0

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

                                                          +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» человек пишет статью с какими-то невнятными бенчмарками?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                              Bred of very sif Cable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                И вот за одну операцию чтения мы получаем 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-битность нельза прочувствовать никак.
                                                                                                  +1
                                                                                                  А нету нету никаких тактов, есть операции чтения и записи.

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

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

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

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

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

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

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

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

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

                                                                                                          По моему этот вопрос скорее про Dual-channel architecture и даже там под сомнением остался:
                                                                                                          https://en.wikipedia.org/wiki/Multi-channel_memory_architecture


                                                                                                          "Ganged versus unganged
                                                                                                          Dual-channel was originally conceived as a way to maximize memory throughput by combining two 64-bit buses into a single 128-bit bus.[disputed – discuss][citation needed]"

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

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

                                                                                        +1

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

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

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

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

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

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

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


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


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

                                                                                                  +1

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


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

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

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

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

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

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

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

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

                                                                                                        0

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

                                                                                                          +2

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

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

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

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

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

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

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

                                                                                                                    То есть практически — ARM64 тут тоже выигрывает при правильно написанном софте.
                                                                                                                      +1
                                                                                                                      Хочется реальных данных
                                                                                                                    0
                                                                                                                    Есть такая фирма FriendlyElec (FriendluARM). Она делает те же процессорные платы, но без видео (и с видео тоже делает) и с кучей очень разных плюшек, вот на них и надо запускать подобные тесты. А RaspberryPI это уже какой-то комбайн без понятного позиционирования, зачем на нём запускать тест кодирования звука? Что, кто-то будет этим заниматься? Тестировать надо практические задачи, а они для RPi — медиасервер и всё, остальное только от незнания о существования альтернатив.
                                                                                                                      0
                                                                                                                      Внезапно спустя неделю эксперементов, под pi 4 нет ни одного стабильного aarch64 дистрибутива с GUI.
                                                                                                                      Даже банальная попытка накатить на ubuntu-server lubuntu-core приводит к чёрному экрану. После починки обнаруживается целая россыпь проблем и крешей.
                                                                                                                      Mate под pi4 нет, а от b3+ не подходит.
                                                                                                                      CentOS не стартует из коробки.
                                                                                                                      После Курения форумов добился появления признаков жизни, но возиться далее желание отпало.
                                                                                                                      Fedora так же отсутствует под pi4.

                                                                                                                      Выводы не утешительные. Максимум что можно заюзать это ubuntu-server без GUI. И то теперь есть сомнения в стабильности.
                                                                                                                        0

                                                                                                                        Я ранее писал, что можно использовать Manjaro. Сам уже некоторое время на ней сижу (установил редакцию с KDE). И к слову о MATE: сейчас в репозиториях ArchLinux как раз самая последняя версия 1.24, и нет никакой проблемы её установить. Глюки KDE меня как раз заставили уйти в MATE на этой машинке.

                                                                                                                          0
                                                                                                                          Дополнение на 26/07/2020: поставил на RPi4 ubuntu-server, добавил ubuntu-desktop — работает почти всё, сразу после установки были разнообразные глючки, после установки обновлений стало сравнительно стабильно.
                                                                                                                          Из недостатков — плохо с видеодрайвером, 500 рыбок в webgl — 8 fps (софт). Видео тоже крутится только 720p и с подтормаживаниями. Звук тоже проблемный — через hdmi никак не хочет идти.
                                                                                                                            0
                                                                                                                            через hdmi никак не хочет идти.
                                                                                                                            У меня Он идет только через один из двух. Но у меня телек SONY там это известная проблема с пишками.

                                                                                                                            Недавно снова поставил x64, уже стало получше. Gnome завёлся и вроде бы пока что всё ок.
                                                                                                                            С видео, да есть засада, x32 тянул ютуб в fullhd а вот на x64 я ловлю слайдшоу. :( Но есть уверенность что скоро поправят. Тем более я ещё не проверял как оно там на расбиане который x64. Думаю ближе к НГ его зарелизят. Возможно к тому времени как-раз и пофиксят всё.

                                                                                                                        Only users with full accounts can post comments. Log in, please.