Gentoo vs Debian performance(давайте протестируем)

march=native + mtune=native

Бессмысленно. -march=foo всегда неявно подразумевает -mtune=foo если не сказано иного.

А вдруг ты генту соберешь так, чтобы подыграть той или иной стороне?

Нужно ставить официальную сборку генты!

Патч бармина.

Есть железо Intel(R) Core(TM)2 CPU 6320@1.86GHz + 4gb ram. Железо слабое, но всё-равно даст пониманием того, быстрее ли gentoo debian’a или нет

Сто раз разжевывали тему производительности, даже на этом форуме. От оптимизаций реально выигрывает только сложный софт и на современном железе. На древнем железе оптимизировать не подо что и запускать нечего.

Получается сравнить несравнимое
Дебиан - стандартный дистрибутив с минимальными настройками
А генту - кастомизированный дистрибутив
Это разные весовые категории
Дебиан надо сравнивать с убунтой, федорой, сузей, альтом
А генту с арчем или лфс-ом каким-нибудь

Бенчмарк xmrig попробуй

Нужно ставить официальную сборку генты!

Ты плохо представляешь что такое Гента. Гента - это конструктор. Там нет такого понятия как официальная сборка. Именно поэтому Гента для новичков не подходит.

Там нет такого понятия как официальная сборка

stage'ы разве ими не являются? или Генту принято прям вообще вообще с нуля собирать?

Или вот https://www.opennet.ru/opennews/art.shtml?num=56963

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

Лучший прирост дает замена железа и особенно hdd -> ssd.

От оптимизаций реально выигрывает только сложный софт и на современном железе

Таки нет. Во-первых есть ifdef, что вместе с флагами позволяет пропускать целые куски кода. Плюс есть пакеты с чрезмерно «общей» оптимизацией. Ну и есть ещё редкие наборы инструкций, которые скажем были на феномах но потом отмерли, так что в стандартной сборке их нету.

Сравнивать производительность дистрибутивов - это как сравнивать скорость автомобилей в двух городах: зависит от ширины дорог (железа), качества дорог (драйверов, типов ФС, версии ядра), эффективности регулирования (настройка/оптимизация ядра, файловых систем и т. п.), количества машин (список зависимостей у пакетов), типов машин (версии программ, как скомпилированы) и т. п.

Содержание вот здесь - это неплохой перечень того, что может влиять на производительность конкретной программы без учёта скорости работы самой программы (машины в метафоре выше) - то есть город в метафоре выше: https://wiki.archlinux.org/title/improving_performance . (И то это не всё: ещё влияет включён ли debug, еще есть несколько реализаций шифрования и др.)

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

Возмёшься?

Производительность Gentoo зависит от радиуса кривизны рук того, кто устанавливал Gentoo, и от времени и желания. Предлагаю измерять это

Intel(R) Core(TM)2 CPU 6320

Не имеет смысла. Потратишь времени на сборку (если нет нормального билд-сервера) в разы больше, чем выиграешь за счет оптимизаций.

а «скорость» gentoo будет измеряться в время компиляции (обновления хромиума) или нет? если тебя кто-то долбит выражениями «быстрее» то эти человеки явно не знают для чего гента.

Есть настроенные debian и gentoo.

Версии ядра, библиотек и софта у тебя совпадают в этих системах?

Они никогда не будут совпадать. Есть stable gentoo и есть stable debian. Его и будем сравнивать

bz2, gzip, ffmpeg, youtube-dl, openssl, gcc

детализируй по каждой команде

Товарищи, давайте сконцентрируем внимание на «чем тестировать», а не «почему не надо тестировать»

Его и будем сравнивать.

И что в этом случае получиться измерить? Проще тогда уж дебиан с march=native пересобрать, если интересует влияние подобной оптимизации на производительность.

будем измерять дебиан как есть и генту как есть, дебиан как есть и генту пересобранную под определенный cpu

NYPA, я и так выкатил тебе бесценный список ПО который большую часть пользовательских задач покрывает.

генту как есть

Гента у всех разная и каждый день меняется. Преимущества от оптимизации под процессор или опций компиляции гораздо проще проверить сравнивая оптимизированный и пересобранный дебиан.

Использовать так бинарный дистрибутив не практично, но, в отличие от сравнения с генту, такое тестирование даст полезную информацию о потенциальных преимуществах оптимизации. Ради которых затем уже удобно использовать генту.

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

