Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Dmitry V. Levin]

On Mon, Dec 13, 2021 at 01:30:26AM +0000, Girar awaiter (lav) wrote:
> https://git.altlinux.org/tasks/291873/logs/events.2.1.log
> 
> 2021-Dec-13 01:27:50 :: task #291873 for sisyphus resumed by lav:
> 2021-Dec-13 01:27:50 :: message: restore full /usr/lib/wine packing
> #100 build 3.1.13-alt1 from /people/lav/packages/rpmrebuild-arepo.git fetched at 2021-Dec-13 01:17:05
[...]
> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
>  Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
>  - rpmrebuild-arepo.conf: restore /usr/lib/wine

Надо написать, почему это было сделано.
Как минимум в commit message, а если причина user visible,
то ещё и в %changelog.


-- 
ldv

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Vitaly Lipatov]

Dmitry V. Levin писал 13.12.21 4:52:
> On Mon, Dec 13, 2021 at 01:30:26AM +0000, Girar awaiter (lav) wrote:
>> https://git.altlinux.org/tasks/291873/logs/events.2.1.log
>> 
>> 2021-Dec-13 01:27:50 :: task #291873 for sisyphus resumed by lav:
>> 2021-Dec-13 01:27:50 :: message: restore full /usr/lib/wine packing
>> #100 build 3.1.13-alt1 from /people/lav/packages/rpmrebuild-arepo.git 
>> fetched at 2021-Dec-13 01:17:05
> [...]
>> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
>>  Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
>>  - rpmrebuild-arepo.conf: restore /usr/lib/wine
> 
> Надо написать, почему это было сделано.
> Как минимум в commit message, а если причина user visible,
> то ещё и в %changelog.
В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine, это 
сломало упаковку.
Как лучше это написать?

restore /usr/lib/wine packing?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

[devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Заменил ветвление в LZMA декомпрессоре на ассемблерную вставку с CMOV, 
на моём компьютере даёт 35% ускорение при распаковке 300мб из сжатой 
билд директории от Python 3.

На шлюзе basalt нормально проверить не получается, потому что на нём 
переменная нагрузка, то с патчем 10-20% быстрее, а иногда без патча 
получается быстрее. Мне нужна помощь в проверке.

Может сильно зависеть от модели процессора.

Патч: https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188

На x86 (32-бит) не проверял, но тоже должно работать.

Если будет стабильное ускорение, но можно предложить в апстрим.

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Оказалось что ускорение со сжатых текстовых данных очень маленькое, 
только +4% с исходников ядра линукс. И на процессоре AMD на этих 
исходниках вообще +1%. Но я попробую это исправить.

На бинарниках и данных Firefox (/usr/lib/firefox) выходит +11% ускорение.

On 13.12.2021 16:02, Ilya Kurdyukov wrote:
> Заменил ветвление в LZMA декомпрессоре на ассемблерную вставку с CMOV, 
> на моём компьютере даёт 35% ускорение при распаковке 300мб из сжатой 
> билд директории от Python 3.
>
> На шлюзе basalt нормально проверить не получается, потому что на нём 
> переменная нагрузка, то с патчем 10-20% быстрее, а иногда без патча 
> получается быстрее. Мне нужна помощь в проверке.
>
> Может сильно зависеть от модели процессора.
>
> Патч: 
> https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
>
> На x86 (32-бит) не проверял, но тоже должно работать.
>
> Если будет стабильное ускорение, но можно предложить в апстрим.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Я думаю, что финальная версия (патч по ссылке обновлён).

Билд питона теперь разжимается 42% быстрее.

Бинарники Firefox с данными - 21% быстрее.

Исходники ядра Линукс - 10% быстрее.

Но нужно еще проверить на разных моделях x86 процессоров, что я сделать 
не смогу.

On 13.12.2021 18:59, Ilya Kurdyukov wrote:
> Оказалось что ускорение со сжатых текстовых данных очень маленькое, 
> только +4% с исходников ядра линукс. И на процессоре AMD на этих 
> исходниках вообще +1%. Но я попробую это исправить.
>
> На бинарниках и данных Firefox (/usr/lib/firefox) выходит +11% ускорение.
>
> On 13.12.2021 16:02, Ilya Kurdyukov wrote:
>> Заменил ветвление в LZMA декомпрессоре на ассемблерную вставку с 
>> CMOV, на моём компьютере даёт 35% ускорение при распаковке 300мб из 
>> сжатой билд директории от Python 3.
>>
>> На шлюзе basalt нормально проверить не получается, потому что на нём 
>> переменная нагрузка, то с патчем 10-20% быстрее, а иногда без патча 
>> получается быстрее. Мне нужна помощь в проверке.
>>
>> Может сильно зависеть от модели процессора.
>>
>> Патч: 
>> https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
>>
>> На x86 (32-бит) не проверял, но тоже должно работать.
>>
>> Если будет стабильное ускорение, но можно предложить в апстрим.
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Vitaly Chikunov]

