LINUX.ORG.RU

firefox-esr с mozilla.org и из debian - разный fps

 , ,


0

2

Собственно сравнил 102.15.1 esr - одно из пакета из официальной дебиан репы, второе скачанное с сайта мозиллы. В первом регулярно обнаруживается слайдшоу, во втором таких проблем нет.

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

Собственно фпс сравнивал в игре https://orteil.dashnet.org/cookieclicker/ - в мозилловском пакете там всё плавно и хорошо, в дебановском дёрганая картинка уже на стадии загрузки (когда крутятся шарики посередине экрана, эту стадию можно искуcственно удлинить если залагать себе инет - зафайрволить что-нить нужное ему в DROP).

А вы что-нить такое замечали? С чем это связано?

Оба фф запускал в новом чистом профиле (одном и том же).

Из заметной разницы (кроме фпс) - в мозилловском пакете нет звука т.к. он только пульсу ищет которой нет.

------------------

Профайлер deb: https://ibb.co/jHqYXxB

Профайлер moz: https://ibb.co/5c4mt5X

Видно что рендер запускается где-то раз в 300мс и грузит проц больше чем рендер в mozilla-пакете. А само 300мс берется из того что сама вкладка этим 300мс перед эти тоже грузит проц, а в moz-пакете гораздо меньше.

Зелёное в Render это в основном RenderThread::UpdateAndRender (во вкладке Marker Table эти пики называются «Composite #1»)

Синее в работе вкладки это «CanvasRenderingContext2D.drawImage»

По этому названию нашёл обсуждение но не знаю насколько оно связано - там про дебиан ничего не говорят.

upd: кажется не связано, ввёл в консоли CanvasRenderingContext2D.prototype.clip = function() { }; и ничего не поменялось в плане скорости

Ввёл CanvasRenderingContext2D.prototype.drawImage = function() {};, после этого затраты на эту функцию в проце вкладки исчезли (как и соответствующие картинки на странице), а вот процесс render всё так же продолжает лагать и тратит по 100мс на одну итерацию (даже увеличилось - до этого тратила около 95мс). В мозилловском пакете же 10-20мс.

------------------

Компактный пример для воспроизведения проблемы: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

Как оказалось, js ни при чём, в примере его вообще нет. Но проблема как-то побочно задевает js тоже (а конкретно функцию CanvasRenderingContext2D.prototype.drawImage - она начинает в этих условиях работать в разы медленнее). В приведённом же примере js нет и лаги видны только в RenderThread::UpdateAndRender (это внутренняя функция в исходниках фф как я понял).

--------------------

Сравнение about:buildconfig firefox-esr с mozilla.org и из debian - разный fps (комментарий)

--------------------

Обновление: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

★★★★★

Последнее исправление: firkax (всего исправлений: 19)

Ответ на: комментарий от anonymous

без sse2

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

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh
debian:
firefox-esr	cpuid	2
firefox-esr	nop	1587
firefox-esr	call	7797
firefox-esr	i486	81
firefox-esr	i686	938
firefox-esr	total	162359

mozilla:
firefox-bin	cpuid	9
firefox-bin	nop	571
firefox-bin	call	6549
firefox-bin	i486	20
firefox-bin	i686	1183
firefox-bin	3dnowext	21
firefox-bin	mmx	354
firefox-bin	sse	128
firefox-bin	sse2	1720
firefox-bin	total	147542

Это может давать разницу в скорости на порядок?

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Я х.з., но ведь зачем-то собирают гентушники пакеты с -march=native. :)

Помню, когда еще обретался на винде, рекламировался palemoon, тем, что собирается, чуть ли не единственный из всех, под sse2. Типа, быстродействие выше гор. )

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от krasnh

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

Ожидал некоторого консерватизма, но тут даже AVX2:

