ARM для arm

Какой размер монитора и DPI в настройках?

это 25" dell (2560x1440 59.95*+)

96x96 dots per inch

Подробностей бы об ощущениях. Что тормозит, что ворочается нормально.

Там, вон, на АRМах вообще рабочую станцию выкатили: https://servernews.ru/999252

Общую картину портит microSD карта, это хоть и твердотельный накопитель, но всё же не SSD диск.

Получается, ты шрифты выкрутил, чтобы читабельно было?

так а ютубчик завелся то или нет?

местами да, увеличивал шрифт, в konsole точно. В хромиуме не трогал ничего.

конечно, с чего бы ему не завеститсь?

ну, может, видео в 1080 идет в виде слайд-шоу, или что-нибудь типа того

f2fs на хомяк, бэкапы для надёжности. Именно f2fs дал мне максимальный пинок отзывчивости.

А вы с первыми тремя малинами вообще не знакомы? На vc4 единственный адекватно работающий видеодекод идёт напрямую в видеопамяти, поверх всех буферов операционки, и вернуть видео оттуда в окно браузера… Короче так лучше не делать. Да оно собственно и не работает, даже там где написано что работает.

Завидую… у меня пока третья. Отожранные 360М памяти немного растраивают.

108 BogoMIPS это в простое под 600Мгц или это предел?

Как организовано питание? Специальный зарядник под юсб-С с повышенным напряжением? Или оно нормально работает от стандартных юсб-гнёзд с 5,0В? Весьма важный для меня вопрос, не придётся ли мне извращаться с питанием.

Питание нужно от 2А. В идеале 3А. Если ниже 2х, то снизится производительность.

Амперы ещё не всё. У меня на 3-й малине сгорел один телефонный зарядник на 2А, та ещё история была. После этого я поставил мдифицированный БП от ПК на 350Вт. Он не напрягаясь выдаёт 25А по линии 5В, но у меня в последние полгода постоянные просадки напряжения и иногда ещё и контакт падает.

И меня напрягает несоответствие. Стандартные usb-A порты предполагают 5,0В, но как всегда пишем 5,0, 4,9 в уме. А тут заявлено что нужен зарядник usb-С с 5,1 вольта. И что произойдёт, если я поставлю мощный БП, но с этой самой просадкой 0,2В?

А мне нужен мощный источник, чтобы кроме малины ещё переферию питать, хаб, 2 смартфона и 3-5 дисков, в т.ч. 3,5" с линией 12В.

А вы с первыми тремя малинами вообще не знакомы?

нет, я имелл опыт с tinkerboard, и она не сильно хуже четвертой малины в плане производительности, разве что там всего 2 гига вместо 4х памяти.

питание рекомендованное (3х амперный 5-ти вольтовый блок питания) https://www.raspberrypi.org/products/type-c-power-supply/ такой.

ну, может, видео в 1080 идет в виде слайд-шоу, или что-нибудь типа того