Hi,

Отдел абсурдизации дарит вам на новый год ссылку: xz-devel@tukaani.org

On Mon, Dec 13, 2021 at 09:52:42PM +0700, Ilya Kurdyukov wrote:
> Я думаю, что финальная версия (патч по ссылке обновлён).
> 
> Билд питона теперь разжимается 42% быстрее.
> 
> Бинарники Firefox с данными - 21% быстрее.
> 
> Исходники ядра Линукс - 10% быстрее.
> 
> Но нужно еще проверить на разных моделях x86 процессоров, что я сделать не
> смогу.
> 
> On 13.12.2021 18:59, Ilya Kurdyukov wrote:
> > Оказалось что ускорение со сжатых текстовых данных очень маленькое,
> > только +4% с исходников ядра линукс. И на процессоре AMD на этих
> > исходниках вообще +1%. Но я попробую это исправить.
> > 
> > На бинарниках и данных Firefox (/usr/lib/firefox) выходит +11% ускорение.
> > 
> > On 13.12.2021 16:02, Ilya Kurdyukov wrote:
> > > Заменил ветвление в LZMA декомпрессоре на ассемблерную вставку с
> > > CMOV, на моём компьютере даёт 35% ускорение при распаковке 300мб из
> > > сжатой билд директории от Python 3.
> > > 
> > > На шлюзе basalt нормально проверить не получается, потому что на нём
> > > переменная нагрузка, то с патчем 10-20% быстрее, а иногда без патча
> > > получается быстрее. Мне нужна помощь в проверке.
> > > 
> > > Может сильно зависеть от модели процессора.
> > > 
> > > Патч:
> > > https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
> > > 
> > > На x86 (32-бит) не проверял, но тоже должно работать.
> > > 
> > > Если будет стабильное ускорение, но можно предложить в апстрим.
> > > 
> > > _______________________________________________
> > > Devel mailing list
> > > Devel@lists.altlinux.org
> > > https://lists.altlinux.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

А можно помочь и без ехидства? Мне нужно проверить на разных 
процессорах, прежде чем предлагать в апстрим. Чтобы так не оказалось, 
что это у меня такие хорошие результаты, а на каких-то процессорах замедлит.

On 13.12.2021 22:08, Vitaly Chikunov wrote:
> Hi,
>
> Отдел абсурдизации дарит вам на новый год ссылку: xz-devel@tukaani.org

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Mon, 13 Dec 2021 22:42:17 +0700 Ilya Kurdyukov wrote:
> А можно помочь и без ехидства? Мне нужно проверить на разных 
> процессорах, прежде чем предлагать в апстрим. Чтобы так не оказалось, 
> что это у меня такие хорошие результаты, а на каких-то процессорах замедлит.