> ./analyze-x86 /usr/lib/firefox-esr/firefox-esr 
/usr/lib/firefox-esr/firefox-esr        cpuid   2
/usr/lib/firefox-esr/firefox-esr        nop     4343
/usr/lib/firefox-esr/firefox-esr        call    6546
/usr/lib/firefox-esr/firefox-esr        i486    57
/usr/lib/firefox-esr/firefox-esr        i686    831
/usr/lib/firefox-esr/firefox-esr        3dnowext        62
/usr/lib/firefox-esr/firefox-esr        mmx     908
/usr/lib/firefox-esr/firefox-esr        sse     1347
/usr/lib/firefox-esr/firefox-esr        sse2    1838
/usr/lib/firefox-esr/firefox-esr        avx     3
/usr/lib/firefox-esr/firefox-esr        avx2    5
/usr/lib/firefox-esr/firefox-esr        total   125089
anonymous
()
Ответ на: комментарий от bugfixer

32 бита не настолько мертвы как многие думают. И часто используются даже на актуальном железе.

И 16, и 8, кто же спорит. Но 32-битных процессоров с AVX не было, не поленился проверить даже экзотику в лице VIA и Zhaoxin.

anonymous
()
Ответ на: комментарий от bugfixer

Просто x86-64 не подразумевает 64 битный userspace. И никто не мешает дёргать AVX из 32 бит.

Технически, наверное, не мешает, но то, что ещё собирают под 32 бита, обычно ориентировано на старое железо. Вон, выше выяснили, что Firefox в Debian без SSE :)

anonymous
()
Ответ на: комментарий от anonymous

но то, что ещё собирают под 32 бита, обычно ориентировано на старое железо

Весьма распространённый misconception. Есть масса причин гонять 32 битный софт. Если большими объёмами в конкретно взятом процессе ворочать не приходится - 32 бита зачастую быстрее (сильно зависит от числа коротких аллокаций). И в масштабах датацентров выливается во вполне себе существенные $$, как по количеству необходимого RAM, так и по электричеству.

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от anonymous

Мешает меньшее количество регистров.

Имеет место быть register pressure, да. Но это мелочи по сравнению с возрастающими memory bandwidth requirements в 64 битах.

И такое нужно собирать самому.

-m32 никто не отменял.

bugfixer ★★★★
()
Ответ на: комментарий от anonymous

ну почему и нет?

современный браузер позволит открыть какой-нибудь современный сайт :)

например, госуслуги какие или сбер-онлайн коммуналку заплатить…

а для «не утюгов» есть хромиум в репе

anonymous
()
Ответ на: комментарий от bugfixer

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

аллокатор делается такой чтоб не зависел от размера указателей

Я возможно не достаточно точно выразился: как именно происходят аллокации - это дело десятое. Но если в принципе софт таков что имеют место быть «газилионы» мелких объектов - цена pointer fetch становится существенной, и это фундаментально.

bugfixer ★★★★
()
Ответ на: комментарий от firkax

Пересобрал с -march=amdfam10 -msse -msse2 -mfpmath=sse - ничего не изменилось, все лаги на месте.

/opt/ff115/usr/lib/firefox-esr/firefox-esr	cpuid	2
/opt/ff115/usr/lib/firefox-esr/firefox-esr	nop	1825
/opt/ff115/usr/lib/firefox-esr/firefox-esr	call	7973
/opt/ff115/usr/lib/firefox-esr/firefox-esr	i486	79
/opt/ff115/usr/lib/firefox-esr/firefox-esr	i686	711
/opt/ff115/usr/lib/firefox-esr/firefox-esr	3dnowext	68
/opt/ff115/usr/lib/firefox-esr/firefox-esr	mmx	1601
/opt/ff115/usr/lib/firefox-esr/firefox-esr	sse	135
/opt/ff115/usr/lib/firefox-esr/firefox-esr	sse2	1609
/opt/ff115/usr/lib/firefox-esr/firefox-esr	sse3	15
/opt/ff115/usr/lib/firefox-esr/firefox-esr	sse4a	39
/opt/ff115/usr/lib/firefox-esr/firefox-esr	total	174273
firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Осталось проверить, влияет ли на что-либо сборка с «clang»+«LTO»+«-O3». Или mozilla просто ‘понты кидает’. :)

https://www.phoronix.com/news/Firefox-Clang-LTO-All-Platforms

Имхо, тема полезная, не зря значит я перешел уже давно на пакеты с реп мозиллы. )

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

