Gentoo и ее '+1%' производительности

Скрипт тестирования в студию.

примерно на 1-2% медленнее

методику измерения в студию

В случае в ffmpeg фреймрейт был не много ниже а потраченное время больше,

что конкретно делалось ффмпегом, что было взято за эталон (какая система с бинарными пакетами)?

как у 99% пользователей gentoo

Так не бывает.

Присоединюсь к вопросу предыдущих ораторов — методику тестирования в студию.

Тащемта бинарники бывают и с O3 собраны.

Какой дурак ставит генту ради мифического прироста производительности?

Ее ставят из-за того, что это один из немногих выживших дистрибутивов, не поддавшихся скатыванию в сраную мастдайку.

Может кто та сталкивался или знает почему так происходит?

Потому что гладиолус!

Присоединяюсь ко всем вышеотписавшимся ораторам и добавлю - Почему не было замеров с icc?

что конкретно делалось ффмпегом

Брал большое видео и проганял его через ffmpeg.

time ffmpeg -i ./bbb_sunflower_2160p_30fps_normal.mp4 -f null - -benchmark

какая система с бинарными пакетами

Я не разобрался где брать бинарники (нужных мне не было в оверлеях), по этому я поставил Arch Linux, настроил там такие же параметры компиляции и протестировал. Имхо из abs мне понятнее.

Тащемта бинарники бывают и с O3 собраны.

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

Какой дурак ставит генту ради мифического прироста производительности?

Тут дело не в приросте, дело в том, что на выходе получаем ухудшение производительности.

Так не бывает

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

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

Может кто та сталкивался или знает почему так происходит?

частенько сталкиваюсь с такими дуриками, как ты. отчего это происходит? скорее от того, что очередной мамкин какир решил, что Кали - это уже некруто, и надо срочно ставить Дженту.

1% - похоже на погрешность измерения - сколько раз ffmpeg запускался?.. я бы разок 10 запустил на одном и том же файле хотя бы... скомпилированную версию и бинарную.

только не знаю, где «бинарную» взять, если брать другой дистрибутив - слишком много данных будет отличаться - не стоит забывать о куче библиотек, от которых зависит ffmpeg, о версиях gcc/binutils/glibc и т.п...

Знатно у тебя полыхнуло.

да, васче, дом аж сгорел

1% - похоже на погрешность измерения

Я согласен, но когда в 10/10 тестов собранный работает чуть медленнее, то сомнений у меня никаких уже не возникало.

Кстати, а размер /usr/bin/ffmpeg какой на arch, а какой на gentoo? Чисто из любопытства (не знаю, на что не может влиять).

У меня ffmpeg-3.3.5

du -sb /usr/bin/ffmpeg 
238816  /usr/bin/ffmpeg

Собирался скорее всего gcc-5, на 6 не успел обновиться.

Што там? Незаметны? 😂😂😂

Для нормальных тестов должна совпадать версия ffmpeg на обеих системах и конфигурация сборки

Кстати, а размер /usr/bin/ffmpeg какой на arch, а какой на gentoo?

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

Еще попробую дополнительно пособирать с -mtune=generic, где то читал что это вроде бы как позволяет получить самый быстрый бинарник.

похоже, у тебя так полыхало от радости, что грамматике и правописанию ты в порыве радости внимание не уделял.

Для нормальных тестов должна совпадать версия ffmpeg на обеих системах и конфигурация сборки

Одинаковые конечно, иначе бред.

тогда покажи выхлоп ffmpeg-а с обеих систем

ноут на котором я проводил первые тесты уехал пару дней назад. Остался ноут со скайлейком на арче.

Очень противоречивая информация насчёт mtune=generic - либо это наиболее быстрый процесс компиляции, либо наиболее универсальный бинарник (который быстрее запустится).

Если -O3 уже пробовали, я бы ещё заодно попробовал -O1 и -Os. Сюрпризом будет, если вдруг -O1 окажется быстрее -O2.

К слову, про -Os, когда я собирал пакеты с таким флагом и жаловался на багзиллу, что не все собираются, мне говорили, мол, не надо с ним собирать, лучше -O2, 0s не рекомендуется... А мне как раз надо было место на диске экономить. Но так и не дошли руки подсчитать, есть ли там реальная экономия.