Я проверю на x86 (Intel Atom N270). Займёт некоторое время, т.к.
машина старенькая и слабенькая. Проверю распаковку имеющихся под
рукой исходников ядра и бинарного пакета firefox (там zstd,
перепакую в xz -9e --x86).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Mon, 13 Dec 2021 19:49:20 +0300 Andrey Savchenko wrote:
> On Mon, 13 Dec 2021 22:42:17 +0700 Ilya Kurdyukov wrote:
> > А можно помочь и без ехидства? Мне нужно проверить на разных 
> > процессорах, прежде чем предлагать в апстрим. Чтобы так не оказалось, 
> > что это у меня такие хорошие результаты, а на каких-то процессорах замедлит.
> 
> Я проверю на x86 (Intel Atom N270). Займёт некоторое время, т.к.
> машина старенькая и слабенькая. Проверю распаковку имеющихся под
> рукой исходников ядра и бинарного пакета firefox (там zstd,
> перепакую в xz -9e --x86).

		old,s		new,s		delta,%
kernel src	33.522±0.077	32.515±0.087	3.01±0.34
firefox pkg	14.645±0.030	14.256±0.023	2.66±0.25

Погрешности приведены для одного стандартного отклонения.
Тесты делались на tmpfs для уменьшения эффекта i/o.

Результат небольшой, но значимый и статистически достоверный.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Для понимания что делает патч:

В LZMA используется адаптивное арифметическое кодирование каждого бита.

А именно: ru.wikipedia.org/wiki/Интервальное_кодирование

После того как бит раскодирован из потока данных - обновляется несколько 
переменных, причём в зависимости от того какой бит прочитали (0 или 1) 
делается это по разному. То есть в конце чтения бита стоит конструкция 
вида if-else, а это условные прыжки в бинарном коде. Ветвление в 
программе тормозит её выполнение, потому что процессору нужно очистить 
конвейер с заранее декодированными инструкциями и заполнить его 
инструкциями по новому адресу, короче говоря прыжок это дорогая инструкция.

Патч убирает это ветвление за счёт того, что оба пути исполнения if-else 
вычисляются одновременно, но код получается без ветвления.

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

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

Поэтому на более простых процессорах (мобильных или просто старых) 
ускорение от патча будет ниже. Как Intel Atom на котором проверил Андрей.


On 14.12.2021 01:59, Andrey Savchenko wrote:
>
>> Я проверю на x86 (Intel Atom N270). Займёт некоторое время, т.к.
>> машина старенькая и слабенькая. Проверю распаковку имеющихся под
>> рукой исходников ядра и бинарного пакета firefox (там zstd,
>> перепакую в xz -9e --x86).
> 		old,s		new,s		delta,%
> kernel src	33.522±0.077	32.515±0.087	3.01±0.34
> firefox pkg	14.645±0.030	14.256±0.023	2.66±0.25
>
> Погрешности приведены для одного стандартного отклонения.
> Тесты делались на tmpfs для уменьшения эффекта i/o.
>
> Результат небольшой, но значимый и статистически достоверный.
>
> Best regards,
> Andrew Savchenko

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Vitaly Chikunov]

On Mon, Dec 13, 2021 at 10:42:17PM +0700, Ilya Kurdyukov wrote:
> А можно помочь и без ехидства? Мне нужно проверить на разных процессорах,
> прежде чем предлагать в апстрим. Чтобы так не оказалось, что это у меня
> такие хорошие результаты, а на каких-то процессорах замедлит.

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

> 
> On 13.12.2021 22:08, Vitaly Chikunov wrote:
> > Hi,
> > 
> > Отдел абсурдизации дарит вам на новый год ссылку: xz-devel@tukaani.org
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

> Пожалуйста, пришлите какие команды надо запустить, чтоб собрать и
> протестировать то, что вам нужно.
git clone git://git.altlinux.org/gears/x/xz.git
cd xz
patch -p1 < faster_lzma_decoder_x86.patch

Патч здесь:

 > https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188

Далее собираем через hasher, или:
./autogen.sh --no-po4a
./configure
make all

Проверить можно так:

1) Исходники ядра линукс:

https://fossies.org/linux/kernel/v5.15/linux-5.15.7.tar.xz

time -p src/xz/xz -d < linux-5.15.7.tar.xz > /dev/null

2) Бинарники и ресурсы Firefox (можно заменить на несколько сотен 
мегабайт других):