lto теоретически может такое сделать, если они злонамеренно раскидали очень нужные inline по разным исходникам. Но всё-таки вряд ли. Остальное - ну не в 10 раз же (а разница примерно такая по факту в работе примера). Мне кажется дело в чём-то другом, придётся изучать как официальный binary-тарболл скомпилить из официального src-тарболла.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Затем что я твой подход «жрите что дают» не разделяю. И подход «пусть они там кодят а я скачаю и буду просто пользоваться» - тоже. Он мало того, что в итоге приводит к персональным проблемам потом, так ещё и в глобальном плане губителен для опенсорса.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Ты собираешься починить все баги комбайна и потом пропихнуть патчи в дистрибутив?

Не считая того, что положение галочки «использовать аппаратное ускорение» в настройках значительно более важно чем метод сборки.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от anonymous

Я не знаю, что происходит. Попробовал у себя, но разницы в потреблении CPU не заметил. Ни одна из версий не тормозит. Но я проверял x86-64, а не x86. Потом уже прочитал, что у ТС 32-битная система. На 32-битных не проверял, слишком муторно устанавливать 32-битную ОС.

i-rinat ★★★★★
()

А вы что-нить такое замечали? С чем это связано?

Пять звезд.

У панды куча опций сборки и в разных дистрибутивах она собрана по-разному. Удивительное - рядом.

utanho ★★★★★
()
Ответ на: комментарий от firkax

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

analyze-x86 показывает что sse нет (ну и правда, я его не прописывал и не разобрался даже куда, но см. ниже фф подаёт признаки его использования)

/opt/ff102my/firefox/firefox-bin	cpuid	15
/opt/ff102my/firefox/firefox-bin	nop	9366
/opt/ff102my/firefox/firefox-bin	call	8651
/opt/ff102my/firefox/firefox-bin	i486	71
/opt/ff102my/firefox/firefox-bin	i686	1496
/opt/ff102my/firefox/firefox-bin	total	196186

about:buildconfig

Build Configuration
Please be aware that this page doesn't reflect all the options used to build Firefox.
Build platform target = i686-pc-linux-gnu
CompilerVersionCompiler flags
/usr/bin/clang -std=gnu9911.0.1-fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/bin/clang++ -std=gnu++1711.0.1-Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wdeprecated-this-capture -Wempty-body -Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wno-error=tautological-type-limit-compare -Wunreachable-code -Wunreachable-code-return -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat -Wcomma -Wenum-compare-conditional -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-psabi -Wthread-safety -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -funwind-tables
/usr/bin/rustc1.63.0
Configure options

--host=i686-linux-gnu --target=i686-linux-gnu --disable-debug-symbols --without-wasm-sandboxed-libraries

При этом окно фф почему-то вместо «Mozilla Firefox» называется «Nightly» и в профайлере видны огромные стектрейсы всего подряд, которых в обычном фф не было - видимо отладочная информация. И это несмотря на наличие опции –disable-debug-symbols. Из этих стектрейсов функция UpdateAndRender, которая лагала, теперь занимает только 0.5% по времени, остальные 99.5% - какое-то

std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >::_M_realloc_insert<std::pair<int, int> >(__gnu_cxx::__normal_iterator<std::pair<int, int>*, std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > > >, std::pair<int, int>&&) [libxul.so]

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

Но вообще сборка оказалась не такой уж сложной, никакие ручные настройки vcs и питонов, как указано на оффсайте мозиллы, делать оказалось не надо, вся сборка теоретически выглядит так:

tar xf firefox-102.15.1esr.source.tar.xz
cd firefox-102.15.1
./mach configure [опции]
./mach build
./mach package

после чего создался файл ./obj-x86_64-pc-linux-gnux32/dist/firefox-102.15.1.en-US.linux-i686.tar.bz2 аналогичный тому что можно скачать с мозиллы бинарный тарболл.

Однако проблемы всё-таки были. Во-первых, в самом начале, на этапе подготовки mach (mach это обёртка на ввода команд и вызова по ним реальных исполнителей, зачем она нужна не знаю) нагло скачивалась с инета какая-то блоатварь, довольно долго и потом компилировалась, но только в первый раз, а в следующие (после полной чистки) она почему-то скачаться не смогла - в середине выдавала ошибку на попытке скачать https://github.com/rust-lang/crates.io-index (вроде бы, но wget-от этот урл качается без проблем) и в итоге писалось Could not install glean-sdk, so telemetry will not be collected. Continuing. и продолжало норм. Не знаю что это за телеметрия и зачем она нужна, наверно пофиг - в итоге меньше времени тратится.