Лучший прирост дает замена железа и особенно hdd -> ssd.

а ssd->nvme доносит до небес :)

Последний пункт принят единогласно.

будем измерять дебиан как есть и генту как есть,

Мне одному показалось, что в этом названии теста: «как есть», есть подвох?

тестируй сборку генту

ооо, как похоливорить - так все гаразды. Вот я предлагаю реально постестить, - сразу 100500 отговорок пук сраньк - пук сраньк

Та что здесь тестировать ?

Я вот вижу небольшое повышение производительности даже при перекомпиляции ведра, или при экспериментах с шедулерами. Но это повышение - субъективное, оно вряд ли измеряется в попугаях, хотя наверное его можно замерить миллисекундометром, открывая менюхи, переключаясь между окнами, запуская софт. Даже mitigations=off дает небольшой прирост, особенно заметный среди большого количества вкладок в браузере, с видосиками, джаваскриптами и прочим тормозным фуфлом.

Если ты эту производительность имеешь в виду - так ее и тестировать не нужно, она видна на глазок.

Если ты имеешь в виду производительность «где быстрее zip сожмет миллион файлов по мегабайту - на генте или дебиане» - то здесь скорее вопрос к программе «zip», а параметры системы хоть немного влияющие на производительность, ты можешь оттюнить на лету как на генте, так и на дебиане.

Ну а попугаи - это дело такое, разницу в работе софта с 1800 попугями, и 1900 попугаями - ты можешь даже не заметить.

Хочешь команду ? Лови:

dd if=/dev/zero of=/dev/null bs=1K count=10000000

https://www.smarty.com/blog/2015/10/performance-testing-with-phoronix/

ждём.

Неплохой вариант, но лучше бы конечно не синтетику гонять. А реальные какие-то задачи выполнить

dd if=/dev/zero of=/dev/null bs=1K count=10000000

Протестировал сразу на нескольких дистрибутивах, только-только поставленных в виртуалбоксе, минимальные установочные образы , виртуалбокс 6.1, справа от дистрибутива стоит версия ядра

Debian 11.3 - 5.10
10240000000 bytes (10 GB, 9.5 GiB) copied, 7.70051 s, 1.3 GB/s
Ubuntu 20 - 5.4
10240000000 bytes (10 GB, 9.5 GiB) copied, 8.08696 s, 1.3 GB/s
Эта же Убунта, но с проапдэйчиным ядром - 5.15
10240000000 bytes (10 GB, 9.5 GiB) copied, 8.08202 s, 1.3 GB/s
Fedora 35 - 5.16
0240000000 байт (10 GB, 9,5 GiB) скопирован, 8,02403 s, 1,3 GB/s
OpenSuse 15.3 - 5.3
10240000000 bytes (10 GB, 9.5 GiB) copied, 7.89832 s, 1.3 GB/s
Alt server 10 - 5.10
10240000000 байт (10 GB, 9,5 GiB) скопирован, 7,81357 s, 1,3 GB/s
Rosa Fresh Desktop 2021.1 - 5.10
10240000000 байт (10 GB, 9,5 GiB) скопирован, 8,3903 s, 1,2 GB/s

Нет. Под виртуалкой такое нельзя проверять, потому что хостовая ОС вносит шум в измерения. Вот у тебя Роса дала 1.2 Гб\с, а ты уверен что в этот момент твой Лялих не ставил обновления, не игрался в свопе, не копировал что-то куда-то, не кешировал файлы и тд ?

[ntfs@ntfs-a320mh ~]$ sudo su
[sudo] password for ntfs: 
[root@ntfs-a320mh ntfs]# dd if=/dev/zero of=/dev/null bs=1K count=10000000
10000000+0 records in
10000000+0 records out
10240000000 bytes (10 GB, 9,5 GiB) copied, 5,58343 s, 1,8 GB/s
[root@ntfs-a320mh ntfs]# dd if=/dev/zero of=/dev/null bs=1K count=10000000
10000000+0 records in
10000000+0 records out
10240000000 bytes (10 GB, 9,5 GiB) copied, 5,55527 s, 1,8 GB/s
[root@ntfs-a320mh ntfs]# dd if=/dev/zero of=/dev/null bs=1K count=10000000
10000000+0 records in
10000000+0 records out
10240000000 bytes (10 GB, 9,5 GiB) copied, 5,59963 s, 1,8 GB/s
[root@ntfs-a320mh ntfs]# dd if=/dev/zero of=/dev/null bs=1K count=10000000
10000000+0 records in
10000000+0 records out
10240000000 bytes (10 GB, 9,5 GiB) copied, 5,40599 s, 1,9 GB/s
[root@ntfs-a320mh ntfs]# 