tar -cf firefox.tar /usr/lib/firefox
src/xz/xz -c -7e --format=lzma firefox.tar > firefox.tar.lzma

time -p src/xz/xz -d < firefox.tar.lzma > /dev/null


Частоту процессора перед проверкой надо на максимум ставить. Или 
запускать тест несколько раз подряд, результат первого запуска выбросить.

Также более точный замер:

perf stat -r 5 src/xz/xz -c -d firefox.tar.lzma > /dev/null


На сжатом тексте даёт наименьшее ускорение.

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Тестовый пакет для Сизифа: https://git.altlinux.org/tasks/291923/

Коммит с патчем: 
http://git.altlinux.org/people/ilyakurdyukov/packages/xz.git


On 14.12.2021 09:53, Ilya Kurdyukov wrote:
>
>> Пожалуйста, пришлите какие команды надо запустить, чтоб собрать и
>> протестировать то, что вам нужно.
> git clone git://git.altlinux.org/gears/x/xz.git
> cd xz
> patch -p1 < faster_lzma_decoder_x86.patch
>
> Патч здесь:
>
> > https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
>
> Далее собираем через hasher, или:
> ./autogen.sh --no-po4a
> ./configure
> make all
>
> Проверить можно так:
>
> 1) Исходники ядра линукс:
>
> https://fossies.org/linux/kernel/v5.15/linux-5.15.7.tar.xz
>
> time -p src/xz/xz -d < linux-5.15.7.tar.xz > /dev/null
>
> 2) Бинарники и ресурсы Firefox (можно заменить на несколько сотен 
> мегабайт других):
>
> tar -cf firefox.tar /usr/lib/firefox
> src/xz/xz -c -7e --format=lzma firefox.tar > firefox.tar.lzma
>
> time -p src/xz/xz -d < firefox.tar.lzma > /dev/null
>
>
> Частоту процессора перед проверкой надо на максимум ставить. Или 
> запускать тест несколько раз подряд, результат первого запуска выбросить.
>
> Также более точный замер:
>
> perf stat -r 5 src/xz/xz -c -d firefox.tar.lzma > /dev/null
>
>
> На сжатом тексте даёт наименьшее ускорение.
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Мне предложили этот архив как образец для тестирования сжатых бинарных 
данных.

https://mirrors.edge.kernel.org/pub/linux/kernel/firmware/linux-firmware-20211027.tar.xz 
<https://mirrors.edge.kernel.org/pub/linux/kernel/firmware/linux-firmware-20211027.tar.xz>

На нём на Skylake получается +29% ускорение декомпрессии.


On 14.12.2021 13:11, Ilya Kurdyukov wrote:
>
> Тестовый пакет для Сизифа: https://git.altlinux.org/tasks/291923/
>
> Коммит с патчем: 
> http://git.altlinux.org/people/ilyakurdyukov/packages/xz.git
>
>
> On 14.12.2021 09:53, Ilya Kurdyukov wrote:
>>
>>> Пожалуйста, пришлите какие команды надо запустить, чтоб собрать и
>>> протестировать то, что вам нужно.
>> git clone git://git.altlinux.org/gears/x/xz.git
>> cd xz
>> patch -p1 < faster_lzma_decoder_x86.patch
>>
>> Патч здесь:
>>
>> > https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
>>
>> Далее собираем через hasher, или:
>> ./autogen.sh --no-po4a
>> ./configure
>> make all
>>
>> Проверить можно так:
>>
>> 1) Исходники ядра линукс:
>>
>> https://fossies.org/linux/kernel/v5.15/linux-5.15.7.tar.xz
>>
>> time -p src/xz/xz -d < linux-5.15.7.tar.xz > /dev/null
>>
>> 2) Бинарники и ресурсы Firefox (можно заменить на несколько сотен 
>> мегабайт других):
>>
>> tar -cf firefox.tar /usr/lib/firefox
>> src/xz/xz -c -7e --format=lzma firefox.tar > firefox.tar.lzma
>>
>> time -p src/xz/xz -d < firefox.tar.lzma > /dev/null
>>
>>
>> Частоту процессора перед проверкой надо на максимум ставить. Или 
>> запускать тест несколько раз подряд, результат первого запуска 
>> выбросить.
>>
>> Также более точный замер:
>>
>> perf stat -r 5 src/xz/xz -c -d firefox.tar.lzma > /dev/null
>>
>>
>> На сжатом тексте даёт наименьшее ускорение.
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]