Да-да, ffmpeg -vvv или как его там был бы полезен. А может там ещё профилирование где-нибудь можно включить. ;)

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

больше, и медленнее

Фиксация на бытовой логике. Плоскоземельщик или что то из аналогов?

Ты не обижайся, но ты ничего никак не протестировал.

Разберись подробнее, детальнее, почитай про возможность емержа разными компиляторами для разных пакетов, например через icc, который даёт прирост 30-60% на архиваторах и кодеках.

Стандартный make.conf

А для той версии, которая быстрее где флаги?

Ты не обижайся, но ты ничего никак не протестировал.

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

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

icc

Речь шла о нативных вещах, а именно GCC. Если какую то часть бинарников действительно собирают чем то еще кроме GCC, тогда вопрос снят.

Gentoo vs Arch

ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.2.0 (Gentoo 7.2.0 p1.1)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/share/doc/ffmpeg-3.4/html --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=native -O2 -pipe -s' --disable-static --enable-avfilter --enable-avresample --disable-stripping --disable-indev=v4l2 --disable-outdev=v4l2 --disable-indev=oss --disable-indev=jack --disable-outdev=oss --disable-outdev=sdl --disable-bzlib --disable-runtime-cpudetect --disable-debug --disable-gcrypt --disable-gnutls --disable-gmp --enable-gpl --enable-hardcoded-tables --enable-iconv --disable-lzma --disable-network --disable-openssl --enable-postproc --disable-libsmbclient --disable-ffplay --disable-sdl2 --disable-vaapi --disable-vdpau --disable-xlib --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-zlib --disable-libcdio --disable-libiec61883 --disable-libdc1394 --disable-libcaca --disable-openal --disable-opengl --disable-libv4l2 --disable-libpulse --disable-libopencore-amrwb --disable-libopencore-amrnb --disable-libfdk-aac --disable-libopenjpeg --disable-libbluray --disable-libcelt --disable-libgme --disable-libgsm --disable-mmal --disable-libmodplug --disable-libopus --disable-libilbc --disable-librtmp --disable-libssh --disable-libspeex --disable-librsvg --disable-libvorbis --disable-libvpx --disable-libzvbi --disable-libbs2b --disable-chromaprint --disable-libflite --disable-frei0r --disable-libfribidi --enable-fontconfig --disable-ladspa --disable-libass --disable-libfreetype --disable-librubberband --disable-libzmq --disable-libzimg --disable-libsoxr --enable-pthreads --disable-libvo-amrwbenc --disable-libmp3lame --disable-libkvazaar --disable-nvenc --disable-libopenh264 --disable-libsnappy --disable-libtheora --disable-libtwolame --disable-libwavpack --disable-libwebp --disable-libx264 --disable-libx265 --disable-libxvid --disable-armv5te --disable-armv6 --disable-armv6t2 --disable-neon --disable-vfp --disable-vfpv3 --disable-armv8 --disable-mipsdsp --disable-mipsdspr2 --disable-mipsfpu --disable-altivec --disable-amd3dnow --disable-amd3dnowext --disable-avx2 --disable-fma3 --disable-fma4 --disable-xop --cpu=host --disable-doc --disable-htmlpages --enable-manpages
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100

...

bench: utime=234.690s
bench: maxrss=85360kB
234.70s user 2.24s system 314% cpu 1:15.42 total

bench: utime=233.196s
bench: maxrss=85076kB
233.21s user 2.94s system 317% cpu 1:14.29 total


vs

ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-shared --enable-version3
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100

  ...

bench: utime=236.455s
bench: maxrss=103492kB
236.48s user 2.22s system 308% cpu 1:17.46 tota

bench: utime=235.375s
bench: maxrss=106588kB
235.39s user 2.15s system 322% cpu 1:13.69 total

Всё на уровне стат. погрешности.

Я правильно понял, что вы тестировали дженту и арч с одним и тем же ядром (или по крайней мере одинаковой версии, собранным с одинаковым конфигом)?

А ещё в ffmpeg всё оптимизировано вручную на ассемблере, компилеру дальше нечего делать.

