Comments 144
Выравнивание — нередко означает снижение эффективной пропускной способности памяти. Грубо говоря, если для доставания двух 32-бит аргументов физически нужно прочитать 2 участка по 64бит — мы ничего не выигрываем, а если они ещё и выравниваться все должны — то расход памяти для данных растёт вдвое.
Я видел, как это широко используется в solaris. Разные системные бинари, типа chmod, passwd и прочее нересурсоёмкое — 32-битное. При этом ядро 64-битное. При сборке своей программы надо всего лишь указывать флажок в gcc.
А с выравниванием — отдельная тема. Надо понимать, что оно не всегда безопасно. Если на x86 можно положить 32-битное целое по нечётному адресу и это не вызовет проблем, кроме замедления, то уже атомик того же размера так не положишь. В подавляющем случае за этим всем следит компилятор. Но если вдруг стоит задача управлять этим вручную (например, компактно сериализовать данные без промежутков), то там кроме кастомного выравнивания обычно заодно применяются и другие штуки, вроде vbl-сжатия.
Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза.
amd64 — закостыленный монстр, где инструкции раздуваются за счёт размазывания опкода и операндов по этим уродливым префиксам.
Врядли имеет смысл сравнивать их с арм/арм64 с фиксированной длиной команды.
Визуально сравниваем бинарники 32 и 64бит (i386 vs amd64) — и часто видим разницу порядка 1,5 раза.
Допустим, но при чём здесь указатели?
И, да, при условии когда у данной малинки важнее не свободная память, а скорость работы с 64-битными целыми или float, вероятно, всё-таки вернее ставить 64бит ось. Но этот случай гораздо реже при использовании малины, чем нехватка памяти и уход в свап. И уж точно ближе к формулировке «выходим за пределы возможностей малинки»
На 4-х гигах вернее отбросить ~700MByte памяти и ставить 32 бита, чем ставить 64. Только это я и хотел сказать.Что лучше: потратить лишние 700 Мб памяти на 64-битные приложения (хотя это какой-то очень суровый случай) и получить прирост производительности или просто выкинуть 700 Мб в никуда?
Впрочем там была шибко уважительная причина: поддержка 64-битных программ была небезопасной из-за ошибок в железе (в поздних stepping'ах вроде поправили, но подход на несколько лет остался).
Довольно наглядно видна разница.
Я как раз собирался себе прикупить это чудо для простенького домашнего сервера на медиа и автоматизацию, но даже знать не знал что он поддерживает 64, хотя догадаться можно было.
Вопрос только — а насколько хорошо будет реализована поддержка софтом?
Что вообще можно поставить на четверку из систем под 64 без самостоятельной сборки, просто чтобы поставил и работало?
Ubuntu?
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
Но у меня их образ не хочет грузиться на малинке.
данные на ФС «самоизменяются», причем совсем не те, которые ты перезаписываешь
А можно подробнее про эту черную магию? Просто я с серией Sandisk Pro / Extreme неплохо знаком, использую их годами в зеркальных фотокамерах, видеокамерах, диктофонах, еще черт знает где — никогда данные сами собой не слетали, кроме как в малинках. Но симптомы в духе «оно работало, а теперь нет» — очень знаком именно применительно к малинам, и пока я не нашел, чем это объяснить, кроме как столь нелюбимым мной полтергейстом.
Всё же нагрузка в фотоаппарате куда легче, чем в компьютере в роли загрузочного диска.
А ещё неплохо бы сислог отрубать, иначе флешка даже без бросков питания дохнет в ноль года за два.
Можно разбить флешку пополам на два раздела, в один записать тестовые данные и скрыть. И дальше использовать только как флешку двукратно меньшего объёма (можно и на полку положить, но это уже чуть другие условия, хотя бы по температуре).
Через 3-4 года можно попытаться прочитать архивный раздел и неприятно удивиться...
На флешке в "малинке" похожие условия: есть множество системных файлов, которые никогда не меняются, а какие-то даже читаются достаточно редко. Есть активные секторы, которые изнашиваются записью. И плюс это всё в рабочем состоянии при повышенной температуре. И внезапно даже никакие особые броски напряжения не нужны, оно само со временем вдруг умрёт…
Раньше, когда только появились Asus EEEpc с тормозными ssd на борту было целое направление оптимизаций, чтоб продлить ресурс. Например, unionfs/aufs с нижним слоем из squashfs, отключение логов и при желании периодический ребилд read-only слоя для актуализации.
Нынче подобная модель используется практически во всех роутерах: грузимся с read-only раздела, пишем в память. Но там это ещё проще, покуда пользовательских данных, которые нужно сохранять, как правило, вообще нет.
На настоящих та же проблема.
Данные, к которым долго не обращаются — "забываются". Заряд уходит из ячеек. Особенно при повышенной температуре (т.е. при эксплуатации).
В принципе, профилактическое чтение всего хранилища где-нибудь раз в полгода может помочь (типа, dd if=/dev/sdX of=/dev/null...). Где-то, возможно, это уже делает сам контроллер. Но в целом мысль такова, что для долговременного ("вечного") хранения ssd не годится.
У флешек обычно другая память на борту. И совершенно другая манера использования (они обычно бОльшую часть времени всё же лежат на полке, а не торчат в порту). Соответственно, температура ниже, данные стареют медленнее.
У ssd, который на борту, особенно где-нибудь в замкнутом пространстве ноутбука всё гораздо печальнее.
Ну вот я тоже понадеялся на опыт и пролетел.
Всё зависит от использования.
У меня раздел с неиспользуемой убунтой стоял нетронутым лет около пяти. А потом я попытался в неё загрузиться, и не смог.
Здесь сложились факторы, что к данным вообще не обращались (даже случайно). Плюс, это рабочий ssd в ноуте, включённом 24х7, т.е. постоянно тёплый/горячий. Вот оно и "выстрелило".
Но покуда есть такая явная зависимость от условий, лучше эти факты сразу учитывать.
MacBook air, early 2014.
SSD его штатный
Может быть просто диск был изношен сильно? Какой у него был объем и какой объем записанной информации?
Ну, наверное всё же не перезаписываются (а с чего вдруг?). Или недостаточно.
Ноут свежий, диск на нём тоже.
Был включён практически 24/7 (хотя на макбуке с его достаточно глубокой спячкой это не сильно принципиально).
На полдиска стояла ubuntu (очевидно — 14.04). В 2016-м её использование прервалось и я перешёл на родную макось. Осенью 2019-го загрузиться в неё уже не смог (скорость чтения упала до <900кб/с, а где-то вообще выскакивала ошибка чтения). В итоге нужное с трудом таки выцарапал, разделы чуть-чуть подвигал, и вроде всё вылечилось. Но осадок остался ).
«Другая» это в чём отличие от SSD?
Cпособность забыть без чтения это специфика собственно версии ячейки из транзистора с плавающим затвором, или нет? Вряд ли тут влияет NAND vs. NOR, поэтому что это организация доступа к ячейкам. Или у них ещё и кросс-влияние?
Флешки появились всё же гораздо раньше ssd "на борту". Как и всевозможные memory stick/sdcard. Думаю, это как раз издержки технологии, которая сперва не давала возможность сделать память с достаточным ресурсом перезаписи.
Кажется, что и нынешние экземпляры — они тоже скорее предназначены для переноса файлов и хранения "на полке", чем для использования в качестве постоянно включенного основного диска, куда постоянно что-то пишут.
Казалось бы, можно в телефон вместо встроенной прошивки приспособить microsd-карту. Но по факту я видел очень много внезапно умерших карт. И всего один телефон, у которого вдруг полетела внутренняя память.
То же с этим помучился (установка "из коробки") — любой сбой по питанию 10..20% вероятность порчи fs и невозможность перезапуститься малине заново.
Но нашел решение.
Для своей системы видеонаблюдения сделал весь SD readonly. Причем смысла делать честь физического диска rd-only, а часть rw. Это не спасает (с SD картой, по крайней мере). Нужно все тома на SD загнать в rd-only режим.
Пришлось повозится, но оно того стоило. За много месяцев эксплуатации с нередкими сбоями по питанию и перезагрузками по выключению питания, проблем нет.
Все что нужно писать (логи, временные файлы с данными) — пишется в tmpfs. После дополнительной настройки вполне хватает небольшого размера tmpfs.
В принципе, можно и отдельный (физически) 2-й диск примонтировать для rw данных. Начиная от USB диска, кончая SPI флеш памятью. И востанавливать его автоматически/программно после сбоя (хотя бы переформатированием).
Но, мне не актуально (второй rw диск), все одно данные тут же в облако сливаются и tmpfs как буфера вполне хватает.
Соотвественно если вы не можете обеспечить, чтобы в момент перезагрузки на SD-карту ничего не писалось (а это тяжело сделать если туда, скажем, пишутся логи) — то готовьтесь через некоторое время «огрести».
А если ничего не писать — данные хранятся годами (но не десятилетиями… со временем всё-таки содержимое с SSD «утекает»… про это нужно не забывать).
Ну вот вроде и нашли проблему: поскольку стираются данные на флешке куда большими блоками, чем пишутся, то при записи на флешку даже те данные, которые, вроде как, вы не трогаете — могут потеряться (потому что вот именно их контроллер решил перенести с одного места на другое «для надёжности»).
Так это известная вещь. Размер блока на SD 512 байт. Но даже их сразу никто не пишет, поскольку через SDIO интерфейс пишут не на прямую, а с использованием DMA. Не знаю, какой у драйвера linux типичный DMA буфер для записи на карту. Но даже на контроллерах меньше 2Кб смысла обычно нет.
Вероятность проблем, если дернуть питание при записи, — 100%. просто иногда эти проблемы остаются скрытыми (попортилось не в критическом для работы OS месте).
решается переводом SD в read-only режим.
Мне помогло.
Как показывает практика, софта под aarch64 достаточно, всякие хромиумы и VLC присутствуют, если будет заметен дефицит софта, то всегда есть AUR, хотя найти IDE всё ещё проблематично.
По моему скромному и субъективному, (не)самой большой проблемой для Raspberry Pi 4B является недостаток различных дистрибутивов, выбирать приходится между Arch/Manjaro, Gentoo, Ubuntu и Raspbian/Debian. Т.е., всё настолько скудно, что я даже не получился их всех перечислить, ибо перечислять толком нечего.
Можно попробовать Manjaro: https://manjaro.org/download/#raspberry-pi-4
Я уже пару дней экспериментирую с этим дистрибутивом. Работает всё на удивление хорошо в сравнении даже с Raspbian (на сайте Raspbian можно почитать про множество багов, появляющихся после обновлений). Замеров никаких не делал. Только вижу, что KDE практически не тупит в сравнении с Raspbian (туда я ставил KDE только для эксперимента).
Вопрос только — а насколько хорошо будет реализована поддержка софтом?
Вполне ок. Все что есть под armv7l — собирают под arm64, в тч сразу куча готовых вещей в имаджах на dockerhub. На моей дома крутится ubuntu (не snappy, а та которая с «легаси» apt) на ней docker в котором qbittorrent-nox, plex server, homeassistant, pihole, пара пет проектов, база под них, traefik для роутинга на все это дело.
Была единственная трабла — 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 вообще оч плохо)
В крайнем случае — можно будет вынести транскодинг на другое устройство, которое включать только по необходимости.
что означает 64-битную память.
Я, конечно, всё понимаю, но этого я понять не могу. И даже не только потому что в оригинале "which means 64 bit ARM".
Даже Винда 32-битная (далеко не лучший пример) может из коробки адресовать 3 с чем-то гигабайт.
А как удалить коммент?
Серверные Windows 2003-2008 x86 могут работать с 4-128 ГБ памяти.
А в пользовательских ОС MS из-за маркетинга могло определяться всего 2,75-3,25 при 4ГБ установленных. С внешней видеокартой.
И на эту тему есть неофициальный патч fix128 на rutracker.org.
А в пользовательских ОС MS из-за маркетинга могло определяться всего 2,75-3,25 при 4ГБ установленных.К сожалению или к счастью — но нет, это не просто маркетинг. Для того, чтобы нормально работать в системе, где невозможно замапировать всю память одновременно драйвера должны это учитывать.
Драйвера от Microsoft и для серверного железа, конечно, к этому готовы, а вот драйвера от производителей разных странных китайских железок… не очень.
Это было во времена DDR1.
К тому же, уже говорилось что серверные ОС могли адресовать всю память через PAE. Помню ставили 2003 на домашний комп с 4Гб, но заканчивалось зависанием системы после загрузки драйверов для NVidia.
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, где виртуальная трансляция может отключаться при переходе простым прерыванием в режим ядра, но не думаю, что вы легко найдёте такую машинку в доступе (и вас устроит цена).
И причём это не первый раз: сначала был PDP-11, с его 16-битным окном в 18- или 22-битный мир — и переход на VAX с его 32-битными виртуальными адресами. Потом 8086 с сегментами — и 80386 с 32-битными виртуальными адресами во времена RAM в единицы мегабайт. Теперь то же массово на границе 32/64. Ну не хотят программисты мучаться со всеми этими far-адресами, категориями памяти «до» и «после» границы, частыми переключениями пейджинга, выглядываниями через узкое окошко… они массово и с обычной плоской памятью-то еле справляются, а вы хотите ещё более странного.
Так что тут лучше честное занудство, чем предложение другим взваливать на себя подобные марудные хлопоты…
И пае прозрачен для приложений, если используется системой.
Точно так же для 64бит системы, 32-бит приложение может _прозрачно_ использовать 4Гб. Как минимум на x64
У кого то прст слишком богатая фантазия.
На ARMv8-A обязательно должно быть реализовано LPAE для 32-битного режима. Ну, если 32-битный режим вообще поддерживается чипом, конечно. Это описано в ARMv8 architecture reference manual.
Если вы осилили этот толстенный документ, задам вопрос в совершенно другую сторону. Пусть есть пара инструкций LDAXR + STXR (например, захват спинлока). Сказано ли где-нибудь явно, что acquire semantics из LDAXR (в отличие от LDXR) распространяется на парную ему успешно сработавшую STXR?
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
Я уже спрашивал на 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. И оно явно работает как надо (иначе бы таки давно исправили).
То ли я в упор не вижу нужное утверждение в документации, то ли его таки нет :(
; 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.
Хм, получается, что гарантия тут собственно за счёт результата проверки exclusive write. Процессор её не отложит не потому, что вводится какое-то левое упорядочение, а потому, что он вообще не пойдёт выполнять чтение-запись данных под локом, если нет подтверждения на корректность записи. Только если мы таки захватили лок, эти операции начнут реально выполняться. Это уже из серии «слона-то я и не заметил» (tm).
> Описано в главе K11.3.
Надо будет перечитать. Но как оно спрятано под невнятным названием :) спасибо! будет чтиво на долгие зимние вечера.
Ну а теперь немного "радости". Я поднял этот вопрос на SO: https://stackoverflow.com/q/58361491 (как тут ссылки в новом редакторе правильно вставлять? не понимаю) и в итоге получил ссылку на реальный пример, где вся эта логика не работает: https://stackoverflow.com/a/66265727/
Я её проверил на реальном ARM (нода на AWS - достаточно реально?) - получается, описанный реордеринг таки происходит. При цикле вокруг LDAXRB и парном к нему STLXRB.
(Чтобы проверить пример, пришлось делать отдельный ассемблерный исходник - в штатных atomic функциях оно пыталось в рантайме найти и применить SWPALB.)
Так что или вам что-то другое в реальном примере помогло... или всё плохо. Ну или автор ответа ошибся в логике, IMHO минимально вероятное.
Что нормально-то? В оригинале говорится про 64-битную архитектуру ARM, которая в переводе превратилась в, видимо, RAM. То что у нас теперь имеется доступ к большему объёму памяти, не меняет разрядность памяти.
Я взял другую карту памяти и поставил на неё 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» человек пишет статью с какими-то невнятными бенчмарками?
Вопрос риторический, я понимаю что это перевод. Но обидно.
На Raspberry Pi4 стоит четырёхъядерный ARM Cortex A72, до 4 ГБ памяти и гигабитный порт Ethernet – и всё это всего за $35.
Враньё чистой воды — этот конфиг стоит не 35!
Враньё чистой воды — этот конфиг стоит не 35!
За столько, сколько он стоит, можно взять Orange pi 4 на rk-3399.
Поинтереснее железка.
Нет, нет и нет.
Выбор между малиной и китайским нонеймами очевиден (рассмотривать стоит лишь пайн, одройды, тинкерборды, невидию, интель, etc)
Не знаю, как дела обстоят с рокчипом, но с всепобедителем не было ни работающей оси, ни работающих дров, ни поддержки ядром, ни поддержки вендором, ни комьюнити.
Тем более появился Raspberry Pi 4.
Медный радиатор за 1,49 неплохо справляется с ней в пассиве, если не грузить все 4 ядра+видео (openssl speedx4+glxgears).
У Распберри есть грмадное коммьюнити, до которого зоопарк других одноплатников «не дорос» — именно из-за зоопарковости.
Правда. Я еще замечу что малина 4гб + переферия в виде оф набора чуть дешевле наков от Интела. Только они на голову выше малины.
64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись.
Как бы да, но на самой плате стоит чип памяти DDR4(k4f8e304hb для 1Gb версии) и у него 32 битная шина, поэтому не все так гладко.
Это означает что за такт шины передаётся 2 бита. Таким образом передаётся 64 бита по 32-битной шине :)
это не делает ширину шины 64-битной
И где я это утверждаю? Я сказал «по 32-битной шине».
Ведь у DDR есть две частоты реальная и «эффективная»
«Эффективная частота» это абстрактное понятие. Вы же понимаете, что интерфейс тактируется одной частотой?
При использовании DDR SDRAM достигается удвоенная скорость работы, нежели в SDRAM, за счёт считывания команд и данных не только по фронту, как в SDRAM, но и по спаду тактового сигнала. За счёт этого удваивается скорость передачи данных без увеличения частоты тактового сигнала шины памяти.
Или мы просто друг друга не поняли, я лишь имел ввиду что 64 битная работа с памятью, при 32 битном интерфейсе самой памяти не даст никаких преимуществ, а не что она не возможна.
Так вот на на своей эффективной частоте она имеет ширину шины 32 бита.
Нет никакой эффективной частоты. Это абстракция.
Шина физически 32-битная. И это не абстракция, а 32 проводника на плате.
И по каждому проводнику за 1 такт передаётся 2 бита. Ровно это я и написал в своём первом посте.
До сих пор не ясно?
64 битная работа с памятью, при 32 битном интерфейсе самой памяти не даст никаких преимуществ
Это не так. Вы не работает с памятью напрямую, а работаете с кэшем.
Команда ldr, к примеру, прочитает 8 байт за такт в 64-битном режиме.
Так что преимущество вполне очевидное.
Именно об этом говорится тут:
64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись.
Нет никакой эффективной частоты. Это абстракция.
Как минимум это общепринятая абстракция.
И по каждому проводнику за 1 такт передаётся 2 бита. Ровно это я и написал в своём первом посте.
До сих пор не ясно?
И как это превращает 32 бита в 64? Правильно никак.
Это не так. Вы не работает с памятью напрямую, а работаете с кэшем.
Команда ldr, к примеру, прочитает 8 байт за такт в 64-битном режиме.
Так что преимущество вполне очевидное.
Для этого как минимум надо чтобы данные были уже в кеше. Иначе она их прочитает за два такта эффективной частоты.
Именно об этом говорится тут: 64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись.
Ну так вот такое чтение можно сделать только за два такта эффективной частоты DDR, а не за один если бы разработчики поставили 2 чипа DDR(если конечно проц умеет работать с 64 битной шиной).
О том, что двухканальный доступ к памяти быстрее однократного? Так так оно было и в первых Pentium'ах — где о 64-битах никто и не заикался.
О том, что доступ в кеш происходит в 64-битном процессоре быстрее, чем в 32-битном? Это тоже очевидно.
И от интерфейса, которым проц соединён с памятью это не зависит никак.
О каком вообще измеримом эффекте вы спорите, я понять не могу?
Потому что спорить о том, сколько ангелов помещается на кончике иглы (при топ, что ничего измеримого про этих ангелов узнать нельзя) — можно до бесконечности.
О том, что двухканальный доступ к памяти быстрее однократного?
Про двухканал вообще никто не говорил.
Я лишь написал о том что несмотря на 64 битность процессора, данные не могут считываться по 8 байт за один раз, из за 32 битности шины памяти.Но это как раз и есть те самые пресловутые «ангелы на кончике иглы»!
С вашим подходом получится, что вичестер вообще в принципе не может больше одного бита раз раз передавать. А видеокарта — может только 16 бит передавать, не более. Потому что в первом случае у вас один провод, во втором — не более 16.
Bred of very sif Cable.
На Raspberri pi используется, насколько мне известно, DDR3 память. За один цикл работы данной памяти из процессора в память (или обратно) передаётся, на минуточку, 256 бит данных. Да, они передаются по восемь бит по одному проводу — но это всё можно увидеть только и исключительно на осциллографе. «С толчки зрения софта» эта шина — передаёт 256 бит «за раз».
Потому и с спрашиваю про наблюдаемые эффекты. Какой смысл обсуждать то, что на программы ровным счётом никак не влияет?
Как минимум это общепринятая абстракция.
Само понятие «эффективной частоты в МГц» применительно к модулям памяти — дилетантство.
В спецификации JEDEC[2] есть замечание, что использовать термин «МГц» в DDR некорректно, правильно указывать скорость «миллионов передач в секунду через один вывод данных».
Иначе говоря «MT/s» или «Mbit/s на контакт»
И как это превращает 32 бита в 64? Правильно никак.
За 1 такт передаётся 2 бита. 32*2 = 64. Повторение — мать учения :)
Но для оценки преимущества 64-битного режима это не имеет никакого значения.
Как в 32-битном режиме, так и в 64-битном режиме работы CPU, подсистема памяти Raspberry-Pi обеспечит сравнимую ПСП, потому что скорость работы с кэшем гораздо выше чем ПСП.
Для этого как минимум надо чтобы данные были уже в кеше.
Кэш на то и придуман, чтобы в подавляющем большинстве случаев данные там были.
К тому же для этого их не всегда нужно читать из памяти. Можно записать данные в кэш-строку и сразу прочитать (в т.ч. из очереди записи процессора).
Ну так вот такое чтение можно сделать только за два такта эффективной частоты DDRУ частоты не бывает тактов. Такт это промежуток (период) между двумя импульсами тактового генератора, который в данном случае подаётся на интерфейс модуля памяти. Как бы вы не напрягались с абстракциями, но этот период составляет строго определённую величину. Его нельзя поделить на два. Что увеличивается, так это data rate, что и указано в названии технологии DDR.
За 1 такт передаётся 2 бита. 32*2 = 64. Повторение — мать учения :)
А нету нету никаких тактов, есть операции чтения и записи. И вот за одну операцию чтения мы получаем 32 бита.
За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.
И в 32-битном режиме и в 64-битном режиме работы CPU, подсистема памяти Raspberry-Pi обеспечит сравнимую ПСП, потому что скорость работы с кэшем гораздо выше чем ПСП.
И потому что доступ к памяти 32битный.
У частоты не бывает тактов. Такт это промежуток (период) между двумя импульсами тактового генератора, который в данном случае подаётся на интерфейс модуля памяти. Как бы вы не напрягались с абстракциями, но этот период составляет строго определённую величину. Его нельзя поделить на два. Что увеличивается, так это data rate, что и указано в названии технологии DDR.
Зато его можно умножить на два производя операции как фронту сигнала и так и по спаду(в отличии от SDR). И вот умножив мы тут и получим ту самую эффективную частоту.
А нету нету никаких тактов, есть операции чтения и записи.Ура.
И вот за одну операцию чтения мы получаем 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-битность нельза прочувствовать никак.
А нету нету никаких тактов, есть операции чтения и записи.
Теперь вы отрицаете наличие тактового сигнала? o_O
И вот за одну операцию чтения мы получаем 32 бита. За такт тактовой частоты операции происходит две, но это как не делало 64 бита так и не делает.Так, так, и что мы получаем? 2*2 = 2?
Вы написали что за одну операцию происходит чтение 32бита, и что за такт выполняется 2 операции, так сколько же бит память передаёт за такт? ;)
32 * 2 = ???
И вот умножив мы тут и получим ту самую эффективную частоту.
WAT? Во-первых, период это величина обратная к частоте.
Во-вторых, вы проигнорировали моё замечание относительно некорректности термина.
Знаете что это напоминает? Людей, которые упорно называют системный блок «процессором», ведь это «общепринятая абстракция» в их круге общения.
Впрочем, говорите как хотите.
Теперь вы отрицаете наличие тактового сигнала? 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
Могу пройти 100 метров за 50 секунду шагами по 1 метру делая два шага в секунд.Я правильно понимаю, что обсуждение маразма, с которого всё началось (якобы невозможности считывания по 8 байт за одно чтение/запись из-за 32 битной шины) окончено?
И могу пройти 100 метров за 50 секунд делая 1 шаг в секунду, но шагая по два метра.
Скорость в двух последних случаях одна и таже. Но вот длинна шага(ширнина шины) от этого одинаковой не станет.
И даже если сделать вид что все кто используют термин неправы то Double Data Rate это всё таки не Double Data WidthЭто уже начались подсчёты «ангелов на кончике иглы». Как оно там называется — в принципе интересная дискуссия, но к исходному вопросу отношения не имеющая. За одно чтение/запись вы получаете гораздо больше 32 бит, а как это всё называть — это уже другой вопрос.
Всё вы меня затролили, я сливаюсь.
По моему этот вопрос скорее про 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]"
Проблема указателей преувеличена, как мне кажется.
А в этой распи всё еще езернет подключён через USB?
<sarcasm>нет, там теперь usb через ethernet подключен</sarcasm>
Таки воткнули PCIe, по которому уже проброшен и 1GbE, и USB3.0.
Но вообще показательно, у большинства промышленных SoC это (RGMII+USB3.0) помещается прямо в камне, правда, говорят, что с маленькими нанометрами 5-вольтовая природа USB уже дает сбой и из-за этого придумали eUSB
А так, 4-гиговая RPi4 очень приятная железка, даже на распбиане, ждем полной поддержки железа на ARM64
А потом выясняется что всяких библиотек, например для работы с камерой Pi, под 64 бита либо нет, либо они не работают даже если соберутся. Плавали, знаем.
Так что нужно аккуратно к этому вопросу подходить. А я подожду пока оно не стабилизируется.
Я часто читаю заявления типа «оно того не стоит», «ты выиграешь несколько миллисекунд», и т.д.
В зависимости от роли и загрузки железки оно действительно может того не стоить.
К примеру, у меня RPi 4 нагружена только netdata с мониторингом пачки сервисов, load average там в среднем меньше 0.1, загрузка процессоров (всех) в худшем случае не более 5%, по сетке едва-ли больше мегабита ходит — выигрыша от перехода на 64bit вообще никакого.
Если это будет супернагруженный web/nas/vpn-server, причём с гигабитным траффиком — другое дело, но тут уже возникнет вопрос, стоит ли для такой роли использовать RPi?
Что касается серьезных задач, то и Intel NUC её не заменит, т.к. точек отказа ровно столько же, а производительности на Ватт, наверное тоже.
Уже месяца два как перевел свой домашний роутер RPI3b+ на Fedora 31 64bit
(начинал с: Raspberry Pi + CentOS = Wi-Fi Hotspot (или малиновый роутер в красной шляпе))
Думаю поделиться в ближайшее время с общественностью, но если вкратце, то:
быстрее/холоднее/удобнее/ и приятнее...
Та можно ставить и ubuntu и kali и другие
А если мало места в флешке (2 GB и больше) ставьте Risc OS
А если еще меньше то установливайте Risc OS Pico (BASIC) (16 MB и больше)
Нет, конечно можно скачать server версию а потом
sudo aptinstall lubuntu-desktop64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись
Непонятно что имеется ввиду. Физически и логически битность ОС к тому сколько максимум можно за раз записать отношения не имеет. Физически там LPDDR4 память, сколько бит из нее раз может забрать процессор никак не меняется от битности ОС.
Логически для 32битного arm есть инструкции STRD/LDRD, с помощью них можно запустить запись чтение сразу 8 байт.
А вот дальнейшая обработка — уже только по 32 бита «за раз». Даже сложить пару 64-битных чисел в ARM32 одной иструкцией не получится.
Но не знаю как это отличие правильно описать короткой фразой.
… что означает 64-битную память.
Оригинал: «which means 64 bit ARM.»
Даже банальная попытка накатить на ubuntu-server lubuntu-core приводит к чёрному экрану. После починки обнаруживается целая россыпь проблем и крешей.
Mate под pi4 нет, а от b3+ не подходит.
CentOS не стартует из коробки.
После Курения форумов добился появления признаков жизни, но возиться далее желание отпало.
Fedora так же отсутствует под pi4.
Выводы не утешительные. Максимум что можно заюзать это ubuntu-server без GUI. И то теперь есть сомнения в стабильности.
Я ранее писал, что можно использовать Manjaro. Сам уже некоторое время на ней сижу (установил редакцию с KDE). И к слову о MATE: сейчас в репозиториях ArchLinux как раз самая последняя версия 1.24, и нет никакой проблемы её установить. Глюки KDE меня как раз заставили уйти в MATE на этой машинке.
Из недостатков — плохо с видеодрайвером, 500 рыбок в webgl — 8 fps (софт). Видео тоже крутится только 720p и с подтормаживаниями. Звук тоже проблемный — через hdmi никак не хочет идти.
через hdmi никак не хочет идти.
У меня Он идет только через один из двух. Но у меня телек SONY там это известная проблема с пишками.
Недавно снова поставил x64, уже стало получше. Gnome завёлся и вроде бы пока что всё ок.
С видео, да есть засада, x32 тянул ютуб в fullhd а вот на x64 я ловлю слайдшоу. :( Но есть уверенность что скоро поправят. Тем более я ещё не проверял как оно там на расбиане который x64. Думаю ближе к НГ его зарелизят. Возможно к тому времени как-раз и пофиксят всё.
Почему на Raspberry Pi4 стоит поставить 64-битную ОС