On Mon, 13 Dec 2021 21:52:42 +0700 Ilya Kurdyukov wrote:
> Я думаю, что финальная версия (патч по ссылке обновлён).

Думаю, что для апстрима нужно сделать проверку на наличие cmov на
этапе configure и добавить проверку этого define в строке:
#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))

cmov есть не на всех i386 (нет на <i686 и некоторых сторонних
моделях i686). Понятно, что такое железо сейчас редко используется,
но всё же. Тем более, что проверка build-time и на run-time не
влияет. Если по какой-то причине нужно run-time сделать, следует
смотреть регистры cpuid.

> Билд питона теперь разжимается 42% быстрее.
> 
> Бинарники Firefox с данными - 21% быстрее.
> 
> Исходники ядра Линукс - 10% быстрее.
> 
> Но нужно еще проверить на разных моделях x86 процессоров, что я сделать 
> не смогу.
> 
> On 13.12.2021 18:59, Ilya Kurdyukov wrote:
> > Оказалось что ускорение со сжатых текстовых данных очень маленькое, 
> > только +4% с исходников ядра линукс. И на процессоре AMD на этих 
> > исходниках вообще +1%. Но я попробую это исправить.
> >
> > На бинарниках и данных Firefox (/usr/lib/firefox) выходит +11% ускорение.
> >
> > On 13.12.2021 16:02, Ilya Kurdyukov wrote:
> >> Заменил ветвление в LZMA декомпрессоре на ассемблерную вставку с 
> >> CMOV, на моём компьютере даёт 35% ускорение при распаковке 300мб из 
> >> сжатой билд директории от Python 3.
> >>
> >> На шлюзе basalt нормально проверить не получается, потому что на нём 
> >> переменная нагрузка, то с патчем 10-20% быстрее, а иногда без патча 
> >> получается быстрее. Мне нужна помощь в проверке.
> >>
> >> Может сильно зависеть от модели процессора.
> >>
> >> Патч: 
> >> https://gist.github.com/ilyakurdyukov/f514418f3affd677e1ac408ec0c09188
> >>
> >> На x86 (32-бит) не проверял, но тоже должно работать.
> >>
> >> Если будет стабильное ускорение, но можно предложить в апстрим.
> >>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel@lists.altlinux.org
> >> https://lists.altlinux.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Alexey V. Vissarionov]

On 2021-12-14 18:22:24 +0300, Andrey Savchenko wrote:

 >> Я думаю, что финальная версия (патч по ссылке обновлён).
 > Думаю, что для апстрима нужно сделать проверку на наличие cmov
 > на этапе configure и добавить проверку этого define в строке:
 > #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))

Еще проще:
#if defined(__GNUC__) && defined(__x86_64__)

 > cmov есть не на всех i386 (нет на <i686 и некоторых сторонних
 > моделях i686).

Да, потеряем часть 32-битных систем, где оно в принципе могло бы
работать...

 > Понятно, что такое железо сейчас редко используется, но всё же.

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

 > Тем более, что проверка build-time и на run-time не влияет.
 > Если по какой-то причине нужно run-time сделать, следует
 > смотреть регистры cpuid.