Последний dd - с закрытым Firefox'ом.

[ntfs@ntfs-a320mh ~]$ sudo su

Некоторые ничему не учатся. Вот решил поставить дебиан ... (комментарий)

Не совсем понял о чем ты ...

Ясно. Это никому не интересно. Closed.

Нет. Под виртуалкой такое нельзя проверять

Да, действительно, на хостовой машине (убунту 20) показал совершенно другой результат:
10240000000 байт (10 GB, 9,5 GiB) скопирован, 2,33067 s, 4,4 GB/s

Я вчера не додумался сравнить

А генту с арчем

Причём арч окажется быстрее. =)

Там нет такого понятия как официальная сборка

stage’ы разве ими не являются?

Нет, это промежуточный этап установки. Оно потому и называется stage 3 . Каждый пользователь потом всё равно меняет профиль, USE флаги, опции компиляции, и перекомпилирует весь мир. Что кардинально меняет характеристики дистрибутива, в частности перформанс (о чём речь в этой ветке).

Или вот https://www.opennet.ru/opennews/art.shtml?num=56963

Это LiveDVD. Да, это официальная сборка, но это лишь вариация установки. На десктопе точно будет другое - потому что см. выше. И если ты хочешь оценить дистрибутив, в случае Gentoo, LiveDVD точно не показатель.

Причём арч окажется быстрее. =)

Не вводи людей в заблуждение.

По ссылке сравнение пакетных менеджеров, а не дистрибутивов. (И даже не сравнение, а так, эмоции)

Медленный пакетный менеджер - известная проблема Gentoo. Это один из немногих недостатков - см. раздел «Недостатки» здесь: Для тех, кто думает перейти на Gentoo

Ваще-т пакетный менеджер – тоже софт. И далеко не самый редкоиспользуемый. ;) Даже не будь он ультра-тормозным сам по себе, достаточно того, что затраты на компиляцию сожрут ЛЮБОЙ возможный выигрыш от оптимизаций скомпилированного софта.

И даже не сравнение, а так, эмоции

И ваще, я бы попросил!

достаточно того, что затраты на компиляцию сожрут ЛЮБОЙ возможный выигрыш от оптимизаций скомпилированного софта.

Затраты на компиляцию не оказывают практически никакого влияния, так как:

1. За исключением фазы первоначальной установки, новые пакеты устанавливаются очень редко
2. Апдейт происходит на фоне и не влияет на основную работу.
3. 95% установка с компиляцией занимает несколько минут на более-менее современном железе.

Выигрыш от компиляции зависит от того, какие задачи стоят. Например, если цель сделать минималистичную систему, чтобы она нормально работала на каком-то IoT или в контейнере, то выигрыш от компиляции может быть критично важным.

И ваще, я бы попросил!

О, теперь ссылка на конкретику.

real    0m5.366s
user    0m5.228s
sys     0m0.124s

Можно вопрос: а 5 секунд - это правда настолько много чтобы поднимать волну негодования?

Слушай, пакетный менеджер Gentoo правда тормозной. И я могу привести примеры задач, где он (пакетный менеджер Gentoo) работает действительно долго. Но пост по ссылке всё-же эмоционален.

Но пост по ссылке всё-же эмоционален.

Вот когда я умру и меня оцифруют…

у меня гента «на глаз» на не самом топовом железе из коробки была быстрее мандрейка (i686) на столько же примерно как тот был быстрее шапки (тогда i386 или 486), т.е. заметно. Запуск либре офиса например секунд 20 против минуты, также тормозилла и вообще все приложухи нахолодную стартовали быстрее. Кроме того, генту можно было поставить на райзерфс, который сам по себе быстрее в несколько раз, а когда я собирал специальные ядра под десктоп с планировщиками задач и ввода/вывода все было совсем моментально и отзывчиво. Там раньше многих была опция параллельного старта сервисов и можно было также в несколько раз быстрее загружаться еще до того как ссд эту проблему нивелировал.