действительно собирают

Действительно собирают. Гента предоставляет возможность собирать как хочешь, в том числе настраивая компиляторы для различных пакетов, ты сам решаешь.

Отсюда и профит.

А ты по-сути собрал еще один арч и сравниваешь его с бинарным.

Отсюда и профит.

ты можешь показать свои результаты профита? Или дать ссылки на профит.

И ты поверишь наслово?

Возьми ICC, собери на выбор или все вместе: tar, gzip, p7zip, bzip2, cpio, lzo (lzma я не пробовал).

Затести время сжатия/разжатия какого-то файла и сравни эти результаты с бинарниками собранными другими компиляторами (gcc, clang).

Я гарантирую тебе от 10% прироста, а верхнюю планку предоставишь ты после тестов.

Размер архивов при этом не изменится, только время обработки в обе стороны.

И ты поверишь наслово?

Ну да. Выложи свои пруфы, мне очень инетерсно. Хотя бы для gzip.

Я не могу выложить пруфы в данный момент:

Linux workstation 4.14.3-gentoo x86_64 AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G AuthenticAMD GNU/Linux

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

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

Тебе нужно, ты и проверяй

:D

Бремя доказательства лежит на том, кто усомнился ;)

Берёшь любой бинарный дистрибутив, ставишь gtkperf (это бенчмарк отрисовки компонентов gtk2 ), замеряешь, записываешь.
Пересобираешь с -march=native -mtune=native пакеты cairo, glib, gtk, gtk-engines-* libfreetype. У меня на debian получалось на i5 больше чем 2х кратный прирост, 6.5 секунд стандартного теста на изкоробочных бинарниках против 2.8 с пересобранными. Естественно разница отзывчивости интерфейса в гномах и xfce видна просто на глаз ;)

* dev-lang/icc
     Доступные версии:      ~13.1.5.192^m ~14.0.3.174^m ~15.0.6.233^m {examples multilib LINGUAS="ja"}
     Домашняя страница:     http://software.intel.com/en-us/articles/intel-composer-xe/
     Описание:              Intel C/C++ Compiler

Вот вроде.

[ebuild  N     ] dev-libs/intel-common-15.0.6.233::gentoo  USE="compiler multilib -examples" 4,091,841 KiB

похоже он, только когда я им в последний раз пользовался, он весил в 2-2.5 раза меньше :)

Но у меня сейчас AMD.

больше чем 2х кратный прирост

Это ты GCC ил на ICC собирал?

gcc

как обычно, версия в Дженте отстаёт на 3. да и по большому счёту, он нафиг не нужен, т.к. никто не гарантирует сборку пакетов, а тем более их работу в дальнейшем.

А разве icc не умеет собирать под -march=native ну или там x86_64?..

Так оптимизации только для интел-цпу же, можно запускать и на amd, только толку от этого очевидно мало, но я лично не проверял.

Ну если что, то в SSE уже сколько лет как AMD тоже умеет. А вот более экзотические новые инструкции может и нет. Я бы не сказал, что «очевидно мало», я бы проверил, но под рукой нет AMD. :-)

а icc совместим с gcc?

а icc совместим с gcc?

Забавно. А я считал что компиляторы пишут по стандартам ЯП соответственно и совместимость должно сравнивать со стандартом а оно вон оказывается чо...

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

https://habrahabr.ru/post/83324/

Сразу предупрежу, что некоторые приложения не собираются icc, а некоторые собираются, но не работают, хотя разработчики icc стремятся сделать его максимально совместимым с gcc

Мне плевать что пишут на хабре. Однако под вопросом

а icc совместим с gcc?

на самом деле ты имел в виду - совместим ли icc со всеми gcc-специфичными костылями в софте? И ответ на этот вопрос как ты наверное и сам понимаешь конечно же нет. Не совместим. Впрочем так-же как и llvm&clang они тут ничем не отличаются потому что проблема не в них а в gcc-специфичных костылях конкретных приложений. Однако то что собирается и работает показывало и 5% и 25% и 30% ускорение от icc по сравнению с gcc.

А де добыть ICC нахаляву?