А оно надо? Ведь build-time проверки на 64-битность архитектуры
вполне достаточно.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Tue, 14 Dec 2021 20:12:20 +0300 Alexey V. Vissarionov wrote:
> On 2021-12-14 18:22:24 +0300, Andrey Savchenko wrote:
> 
>  >> Я думаю, что финальная версия (патч по ссылке обновлён).
>  > Думаю, что для апстрима нужно сделать проверку на наличие cmov
>  > на этапе configure и добавить проверку этого define в строке:
>  > #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
> 
> Еще проще:
> #if defined(__GNUC__) && defined(__x86_64__)
> 
>  > cmov есть не на всех i386 (нет на <i686 и некоторых сторонних
>  > моделях i686).
> 
> Да, потеряем часть 32-битных систем, где оно в принципе могло бы
> работать...
> 
>  > Понятно, что такое железо сейчас редко используется, но всё же.
> 
> ... ну и хрен бы с ними - пусть продолжают работать, как сейчас.
> 
>  > Тем более, что проверка build-time и на run-time не влияет.
>  > Если по какой-то причине нужно run-time сделать, следует
>  > смотреть регистры cpuid.
> 
> А оно надо? Ведь build-time проверки на 64-битность архитектуры
> вполне достаточно.
 
Ну вот я пользуюсь 32-битной системой — мне надо.
А ты продолжай затыкать спектры и мелтдауны.


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Alexey V. Vissarionov]

On 2021-12-14 20:34:11 +0300, Andrey Savchenko wrote:

 >> Еще проще:
 >> #if defined(__GNUC__) && defined(__x86_64__)
 >>> cmov есть не на всех i386 (нет на <i686 и некоторых сторонних
 >>> моделях i686).
 >> Да, потеряем часть 32-битных систем, где оно в принципе могло
 >> бы работать...
 >>> Понятно, что такое железо сейчас редко используется, но всё же.
 >> ... ну и хрен бы с ними - пусть продолжают работать, как сейчас.
 >>> Тем более, что проверка build-time и на run-time не влияет.
 >>> Если по какой-то причине нужно run-time сделать, следует
 >>> смотреть регистры cpuid.
 >> А оно надо? Ведь build-time проверки на 64-битность архитектуры
 >> вполне достаточно.
 > Ну вот я пользуюсь 32-битной системой — мне надо. А ты продолжай
 > затыкать спектры и мелтдауны.

Даже со всеми затычками 64-битные системы (как АПК) производительнее
32-битных. А "музыку заказывают" пользователи именно таких систем, а
не хомячки с прабабушкиными пнями-4.

Напомню, что архитектура x86_64 в этом году справила совершеннолетие.
И о том, что 64 бита - это не только писюшатина.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Спасибо всем кто принял участие в тестировании на x86.

Думаю данных достаточно, я написал письмо мейнтейнеру XZ Utils с 
просьбой принять патч. Но там написано что он может долго отвечать. У 
кого настроен IRC - можете написать сюда: "The project's IRC channel is 
#tukaani on Libera Chat. (irc.libera.chat:6697 TLS)", тогда процесс 
пойдёт быстрее.

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

Но для AArch64 протестировано мало (лишь 2 модели), так что всё еще 
будет полезно.

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Wed, 15 Dec 2021 14:29:08 +0700 Ilya Kurdyukov wrote:
> Спасибо всем кто принял участие в тестировании на x86.
> 
> Думаю данных достаточно, я написал письмо мейнтейнеру XZ Utils с 
> просьбой принять патч. Но там написано что он может долго отвечать. У 
> кого настроен IRC - можете написать сюда: "The project's IRC channel is 
> #tukaani on Libera Chat. (irc.libera.chat:6697 TLS)", тогда процесс 
> пойдёт быстрее.
> 
> Мои опасения были, что на некоторых моделях процессоров может оказаться, 
> что новый код не ускоряет, а замедляет. И тогда пришлось бы делать две 
> версии декодера, и определять какую использовать в рантайме. Но среди 
> распространённых моделей такого не нашлось.
> 
> Но для AArch64 протестировано мало (лишь 2 модели), так что всё еще 
> будет полезно.

AArch64: Cortex-A53 (pinephone) в 1 поток на xz-3.0alpha2:

		old,s		new,s		delta,%