см. ниже

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Во-вторых, по-дефолту (я в начале не указал ему опции сборки) оно пыталось собирать 64-битный фф (на 32-битной ОС!) и ругалось на отсутствие всякий 64-бит компонент, я их даже ставил

apt-get install lib64stdc++-10-dev   # missing <cstddef>
apt-get install libc6-dev-amd64      # missing <sys/cdefs.h>

но в итоге оно выдало вот такое:

 0:15.98 checking rustc version... 1.63.0
 0:16.01 checking cargo version... 1.65.0
 0:16.14 checking for rust host triplet...
 0:16.14 ERROR: The rust compiler host (i686-unknown-linux-gnu) is not suitable for the configure host (x86_64-pc-linux-gnux32/x86_64-unknown-linux-gnux32).
 0:16.14 You can solve this by:
 0:16.14 * Set your configure host to match the rust compiler host by editing your
 0:16.15 mozconfig and adding "ac_add_options --host=i686-unknown-linux-gnu".
 0:16.15 * Or, install the rust toolchain for x86_64-pc-linux-gnux32/x86_64-unknown-linux-gnux32, if supported, by running
 0:16.15 "rustup default stable-x86_64-unknown-linux-gnux32"
*** Fix above errors and then restart with "./mach build"

Затёр все следы (rm -Rf firefox-102.15.1 ~/.mozbuild ~/.cache ~/.cargo ~/.local /tmp/), распаковал заново

./mach configure --host=i686-linux-gnu --target=i686-linux-gnu
./mach build

заработало но всё равно

    MOZ_OBJDIR=/home/testuser/ff-moz/firefox-102.15.1/obj-x86_64-pc-linux-gnux32
    OBJDIR=/home/testuser/ff-moz/firefox-102.15.1/obj-x86_64-pc-linux-gnux32

избавиться от странного названия директории так и не удалось, пофиг

упало на <string.h> для target=wasm32-wasi

сделал

./mach configure --host=i686-linux-gnu --target=i686-linux-gnu --without-wasm-sandboxed-libraries
./mach build

(кстати может быть лаги из-за отсутствия этих wasm-libaries? в дебиановской сборке эта опция тоже присутствует)

Упало из-за нехватки адресного пространства процесса в 4гб при сборке

46:55.68    Compiling style v0.0.1 (/home/testuser/ff-moz/firefox-102.15.1/servo/components/style)
65:12.74 memory allocation of 431239860 bytes failed
65:13.06 error: could not compile `style`
65:13.07 Caused by:
65:13.07   process didn't exit successfully: `/usr/bin/rustc --crate-name style --edition=2018 servo/components/style/lib.rs

Вспомнил в debian/rules комментарий по поводу этого, память жрётся раст-комилятором из-за отладочных символов и на 32-бит хосте их надо отключать - опять всё тру и заново

./mach configure --host=i686-linux-gnu --target=i686-linux-gnu --without-wasm-sandboxed-libraries --disable-debug-symbols
./mach build

Опять упало

443:34.15 In file included from /home/testuser/ff-moz/firefox-102.15.1/modules/fdlibm/src/e_acos.cpp:44:
443:34.15 /home/testuser/ff-moz/firefox-102.15.1/modules/fdlibm/src/math_private.h:34:21: error: typedef redefinition with different types ('__double_t' (aka 'double') vs 'long double')
443:34.15 typedef __double_t  double_t;
443:34.15                     ^
443:34.15 /usr/include/math.h:156:21: note: previous definition is here
443:34.15 typedef long double double_t;
443:34.16                     ^
443:34.53 1 error generated.
443:34.53 gmake[4]: *** [/home/testuser/ff-moz/firefox-102.15.1/config/rules.mk:669: e_acos.o] Error 1
443:34.53 gmake[3]: *** [/home/testuser/ff-moz/firefox-102.15.1/config/recurse.mk:72: modules/fdlibm/src/target-objects] Error 2
443:34.53 gmake[3]: *** Waiting for unfinished jobs....
444:17.09 gmake[2]: *** [/home/testuser/ff-moz/firefox-102.15.1/config/recurse.mk:34: compile] Error 2
444:17.10 gmake[1]: *** [/home/testuser/ff-moz/firefox-102.15.1/config/rules.mk:361: default] Error 2
444:17.11 gmake: *** [client.mk:63: build] Error 2
444:17.11 149 compiler warnings present.
444:20.29 Notification center failed: Install notify-send (usually part of the libnotify package) to get a notification when the build finishes.