посмотрел первый попавшийся(https://www.youtube.com/watch?v=ylk6VMBLrvM) в 1080p только что, вполне смотрибельно…

В том то и дело! Это не 5В, а 5,1В блок питания.

И от чего питаете вы? И как оно будет вести себя от обычных 5,0В гнёзд бе зограничений по току?

Нормально будет себя вести, запитывал от повербанка mi power 3 pro. А так БП воткнут в обычную розетку.

armv7l на Cortex-A72?

Память экономишь ценою 10-15% производительности AArch64?

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

Я именно в такой же ситуации и замерял, только это был всё же Android, а не обычный Linux. На обычном пока не довелось. 64-битный процессор, ядро, но разница между именно сборкой приложения в 32-битном(с hardfloat) и 64-битном режимах была где-то 10 процентов в пользу aarch64, конечно.

Для этой задачи, думаю, лучше брать соснодоски. Там есть еммс.

лучше брать соснодоски

что простите, брать?

За калокуб тебе жирный минус!

https://servernews.ru/999252
$3k

я ждал тебя(таких), давай, расскажи про искусство управления битами в регистрах.

Зайди на любой форум по радиоэлектронике и умойся из ушата с дерьмом, которое на тебя выльют ☺

Этот подход полностью аналогичен быдлокодингу для десктопа (вместо легковесных библиотек брать С++ с культяпками) или веб-быдлокодингу (пыхпых какой-нибудь или нодеЖС).

Интересно было бы увидеть тесты. В своё время то же самое говорили про х86_64, но потом было достоверно показано, что прирост в среднем не превышает 2% и заметен только в длинных векторах.

У него распбиан. Тамошние наркоманы до сих пор не осилили AArch64. А собсна выбора почти и нет. Из 64-битных ОС для Малинки я пока только FreeBSD и Arch видел. Ещё конечно Pidora была, но судя по всему она давно сдохла.

А твоя ненависть к HAL обусловлена исключительно религиозными убеждениями или в этом есть какое-то рациональное зерно?

В среднем по больнице температура составляла 36.7 ага. Усреднили отсутствие прироста в каком-нибудь /bin/ls с двойным(допустим) приростом в каких-нибудь кодеках и прочем fpu коде.

Зайди на любой форум по радиоэлектронике

но это форум по ОС Linux

вместо легковесных библиотек брать С++ с культяпками

ах да, точно, лучше gtk и Си.

но потом было достоверно показано

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

Инженеры в AMD думали, совещались, как бы насрать пользователям и заставить их покупать оперативку. И придумали, размер указателя на четыре байта увеличили, чтобы адресовать больше 4 гб да новых регистров добавили. Чтобы пользователи страдали и ОЗУ покупали. Была ещё информация, что в создании AMD64 активно участвовали инопланетяне с Нибиру при поддержке и финансировании масонов.

Для начала почитай, сколько багов в кале.

Далее - почитай код самого кала. Ужаснись.

Ну и посмотри документацию кала. Еще больше ужаснись.

А теперь резонный вопрос: на кой черт вместо того, чтобы только RM с даташитом на МК читать, читать еще и документацию на кал? Причем, использование кала сильно будет затормаживать выполнение работы и раздувать объем флеш...

Ах, да: если тебе говорят, что кал - это переносимость кода между платформами, то плюнь в морду тому гибонну, кто так говорит! При переходе, скажем, с STM32F0 на STM32F3 тебе по-любому этот калокод придется прелопачивать!

Чтобы пользователи страдали и ОЗУ покупали

так постоянно же ноют от нехватки. А те, кто адресуют больше 4х гиг, остальным рассказывают как решить проблемы(купи 16 гиг, нищеброд (у меня 32 гига не тормозит,(ввозьмите сервер с 1Тб ОЗУ и все ваши приложения будут летать))) и всё в таком же духе.

Для начала почитай, сколько багов в кале.

Далее - почитай код самого кала. Ужаснись.

Ну и посмотри документацию кала. Еще больше ужаснись

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

что за доски?

Pine64

А как еще кусок дерьма, кроме как калом, называть?

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

Да при чем здесь объем оперативки? Самый главный факт - это работа «за один присест» с данными в 64 бита! А представь, была бы архитектура 4096-битная, какой был бы кайф! Тогда можно было бы не задумывась ворочать достаточно большими целыми. А сейчас это очень долго и нудно, т.к., скажем, число «гугол + один» не реализуемо ни на какой современной архитектуре. Придется выдумывать толпу костылей и подпорок, чтобы можно было к этому числу прибавить еще один. И занимать это будет много времени...

Ну так арч FTW. Чем распбиан может отличаться?

// никогда не было RPi.

Ну вот если касательно Android, то я тестировал производительность Xash3D FWGS на нём. Собственно который я и пишу. Результат я опубликовал тут

90 FPS против сотни, просто от рекомпиляции. Бесплатная производительность!

В случае х86/амд64 разница в пределах погрешности везде кроме специально разработанной под эту разницу синтетики, в т.ч. во всяких кодеках и fpu.

16-битный код и разделение памяти данных и памяти кода могло бы решить проблему…

Нет, 64 бита это всего лишь длинна адреса в памяти. А работа за один пресест ведётся над какой то другой штукой.

Нет, 64бит процессоры как раз работают с числами такой разрядности нативно. Можно в 64бита упихать 8 8битных числа, и потенциально обработать за один такт.

Программы начинали упираться и в 32бит. Адресного пространства требуется больше, чем используется реальной памяти. Костыли вроде highmem замедляют работу.