kernel		31.23±0.02	29.46±0.02	5.68±0.08
firmware	29.84±0.02	27.20±0.04	8.86±0.13

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Wed, 15 Dec 2021 18:55:38 +0300 Andrey Savchenko wrote:
> On Wed, 15 Dec 2021 14:29:08 +0700 Ilya Kurdyukov wrote:
> > Спасибо всем кто принял участие в тестировании на x86.
> > 
> > Думаю данных достаточно, я написал письмо мейнтейнеру XZ Utils с 
> > просьбой принять патч. Но там написано что он может долго отвечать. У 
> > кого настроен IRC - можете написать сюда: "The project's IRC channel is 
> > #tukaani on Libera Chat. (irc.libera.chat:6697 TLS)", тогда процесс 
> > пойдёт быстрее.
> > 
> > Мои опасения были, что на некоторых моделях процессоров может оказаться, 
> > что новый код не ускоряет, а замедляет. И тогда пришлось бы делать две 
> > версии декодера, и определять какую использовать в рантайме. Но среди 
> > распространённых моделей такого не нашлось.
> > 
> > Но для AArch64 протестировано мало (лишь 2 модели), так что всё еще 
> > будет полезно.
> 
> AArch64: Cortex-A53 (pinephone) в 1 поток на xz-3.0alpha2:

xz-5.3.2alpha (git head, короче говоря)

> 
> 		old,s		new,s		delta,%
> kernel		31.23±0.02	29.46±0.02	5.68±0.08
> firmware	29.84±0.02	27.20±0.04	8.86±0.13
> 
> Best regards,
> Andrew Savchenko


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] ускорение lzma декомпрессии (XZ Utils)

[Ilya Kurdyukov]

Мейнтейнер XZ Utils ответил, что патч небольшой, поэтому будет просто 
его проверить и принять.

Сейчас он работает над другими изменениями, поэтому к этому патчу 
приступит не ранее февраля.

Также заметил, что некто уже написал ассемблерную версию декодера (с 
использованием CMOV) для x86_64 (https://github.com/conor42/fxz 
<https://github.com/conor42/fxz>) Но такой объём ему сложно проверить и 
принять в апстрим. Кстати, я сам сначала хотел написать на ассемблере 
(что заняло бы много времени), но получилось обойтись ассемблерной вставкой.

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Dmitry V. Levin]

On Mon, Dec 13, 2021 at 04:56:00AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 13.12.21 4:52:
> > On Mon, Dec 13, 2021 at 01:30:26AM +0000, Girar awaiter (lav) wrote:
> >> https://git.altlinux.org/tasks/291873/logs/events.2.1.log
> >> 
> >> 2021-Dec-13 01:27:50 :: task #291873 for sisyphus resumed by lav:
> >> 2021-Dec-13 01:27:50 :: message: restore full /usr/lib/wine packing
> >> #100 build 3.1.13-alt1 from /people/lav/packages/rpmrebuild-arepo.git 
> >> fetched at 2021-Dec-13 01:17:05
> > [...]
> >> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
> >>  Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
> >>  - rpmrebuild-arepo.conf: restore /usr/lib/wine
> > 
> > Надо написать, почему это было сделано.
> > Как минимум в commit message, а если причина user visible,
> > то ещё и в %changelog.
> В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine, это 
> сломало упаковку.
> Как лучше это написать?

Так и написать, например:
- rpmrebuild-arepo.conf: reintroduced /usr/lib/wine mistakenly removed
  in the previous release.


-- 
ldv

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Alexey V. Vissarionov]

On 2021-12-14 03:22:16 +0300, Dmitry V. Levin wrote:

 >>>> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
 >>>> Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
 >>>> - rpmrebuild-arepo.conf: restore /usr/lib/wine
 >>> Надо написать, почему это было сделано.
 >>> Как минимум в commit message, а если причина user visible,
 >>> то ещё и в %changelog.
 >> В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine,
 >> это сломало упаковку. Как лучше это написать?
 > Так и написать, например: - rpmrebuild-arepo.conf: reintroduced
 > /usr/lib/wine mistakenly removed in the previous release.

s/mistakenly/erroneously/


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Dmitry V. Levin]