Выяснил что это баг, появившийся в 91-esr и 93+ не-esr, https://bugzilla.mozilla.org/show_bug.cgi?id=1729459 падает только на 32-битах и, говорят, только на относительно новых glibc (у старых не было double_t в math.h), мозилле кажется пофиг, они собирают на старом glibc и вообще не особо интересуются 32 битами? В дебиане опять нашлось решение к этому, беру патч из deb-src пакета Fix-math_private.h-for-i386-FTBFS.patch (он фиксит тот внутренний math.h чтобы его double_t стал таким же как в системном, не знаю насколько это коррентое решение но в итоге скомпилировалось)

Продолжаю компиляцию без чистки всего т.к. она уже полдня к этому моменту шла

./mach build

всё получилось

./mach package

результат в ./obj-x86_64-pc-linux-gnux32/dist/firefox-102.15.1.en-US.linux-i686.tar.bz2

где-то рядом кажется языковые пакеты спрятаны но я не стал с ними возиться

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Из этих стектрейсов функция UpdateAndRender, которая лагала, теперь занимает только 0.5% по времени, остальные 99.5% - какое-то

А нет, я не всё сразу заметил, вобщем вот логи профайлера - кажется куча времени уходит на функцию viaduct_log_error() которая тое вызывается из UpdateAndRender, который в свою очередь вызывается (почему?!) из этого аллокатора.

https://share.firefox.dev/48NCNaX

https://firk.cantconnect.ru/ff102prof.png

Судя по названию функции и тем что она жрёт всё время - он куда-то спамит ошибками, куда интересно? В консоли относительно чисто.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

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

https://share.firefox.dev/3RONV0r

firkax ★★★★★
() автор топика

Очередное обновление информации, если кому интересно, выяснилось несколько фактов.

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

  2. То что я «собрал с sse и лаги никуда не делись» - неправильно собрал. Я подставил те ключи в CFLAGS и они действовали только на .c но большинство кода там .cpp - так что надо было ещё и в CXXFLAGS. А ещё есть код на расте, что подставить туда я ещё не выяснил. SSE для .cpp заметно улучшило ситуацию, однако подробнее в следующем пункте. При этом в about:buildconfig в флагах для c++ они почему-то не появились.

  3. Оказалось что проблема таки не одна. Есть лаги в процессе вкладки (который обслуживает js) - там лагала функция рисования на canvas, и вот она кажется полностью исправилась после включения SSE в CXXFLAGS - и это как раз те лаги, которые были видны в самой игре и из-за которых я вообще полез разбираться. И есть ещё одни лаги в главном процессе в треде рендера (они видны в html-примере который я выкладывал, и в экране загрузки игры). Они собственно никуда не делись, и приходятся на софтварный эмулятор opengl, который фф включает для моей нвидии. Но эмулятор то есть и в официальной сборке и там он работает быстро - надо разбираться дальше. Возможно надо как-то присунуть sse в раст. В официальной сборке есть флаг –enable-rust-simd но у меня при попытке его использования сборка падает с ошибкой «unresolved import simd_funcs», «use of undeclared crate or module simd_funcs».

Почти 100% процового времени рендер-тред проводит в функции void draw_quad_spans<unsigned int>(int, glsl::vec2_scalar*, unsigned int, glsl::vec3*, Texture&, Texture&, ClipRect const&) [gfx/wr/swgl/src/rasterize.h] вокруг которой ещё всякой rust-код в большой количестве.

Профайлеры для лагов js-canvas:

кастомной сборки без SSE: https://share.firefox.dev/3ShU72s

мозилловской сборки: https://share.firefox.dev/48JPjse

кастомной сборки в SSE в CFLAGS+CXXFLAGS: https://share.firefox.dev/3tJCjEd

Бектрейс до функции где видны различия:

SkDraw::drawRect(SkRect const&, SkPaint const&, SkMatrix const*, SkRect const*) const [libxul.so]
SkDraw::drawBitmap(SkBitmap const&, SkMatrix const&, SkRect const*, SkPaint const&) const [libxul.so]
SkBitmapDevice::drawBitmap(SkBitmap const&, SkMatrix const&, SkRect const*, SkPaint const&) [libxul.so]
SkBitmapDevice::drawBitmapRect(SkBitmap const&, SkRect const*, SkRect const&, SkPaint const&, SkCanvas::SrcRectConstraint) [libxul.so]
SkBaseDevice::drawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const&, SkCanvas::SrcRectConstraint) [libxul.so]
SkCanvas::onDrawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) [libxul.so]
SkCanvas::drawImageRect(SkImage const*, SkRect const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) [libxul.so]
mozilla::gfx::DrawTargetSkia::DrawSurface(mozilla::gfx::SourceSurface*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::DrawSurfaceOptions const&, mozilla::gfx::DrawOptions const&) [libxul.so]
mozilla::dom::AdjustedTarget::DrawSurface(mozilla::gfx::SourceSurface*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::DrawSurfaceOptions const&, mozilla::gfx::DrawOptions const&) [libxul.so]
mozilla::dom::CanvasRenderingContext2D::DrawImage(mozilla::dom::HTMLImageElementOrSVGImageElementOrHTMLCanvasElementOrHTMLVideoElementOrOffscreenCanvasOrImageBitmap const&, double, double, double, double, double, double, double, double, unsigned char, mozilla::ErrorResult&) [libxul.so]
mozilla::dom::CanvasRenderingContext2D::DrawImage(mozilla::dom::HTMLImageElementOrSVGImageElementOrHTMLCanvasElementOrHTMLVideoElementOrOffscreenCanvasOrImageBitmap const&, double, double, double, double, mozilla::ErrorResult&) [libxul.so]
mozilla::dom::CanvasRenderingContext2D_Binding::drawImage(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [libxul.so]
CanvasRenderingContext2D.drawImage
mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) [libxul.so]
0x576307df
CanvasRenderingContext2D.prototype.drawImage [https://orteil.dashnet.org/cookieclicker/main.js?v=10b:733:53]
Game.Launch/Game.Init/Game.DrawBackground [https://orteil.dashnet.org/cookieclicker/main.js?v=10b:15170:30]
Game.Launch/Game.Draw [https://orteil.dashnet.org/cookieclicker/main.js?v=10b:16654:19]
Game.Launch/Game.Loop [https://orteil.dashnet.org/cookieclicker/main.js?v=10b:16769:19]
js::RunScript
setTimeout handler
nsTimerImpl::Fire
XRE_InitChildProcess
(root)

Дальше видны такие отличия:

  1. В версиях с SSE оно вообще меньшую долю времени занимает и кроме него становятся заметны всякие ожидания событий

  2. фф без SSE - почти время занимает draw_rect_as_path и в 30 раз меньше на SkScan::AntiFillRect, а в мозилловской и в моей с SSE такой огромной разницы нет, в разных местах то одно то другое больше

  3. внутри этой функции в no-sse версии есть вызовы функций с префиксом portable::, в мозилловской - sse2::, в моей с sse (arch=amdfam10) - sse3:: - что наводит на мысли что мозилловская сборка тоже под весьма древние процы и её вполне можно ускорить ещё дальше, если правильно собрать.

  4. В мозилловской версии функция drawDevPath заинлайнена в drawPath а в моих сборках нет - не знаю насколько это влияет

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

в дебиановском расте нет sse2 - оно работает на моем 3 пеньке

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

anonymous
()

Сделал ещё две сборки:

  1. в дебиановскую добавил arch=amdfam10 и в C и в C++ и в Rust
./configure –host=i686-linux-gnu –target=i686-linux-gnu MOZILLA_OFFICIAL=1 –enable-update-channel=esr MOZBUILD_STATE_PATH=/home/testuser/ff/firefox-esr-115.6.0esr/debian/.mozbuild CC=gcc CXX=g++ –disable-debug-symbols –enable-alsa –with-app-name=firefox-esr ‘RUSTFLAGS=-C target-cpu=amdfam10 -C target-feature=+sse -C target-feature=+sse2 –remap-path-prefix=/home/testuser/ff/firefox-esr-115.6.0esr=.’ –enable-system-ffi –enable-default-toolkit=cairo-gtk3-wayland –with-mozilla-api-keyfile=/home/testuser/ff/firefox-esr-115.6.0esr/debian/mls.key –with-google-location-service-api-keyfile=/home/testuser/ff/firefox-esr-115.6.0esr/debian/google.key –with-google-safebrowsing-api-keyfile=/home/testuser/ff/firefox-esr-115.6.0esr/debian/google.key –with-unsigned-addon-scopes=app,system –without-wasm-sandboxed-libraries –disable-updater MOZ_APP_REMOTINGNAME=Firefox-esr –with-system-libevent –disable-install-strip –with-system-zlib –enable-official-branding –prefix=/usr
/usr/bin/gcc -std=gnu9910.2.1-O2 -ffile-prefix-map=/home/testuser/ff/firefox-esr-115.6.0esr=. -fstack-protector-strong -Wformat -Werror=format-security -march=amdfam10 -msse -msse2 -mfpmath=sse -fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/bin/g++ -std=gnu++1710.2.1-Wdate-time -D_FORTIFY_SOURCE=2 -fno-sized-deallocation -fno-aligned-new -O2 -ffile-prefix-map=/home/testuser/ff/firefox-esr-115.6.0esr=. -fstack-protector-strong -Wformat -Werror=format-security -march=amdfam10 -msse -msse2 -mfpmath=sse -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -freorder-blocks -O2 -fomit-frame-pointer -funwind-tables
/usr/bin/rustc1.63.0-C target-cpu=amdfam10 -C target-feature=+sse -C target-feature=+sse2 –remap-path-prefix=/home/testuser/ff/firefox-esr-115.6.0esr=.

Лагает как и раньше, несмотря на наличие sse3 в именах нужных функций в профайлере canvas profiler render profiler

  1. скомпилировал нативные мозилловские исходники с arch=amdfam10 и основными опциями и патчами от дебиана
./configure –host=i686-linux-gnu –target=i686-linux-gnu MOZILLA_OFFICIAL=1 –disable-debug-symbols –enable-alsa ‘RUSTFLAGS=-C target-cpu=amdfam10 -C target-feature=+sse -C target-feature=+sse2’ –enable-js-shell –enable-default-toolkit=cairo-gtk3-x11-wayland –enable-proxy-bypass-protection –disable-proxy-direct-failover –without-wasm-sandboxed-libraries –disable-updater –enable-official-branding
/usr/bin/clang -std=gnu9911.0.1-march=amdfam10 -msse -msse2 -mfpmath=sse -fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/bin/clang++ -std=gnu++1711.0.1-Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wdeprecated-this-capture -Wempty-body -Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wno-error=tautological-type-limit-compare -Wunreachable-code -Wunreachable-code-return -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat -Wcomma -Wenum-compare-conditional -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-psabi -Wthread-safety -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -march=amdfam10 -msse -msse2 -mfpmath=sse -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -funwind-tables
/usr/bin/rustc1.63.0-C target-cpu=amdfam10 -C target-feature=+sse -C target-feature=+sse2

Работает чуточку медленнее чем бинарники с мозиллы, но совсем чуть-чуть. canvas profiler render profiles

Выводы:

  1. sse очень важно, без него лаги неизбежны, но дебиановской сборке оно почему-то совсем не помогает

  2. lto, pgo, -O3 и что там ешё есть в офф сборке и нет у меня - если и влияют то на грани заметности

  3. осталось проверить: а) 102 vs 115 (так уж вышло что deb-src я собирал 115 а mozilla-src 102); б) gcc vs clang (собирал deb=gcc, moz=clang); в) наверно ещё какие-то мелочи но там реально мелочи;

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

sse очень важно

А можно уже, гипотетически, сделать вывод, что, например, эта сборка (gnome, lxqt, mate) под твой проц (amdfam10) будет шустрее, чем дебиан, который установлен у тебя сейчас?

Гентушники мне правда уже сказали однозначно, что нет. Но я не теряю надежды, что смысл есть. ) Сам не хочу пока проверять.

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)