On Tue, Dec 14, 2021 at 08:04:01AM +0300, Alexey V. Vissarionov wrote:
> On 2021-12-14 03:22:16 +0300, Dmitry V. Levin wrote:
> 
>  >>>> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
>  >>>> Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
>  >>>> - rpmrebuild-arepo.conf: restore /usr/lib/wine
>  >>> Надо написать, почему это было сделано.
>  >>> Как минимум в commit message, а если причина user visible,
>  >>> то ещё и в %changelog.
>  >> В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine,
>  >> это сломало упаковку. Как лучше это написать?
>  > Так и написать, например: - rpmrebuild-arepo.conf: reintroduced
>  > /usr/lib/wine mistakenly removed in the previous release.
> 
> s/mistakenly/erroneously/

Это зависит от тонкостей причины, пусть автор решает, как оно было
на самом деле.


-- 
ldv

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Vitaly Lipatov]

Dmitry V. Levin писал 14.12.21 11:57:
> On Tue, Dec 14, 2021 at 08:04:01AM +0300, Alexey V. Vissarionov wrote:
>> On 2021-12-14 03:22:16 +0300, Dmitry V. Levin wrote:
>> 
>>  >>>> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
>>  >>>> Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
>>  >>>> - rpmrebuild-arepo.conf: restore /usr/lib/wine
>>  >>> Надо написать, почему это было сделано.
>>  >>> Как минимум в commit message, а если причина user visible,
>>  >>> то ещё и в %changelog.
>>  >> В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine,
>>  >> это сломало упаковку. Как лучше это написать?
>>  > Так и написать, например: - rpmrebuild-arepo.conf: reintroduced
>>  > /usr/lib/wine mistakenly removed in the previous release.
>> 
>> s/mistakenly/erroneously/
> 
> Это зависит от тонкостей причины, пусть автор решает, как оно было
> на самом деле.
Сейчас в задании такой текст:
- restore /usr/lib/wine packing (was deleted by mistake)

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

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Dmitry V. Levin]

On Tue, Dec 14, 2021 at 08:31:16PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 14.12.21 11:57:
> > On Tue, Dec 14, 2021 at 08:04:01AM +0300, Alexey V. Vissarionov wrote:
> >> On 2021-12-14 03:22:16 +0300, Dmitry V. Levin wrote:
> >> 
> >>  >>>> #100 rpmrebuild-arepo 3.1.12-alt1 -> 3.1.13-alt1
> >>  >>>> Mon Dec 13 2021 Vitaly Lipatov <lav@altlinux.ru> 3.1.13-alt1
> >>  >>>> - rpmrebuild-arepo.conf: restore /usr/lib/wine
> >>  >>> Надо написать, почему это было сделано.
> >>  >>> Как минимум в commit message, а если причина user visible,
> >>  >>> то ещё и в %changelog.
> >>  >> В прошлый раз я был не прав, когда удалил оттуда /usr/lib/wine,
> >>  >> это сломало упаковку. Как лучше это написать?
> >>  > Так и написать, например: - rpmrebuild-arepo.conf: reintroduced
> >>  > /usr/lib/wine mistakenly removed in the previous release.
> >> 
> >> s/mistakenly/erroneously/
> > 
> > Это зависит от тонкостей причины, пусть автор решает, как оно было
> > на самом деле.
> Сейчас в задании такой текст:
> - restore /usr/lib/wine packing (was deleted by mistake)
> 
> переделывать на ваш вариант или достаточно?

В %changelog всё ещё написано "- rpmrebuild-arepo.conf: restore /usr/lib/wine",
и это желательно доработать.


-- 
ldv

Re: [devel] [#291873] EPERM (try 2) rpmrebuild-arepo.git=3.1.13-alt1

[Vitaly Lipatov]

Dmitry V. Levin писал 14.12.21 23:50:
...
> В %changelog всё ещё написано "- rpmrebuild-arepo.conf: restore 
> /usr/lib/wine",
> и это желательно доработать.
Исправил.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team