[devel] Оптимизированные для i686 и выше библиотеки.

[devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

Привет.

Хотелось бы собрать оптимизированные для >= i686 библиотеки ffmpeg с
использованием CMOV.

Куда правильно класть такие библиотеки в ALT?

-- 
ГИБДД - Гони Инспектору Бабки и Дуй Дальше

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Michael Shigorin]

On Fri, Aug 27, 2010 at 11:52:30AM +0400, Konstantin Pavlov wrote:
> Хотелось бы собрать оптимизированные для >= i686 библиотеки
> ffmpeg с использованием CMOV.  Куда правильно класть такие
> библиотеки в ALT?

В /people, а ещё глянь #23871.

По *lib/i686 сейчас пусто:
contents_index.i586:/lib/i686   filesystem
contents_index.i586:/lib/i686/tls       filesystem
contents_index.x86_64:/lib/i686 filesystem
contents_index.x86_64:/lib/i686/tls     filesystem

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

On Fri, Aug 27, 2010 at 11:09:24AM +0300, Michael Shigorin wrote:
> On Fri, Aug 27, 2010 at 11:52:30AM +0400, Konstantin Pavlov wrote:
> > Хотелось бы собрать оптимизированные для >= i686 библиотеки
> > ffmpeg с использованием CMOV.  Куда правильно класть такие
> > библиотеки в ALT?
> 
> В /people, а ещё глянь #23871.

В /people нет желания, туда никто никогда не смотрит.

#23871 никакого отношения не имеет к моей проблеме.

> По *lib/i686 сейчас пусто:
> contents_index.i586:/lib/i686   filesystem
> contents_index.i586:/lib/i686/tls       filesystem
> contents_index.x86_64:/lib/i686 filesystem
> contents_index.x86_64:/lib/i686/tls     filesystem

В том и вопрос, в Дебиане это /usr/lib/i686/cmov/ .

-- 
 * aphlux пару дней назад попробовал поставить Fedora Core 4. Ребята, ALC 3.0 -
   это замечательный, стабильный продукт с огромным функционалом "из коробки",
   не требующий никаких дополнительных действий после установки.

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Andrey Rahmatullin]

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

On Fri, Aug 27, 2010 at 12:12:55PM +0400, Konstantin Pavlov wrote:
> > По *lib/i686 сейчас пусто:
> > contents_index.i586:/lib/i686   filesystem
> > contents_index.i586:/lib/i686/tls       filesystem
> > contents_index.x86_64:/lib/i686 filesystem
> > contents_index.x86_64:/lib/i686/tls     filesystem
> В том и вопрос, в Дебиане это /usr/lib/i686/cmov/ .
[13:44:00] <wRAR> strings /sbin/ldconfig|grep (cmov|i686) показывает, что лдконфиг знает сам
[13:44:07] <vsu> ну насчёт i686/cmov не знаю
[13:44:39] <vsu> тут получается ./tls/i686/sse2:./tls/i686:./tls/sse2:./tls:./i686/sse2:./i686:./sse2:.
[13:50:06] <wRAR> sudo ldconfig -vNX
[13:50:08] <wRAR> хм
[13:50:30] <wRAR> на бебеане больше пишет
[13:50:38] <wRAR> /usr/lib/i686/cmov: (hwcap: 0x0008000000008000)
[13:52:27] <wRAR> http://patch-tracker.debian.org/patch/series/view/eglibc/2.11.2-2/i386/local-cmov.diff
[13:52:44] <wRAR> походу там cmov отдельно потому что нельзя с cmov класть в 686
[13:59:47] <vsu> действительно, с LD_HWCAP_MASK=0x4008000 в путях появляется и cmov
[14:05:15] <vsu> вообще на самом деле -march=i686 подразумевает поддержку cmov
[14:05:43] <vsu> поэтому для недоделанных его не включают



-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<wRAR> The old D-Bus API will be removed. We gonna have a whole new D-Bus API
       set that is smaller and more powerful.
<ilyak_> Фиг с ним, они вроде не в первый раз меняют API полностью?
<ilyak_> Причем там у них этого API полтора вызова
<dottedmag> А теперь меньше! 0.75!
<dottedmag> И эти 0.75 more powerful!

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Michael Shigorin]

On Fri, Aug 27, 2010 at 12:12:55PM +0400, Konstantin Pavlov wrote:
> > > Хотелось бы собрать оптимизированные для >= i686 библиотеки
> > > ffmpeg с использованием CMOV.  Куда правильно класть такие
> > > библиотеки в ALT?
> > В /people, а ещё глянь #23871.
> В /people нет желания, туда никто никогда не смотрит.

Ну я бы завтра посмотрел. :)

> #23871 никакого отношения не имеет к моей проблеме.

Некоторое имеет -- оптимизация под i586 в почти любом случае
малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
или в сторону i686 (а-ля PLD).  Если принять второе решение,
твоя проблема решается автоматически.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Igor Zubkov]

27 августа 2010 г. 11:56 пользователь Michael Shigorin написал:
> On Fri, Aug 27, 2010 at 12:12:55PM +0400, Konstantin Pavlov wrote:
>> > > Хотелось бы собрать оптимизированные для >= i686 библиотеки
>> > > ffmpeg с использованием CMOV.  Куда правильно класть такие
>> > > библиотеки в ALT?
>> > В /people, а ещё глянь #23871.
>> В /people нет желания, туда никто никогда не смотрит.
>
> Ну я бы завтра посмотрел. :)
>
>> #23871 никакого отношения не имеет к моей проблеме.
>
> Некоторое имеет -- оптимизация под i586 в почти любом случае
> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
> или в сторону i686 (а-ля PLD).  Если принять второе решение,
> твоя проблема решается автоматически.

Хотел написать что в Fedora 13 используется i686 по умолчанию, но
оказалось что с 12 релиза. Не пора ли догонять?

http://fedoraproject.org/wiki/Features/F12X86Support

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Konstantin Pavlov]

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

On Fri, Aug 27, 2010 at 11:56:06AM +0300, Michael Shigorin wrote:
> > В /people нет желания, туда никто никогда не смотрит.
> 
> Ну я бы завтра посмотрел. :)

http://git.altlinux.org/tasks/28173/build/1/i586/rpms/

> > #23871 никакого отношения не имеет к моей проблеме.
> 
> Некоторое имеет -- оптимизация под i586 в почти любом случае
> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
> или в сторону i686 (а-ля PLD).  Если принять второе решение,
> твоя проблема решается автоматически.

В дебиане, надо сказать, проблема решена иначе.

-- 
<xapienz> овз на ноуте??
<dottedmag> А то, что у меня на ееепце опенвз - это в морг?
<thresh> у тебя скоро на книгочиталке будет опенвз
<thresh> это уже диагноз :)
<dottedmag> А ведь под арм есть.
 * dottedmag ушёл собирать
<thresh> черт, надо usb-клаву покупать
<thresh> и ставить альт на плейстейшен, а то я чето как лох :)

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Fri, Aug 27, 2010 at 12:17:48PM +0300, Igor Zubkov wrote:
> Хотел написать что в Fedora 13 используется i686 по умолчанию, но
> оказалось что с 12 релиза. Не пора ли догонять?
> 
> http://fedoraproject.org/wiki/Features/F12X86Support
Щас набегут аффтары Antique.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> Вот я пользуюсь pine, причём каждый день.
Я вам сочувствую.
Несколько лет назад одного письма "специального вида" мне было достаточно,
чтобы навсегда распрощаться с этим почтовым клиентом.
		-- ldv in devel@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Igor Zubkov]

27 августа 2010 г. 12:25 пользователь Andrey Rahmatullin написал:
> On Fri, Aug 27, 2010 at 12:17:48PM +0300, Igor Zubkov wrote:
>> Хотел написать что в Fedora 13 используется i686 по умолчанию, но
>> оказалось что с 12 релиза. Не пора ли догонять?
>>
>> http://fedoraproject.org/wiki/Features/F12X86Support
> Щас набегут аффтары Antique.

Дело в том что при переходе на i686 будет потеряна поддержка таких процессоров:
Intel i586 (all)
National Semiconductor Geode processors
VIA C3 (Ezra and Samuel Cores)
AMD Geode GX

Вопрос надо ставить так, из-за пары чистых intel i586 мы тормозим
прогресс? Это даже компьютером сейчас сложно назвать. (Оставшиеся три
процессора я в дикой природе просто не встречал.)

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Fri, Aug 27, 2010 at 12:34:11PM +0300, Igor Zubkov wrote:
> > Щас набегут аффтары Antique.
> Дело в том что при переходе на i686 будет потеряна поддержка таких процессоров:
> Intel i586 (all)
Ну вот эти и набегут.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<[nbr|lazy]> страницы без ссылок вполне осмысленны. Они ищутся поиском
 * dottedmag_ws подавляет мысль заказать чучело [nbr|lazy] и сжечь
 * [nbr|lazy] не понравилось очень сильно, что wiki.sisyphus.ru сделали
   подмножеством freesource.info
 * dottedmag_ws вторично подавляет мысль заказать чучело [nbr|lazy] и сжечь

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Michael Shigorin wrote:

> Некоторое имеет -- оптимизация под i586 в почти любом случае
> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
> или в сторону i686 (а-ля PLD). 

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

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Andrey Rahmatullin wrote:

> > Intel i586 (all)

> Ну вот эти и набегут.
 
Я бы на них посмотрел... ;-)

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

PS: Хотя у меня где-то есть K6-II-300. Вот он кто, интересно ?

PPS: не знаю, дома системник где-то по шкафам, или в сарае... :-)

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Aleksey Novodvorsky]

27 августа 2010 г. 13:39 пользователь Sergey Y. Afonin
<asy@altlinux.ru> написал:
> On Friday 27 August 2010, Michael Shigorin wrote:
>
>> Некоторое имеет -- оптимизация под i586 в почти любом случае
>> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
>> или в сторону i686 (а-ля PLD).
>
> А вот в самом деле, остались ли системы с P1, куда можно поставить
> современную систему, чтобы не тормозило ?

Да, остались.
Потому лучше добавить i686 не удаляя пока i586.  Но это для следующего
бранча, сейчас слабо. Там и карманы подоспеют.

Rgrds, Алексей

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Fri, Aug 27, 2010 at 01:42:30PM +0400, Sergey Y. Afonin wrote:
> > > Intel i586 (all)
> > Ну вот эти и набегут.
> Я бы на них посмотрел... ;-)
http://www.altlinux.org/Antique

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<rootest_> xchat стоит... плохой, скажете?
<raorn> гавна кусок
<hiddenman> кто звал меня?
<hiddenman> а, это про xchat

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Michael Shigorin]

On Fri, Aug 27, 2010 at 03:51:48PM +0600, Andrey Rahmatullin wrote:
> > > > Intel i586 (all)

Для именно Pentium может быть осмысленно собирать отдельно.
Вопрос -- в достаточной ли мере (разве что по школам если много
именно первого поколения и в эквиваленте).

> > > Ну вот эти и набегут.
> > Я бы на них посмотрел... ;-)
> http://www.altlinux.org/Antique

Это не про предельно древние агрегаты.  Графический инсталятор
на <64M RAM сейчас приходится впинывать дополнительными rm -rf'ами
в profiles/install2/image-scripts.d, как раз на неделе проверял.

i586 с >=64M RAM видел редко (один такой сам собирал, iP133/96M).

PS: ни у кого живой 486 нет?  Тут бы один патчик проверить... ;)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Fri, Aug 27, 2010 at 01:06:15PM +0300, Michael Shigorin wrote:
> > > > > Intel i586 (all)
> Для именно Pentium может быть осмысленно собирать отдельно.

> > http://www.altlinux.org/Antique
> Это не про предельно древние агрегаты.
Ну на страничке упоминаются P-I.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> [Установил wine, а] вместо шрифтов точки где взять?
А зачем Вам вместо шрифтов точки?
		-- wrar in community@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Andrey Rahmatullin wrote:

> > > > Intel i586 (all)
> > > Ну вот эти и набегут.
> > Я бы на них посмотрел... ;-)

> http://www.altlinux.org/Antique

A - мало что могут - CPU 166-266 мгц, RAM 32-64 мб видео 1-2 мб 
B - что-то могут - CPU 266-533 мгц, RAM 64-128 мб видео 2-4 мб 
C - могут многое - CPU 533-700 мгц, RAM 128-256 мб видео 4-8 мб 
D - могут практически все - CPU 700 мгц и выше, RAM 256-512 мб видео 8 мб и выше 

В "B" - уже low level i686 попадают. Написать тут 300-533, и всё
будет нормально (про K6 забудем пока). :-)

А на "A" закладываться не с чем, хотя aen вон пишет, что есть ещё...

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Vitaly Lipatov]

В сообщении от Пятница 27 августа 2010 Igor Zubkov написал(a):
...
> AMD Geode GX
...
> процессора я в дикой природе просто не встречал.)
А мы их регулярно используем (контроллеры во встраиваиваемых решениях)


-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Motsyo Gennadi aka Drool]

27.08.2010 12:25, Andrey Rahmatullin пишет:
> Щас набегут аффтары Antique.

	А также те, кто все еще использует процессоры класса Р-1 для всяких там
роутеров, внутренних серверочков всякой мелочи и т.п.

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Motsyo Gennadi aka Drool]

27.08.2010 12:39, Sergey Y. Afonin пишет:
> А вот в самом деле, остались ли системы с P1, куда можно поставить
> современную систему, чтобы не тормозило ?

	Да. 5.1 используется на таких машинках.

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Motsyo Gennadi aka Drool wrote:

> > А вот в самом деле, остались ли системы с P1, куда можно
> > поставить современную систему, чтобы не тормозило ?
> 
>         Да. 5.1 используется на таких машинках.
 
С xorg ? Или это не рабочие станции по задачам ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Motsyo Gennadi aka Drool wrote:

>    А также те, кто все еще использует процессоры класса Р-1 для
> всяких там роутеров, внутренних серверочков всякой мелочи и т.п.

Они, по идее, должны бы уже из строя повыходить...

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Sergey Y. Afonin]

On Friday 27 August 2010, Vitaly Lipatov wrote:

> > AMD Geode GX
> ...
> > процессора я в дикой природе просто не встречал.)

> А мы их регулярно используем (контроллеры во встраиваиваемых решениях)

Тогда вопрос. А сложно ли сделать сокращённый репозитарий ? Именно
из расчёта на контроллеры ? Тогда для i586 можно оставить собираться
только то, что действительно необходимо. И какой-то список вести,
что надо...

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Motsyo Gennadi aka Drool]

27.08.2010 15:25, Sergey Y. Afonin пишет:
>>         Да. 5.1 используется на таких машинках.
>  
> С xorg ? Или это не рабочие станции по задачам ?

	Нет, графика там отсутствует.

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Motsyo Gennadi aka Drool]

27.08.2010 15:27, Sergey Y. Afonin пишет:
>>    А также те, кто все еще использует процессоры класса Р-1 для
>> всяких там роутеров, внутренних серверочков всякой мелочи и т.п.
> 
> Они, по идее, должны бы уже из строя повыходить...

	Ага, щяз. Они переживут все нынешние машины - там не было таких нежных
конденсаторов, зачастую даже охлаждение пассивное, винты по 1-2 гига
пашут годами в аптайме без ИБП, т.к. плотность записи там несравнима с
нынешними винтами. Всякие IBM PC250-300, SiemensNixdorf и Compaq - мои
любимые модели для изготовления роутеров и шлюзов. Проверено временем.

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Vitaly Lipatov]

В сообщении от Пятница 27 августа 2010 Sergey Y. Afonin написал(a):
> On Friday 27 August 2010, Vitaly Lipatov wrote:
> > > AMD Geode GX
...
> > А мы их регулярно используем (контроллеры во встраиваиваемых решениях)
> 
> Тогда вопрос. А сложно ли сделать сокращённый репозитарий ? Именно
> из расчёта на контроллеры ? Тогда для i586 можно оставить собираться
> только то, что действительно необходимо. И какой-то список вести,
> что надо...
Я-то считаю, что вообще надо перейти на x86_64 повсеместно, и забыть уже о 
i586 и производительности на нём. Поэтому я перестал напрягаться по поводу 
сборок под i686 — вроде давно уже все процессоры умеют x86_64.

Мы за i586 для контроллеров не держимся. Надо будет — сделаем сокращённый 
репозиторий, это не так сложно. Хотя эта задача близка к сборке на ARM — стоит 
решить (признать), что под некоторые архитектуры много что не нужно собирать.

Я бы это делал путём введения в спек явного указания, что данных пакет надо 
собрать ещё и под одну из неосновных архитектур (i586 или ARM). Собирая при 
этом все пакеты по умолчанию под i686/x86_64.

-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Денис Смирнов]

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

On Fri, Aug 27, 2010 at 07:07:17PM +0400, Vitaly Lipatov wrote:

VL> Я-то считаю, что вообще надо перейти на x86_64 повсеместно, и забыть уже о 
VL> i586 и производительности на нём. 

Неттопы, нетбуки... :(
Забыть -- не получится. А вот идея собирать подмножество репозитория под
i586 мне нравится.

Но одна глобальная проблема остается. x86_64 -- понятие очень растяжимое.

Например какая разновидность SSE поддерживается? Или вот тут новомодное
аппаратное ускорение AES появилось. 

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Sat, Aug 28, 2010 at 04:18:59AM +0400, Денис Смирнов wrote:
> Но одна глобальная проблема остается. x86_64 -- понятие очень растяжимое.
> 
> Например какая разновидность SSE поддерживается? 
2

> Или вот тут новомодное аппаратное ускорение AES появилось. 
Ну это всё же лучше, чем без MMX собирать.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

>> заменить предлог "по" (цепляет меня корявостью ;)
> Вообще, еще часто используют "под"
Под... над...  Давайте без этой камасутры? :)
		-- avp in docs@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Денис Смирнов]

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

On Sat, Aug 28, 2010 at 01:26:30PM +0600, Andrey Rahmatullin wrote:

>> Например какая разновидность SSE поддерживается? 
AR> 2

вот-вот..

>> Или вот тут новомодное аппаратное ускорение AES появилось. 
AR> Ну это всё же лучше, чем без MMX собирать.

Разумеется. 

Итак, если по применениям, то:

1. нормальные современные машинки -- это поголовно x86_64, и когда наконец
кто-нибудь соберет nspluginwrapper, с учетом действующего arepo
практически никаких причин использовать на них i586/i686 не будет. А на
серверах смысла в i586/i686 уже нет никакого.

2. старье для терминалок (да и про школы не забываем) -- ему может быть
надо i586 (?)

3. офисное барахло -- i586/i686. Смысла особо что-то оптимизировать нет.

4. нетбуки. i686, и оптмизировать под них _надо.

Вывод: для последних двух подход федоры (i686, --mtune=atom) самый
разумный. О первом особо заботиться нет смысла.

Что делать со вторым? Если забить -- то можно просто сделать также как в
федоре. Если не забивать -- то либо оставляем как есть (и владельцы
нетбуков будут в проигрыше), либо собирать и под i586 и под i686.

Гм. Может для старья оставить p5, а в Сизифе пойти по тому же пути что
Федора?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------


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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Andrey Rahmatullin]

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

On Sat, Aug 28, 2010 at 12:01:59PM +0400, Денис Смирнов wrote:
> Гм. Может для старья оставить p5
Вот именно.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> Естественно Master'ом это называть нельзя.
Master'ом можно назвать что угодно, было бы желание.
		-- ldv in devel@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Michael Shigorin]

On Sat, Aug 28, 2010 at 12:01:59PM +0400, Денис Смирнов wrote:
> Гм. Может для старья оставить p5, а в Сизифе пойти по тому же
> пути что Федора?

Можно и так, а сбоку после отбранчёвывания наладить подмножество
хоть под i486 для уже озвученных специальных случаев.  Всё равно
опенофисы с мозиллами и kde с gnome там не нужны.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Aleksey Novodvorsky]

28 августа 2010 г. 12:01 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Sat, Aug 28, 2010 at 01:26:30PM +0600, Andrey Rahmatullin wrote:
>
>>> Например какая разновидность SSE поддерживается?
> AR> 2
>
> вот-вот..
>
>>> Или вот тут новомодное аппаратное ускорение AES появилось.
> AR> Ну это всё же лучше, чем без MMX собирать.
>
> Разумеется.
>
> Итак, если по применениям, то:
>
> 1. нормальные современные машинки -- это поголовно x86_64, и когда наконец
> кто-нибудь соберет nspluginwrapper, с учетом действующего arepo
> практически никаких причин использовать на них i586/i686 не будет. А на
> серверах смысла в i586/i686 уже нет никакого.
>
> 2. старье для терминалок (да и про школы не забываем) -- ему может быть
> надо i586 (?)
>
> 3. офисное барахло -- i586/i686. Смысла особо что-то оптимизировать нет.
>
> 4. нетбуки. i686, и оптмизировать под них _надо.
>
> Вывод: для последних двух подход федоры (i686, --mtune=atom) самый
> разумный. О первом особо заботиться нет смысла.
>
> Что делать со вторым? Если забить -- то можно просто сделать также как в
> федоре. Если не забивать -- то либо оставляем как есть (и владельцы
> нетбуков будут в проигрыше), либо собирать и под i586 и под i686.
>
> Гм. Может для старья оставить p5, а в Сизифе пойти по тому же пути что
> Федора?

Тогда уж p6, так как до бранчевания вряд ли стоит делать резкие
телодвижения в эту сторону.
Решение зависит от ресурсов и, полагаю, от реализации карманов. Работа
по обоим направлениям идет, но делать прогнозы по времени я не буду,
обжигался неоднократно.
С Софтулом это все никак не связано.
Что касается второго пункта, то он  пока реально востребован теми, кто
проводит внедрения в школах и муниципалитетах, не считая любителей
ретро. И там наработаны свои оригинальные технологии. Думаю, что около
года они будут не только использоваться, но и развиваться. Над думать
о миграции наработанных решений на современные легкие системы, типа
Atom и ARM, чтобы похоронить эту ветку старья достойно ее славному
прошлому.
Вообще, все никак не удается составить список имеющихся и
разрабатываемых участниками тим решений. Понятно, что среди них есть
"секретные", но не все же. Это позволило бы понимать хотелки друг
друга и сопоставлять их с действиями.
Rgrds, Алексей

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Денис Смирнов]

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

On Sat, Aug 28, 2010 at 03:40:15PM +0400, Aleksey Novodvorsky wrote:

AN> Тогда уж p6, так как до бранчевания вряд ли стоит делать резкие
AN> телодвижения в эту сторону.

Это, как я понимаю, вопрос не технический. Пересобрать весь репозиторий
под i686 роботы смогут весьма шустро и успешно. Если выбирать вариант
"добавить архитектуру", то я так понимаю это <= 1 часа работы ldv@ или at@
запустить всю эту машинерию.

Выбор "добавить архитектуру" или "заменять i586 -> i686" -- уже финансовый
(ресурсы сборочницы).

Выбор "если заменять то когда" -- зависит исключительно от
позиционирования. Т.е. нужен ли нам p6 на терминала.

При этом делать как раз _такое_ изменение сразу после выхода p6, означает
сразу похоронить p6 как LTS с десктопной стороны.

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

А карманы тут причем? Они помогут только делать оптимизированное
подмножество (скажем mplayer+ffmpeg собирать под десяток разных
процессоров оптимизируя до упора).

AN> Что касается второго пункта, то он  пока реально востребован теми, кто
AN> проводит внедрения в школах и муниципалитетах, не считая любителей
AN> ретро. И там наработаны свои оригинальные технологии. Думаю, что около
AN> года они будут не только использоваться, но и развиваться. Над думать
AN> о миграции наработанных решений на современные легкие системы, типа
AN> Atom и ARM, чтобы похоронить эту ветку старья достойно ее славному
AN> прошлому.

Так нам нужна поддержка старья в LTS p6?

AN> Вообще, все никак не удается составить список имеющихся и
AN> разрабатываемых участниками тим решений. Понятно, что среди них есть
AN> "секретные", но не все же. Это позволило бы понимать хотелки друг
AN> друга и сопоставлять их с действиями.

У меня сейчас в планах очередное перепахивание околоастерисковского
хозяйства. И мне бы хотелось успеть до форка p6. Когда он?

К сожалению, видимо, придется в p6 класть бету астериска 1.8, ибо это
следующая LTS ветка астериска, а нынешний 1.6.2 скоро загнется.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] альтернативные архитектуры семейства x86

[Dmitry V. Levin]

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

On Sat, Aug 28, 2010 at 03:40:15PM +0400, Aleksey Novodvorsky wrote:
> 28 августа 2010 г. 12:01 пользователь Денис Смирнов написал:
[...]
> > Гм. Может для старья оставить p5, а в Сизифе пойти по тому же пути что
> > Федора?
> 
> Тогда уж p6, так как до бранчевания вряд ли стоит делать резкие
> телодвижения в эту сторону.
> Решение зависит от ресурсов и, полагаю, от реализации карманов.

Решение зависит от
- спроса (я так и не понял, кому чего надо в этом направлении);
- пересобираемости Сизифа (чтобы забутстрапить новую архитектуру, нужно
  собрать все arch-пакеты под эту архитектуру);
- ресурсов (чтобы забутстрапить новую архитектуру, и чтобы потом
  собирать задания под эту архитектуру);
- незначительных изменений в girar-builder (чтобы сделать список
  поддерживаемых архитектур конфигурируемым).

Я не вижу никакой зависимости от реализации персональных репозиториев.

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


-- 
ldv

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Anton Farygin]

27.08.2010 13:39, Sergey Y. Afonin пишет:
> On Friday 27 August 2010, Michael Shigorin wrote:
>
>> Некоторое имеет -- оптимизация под i586 в почти любом случае
>> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
>> или в сторону i686 (а-ля PLD).
>
> А вот в самом деле, остались ли системы с P1, куда можно поставить
> современную систему, чтобы не тормозило ? Что-то я боюсь, что даже
> с PII ничего хорошего не получится, хотя их есть у меня, и, даже,
> с 5.1... Но это уже, как раз, i686.

У меня PII (Celeron 600) не тормозит, работает (Gnome, Sisyphus).

Re: [devel] альтернативные архитектуры семейства x86

[Alexey I. Froloff]

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

On Sat, Aug 28, 2010 at 04:17:51PM +0400, Dmitry V. Levin wrote:
> Но, главное, надо просуммировать хотелки в такой форме, чтобы стало
> понятно, как выглядит спрос.
Ещё не надо забывать про:

$ grep -Fh i586 /space/ALT/Sisyphus/*/base/contents_index | cut -f2 | sort -u | wc -l
271

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

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

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Timur Batyrshin]

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

On Fri, 27 Aug 2010 15:35:46 +0300
Motsyo Gennadi aka Drool wrote:

> >>    А также те, кто все еще использует процессоры класса Р-1 для
> >> всяких там роутеров, внутренних серверочков всякой мелочи и т.п.
> > 
> > Они, по идее, должны бы уже из строя повыходить...
> 
> 	Ага, щяз. Они переживут все нынешние машины - там не было
> таких нежных конденсаторов, зачастую даже охлаждение пассивное, винты
> по 1-2 гига пашут годами в аптайме без ИБП, т.к. плотность записи там
> несравнима с нынешними винтами. Всякие IBM PC250-300, SiemensNixdorf
> и Compaq - мои любимые модели для изготовления роутеров и шлюзов.
> Проверено временем.

А блоки питания как выдерживают?
Они обычно первыми дохнут (не считая винтов).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] [JT] Оптимизированные для i686 и выше библиотеки

[Motsyo Gennadi aka Drool]

31.08.2010 09:43, Timur Batyrshin пишет:
> А блоки питания как выдерживают?
> Они обычно первыми дохнут (не считая винтов).

	3 года аптайма Compaq P1-166 Мгц, 64 ЗУ, 3 гб винта - роутер +
внутренний чатик в локальной сети организации на 30 машин, работает без
ИБП, настроен на автоматический старт после появления элекричества.
Siemens-Nixdorf Р1-233, 128 ОЗУ, винт на 1,5 гб, аптайм порядка 3,5 лет,
функции аналогичные, также без ИБП.
	Да, раньше умели делать на совесть.

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Alexey Tourbin]

On Fri, Aug 27, 2010 at 01:46:35PM +0400, Aleksey Novodvorsky wrote:
> 27 августа 2010 г. 13:39 пользователь Sergey Y. Afonin
> <asy@altlinux.ru> написал:
> > On Friday 27 August 2010, Michael Shigorin wrote:
> >
> >> Некоторое имеет -- оптимизация под i586 в почти любом случае
> >> малоосмысленна.  Её бы сдвинуть или в сторону i486 (Debian/RH),
> >> или в сторону i686 (а-ля PLD).
> >
> > А вот в самом деле, остались ли системы с P1, куда можно поставить
> > современную систему, чтобы не тормозило ?
> 
> Да, остались.
> Потому лучше добавить i686 не удаляя пока i586.  Но это для следующего
> бранча, сейчас слабо. Там и карманы подоспеют.

That's not at all a matter of "branch" or "pockets".  Believe me or not,
you can simply place libraries under /lib/i686 or /lib/sse2, and they'll
be picked up automatically (as needed).  Building glibc this way would
address 90% of the issue.

Also, I believe that speculations about i586 (vs i686 vs sse2-capable
CPUs) are greatly exaggerated.  Usually there is something like 2%
a difference.

> Rgrds, Алексей

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Michael Shigorin]

On Wed, Sep 01, 2010 at 03:25:52AM +0400, Alexey Tourbin wrote:
> Also, I believe that speculations about i586 (vs i686 vs
> sse2-capable CPUs) are greatly exaggerated.  Usually there is
> something like 2% a difference.

glibc почитай, что ли.  Ссылка в #23871.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки

[Alexey Tourbin]

On Wed, Sep 01, 2010 at 02:30:16AM +0300, Michael Shigorin wrote:
> On Wed, Sep 01, 2010 at 03:25:52AM +0400, Alexey Tourbin wrote:
> > Also, I believe that speculations about i586 (vs i686 vs
> > sse2-capable CPUs) are greatly exaggerated.  Usually there is
> > something like 2% a difference.
> 
> glibc почитай, что ли.  Ссылка в #23871.

I think I've seen this.  What's your point?  Was it 10% a difference?
Did you measure?

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Aug 27, 2010 at 11:52:30AM +0400, Konstantin Pavlov wrote:
> Хотелось бы собрать оптимизированные для >= i686 библиотеки ffmpeg с
> использованием CMOV.

Too late a question, but anyway, what do you expect?  Was it,
like, 10% faster?  Did you measure?  Ain't you just ... around?

> Куда правильно класть такие библиотеки в ALT?

/usr/lib/sse2 is a nice place (probably not only in ALT).
But you should think twice before you do a thing.

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Денис Смирнов]

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

On Wed, Sep 01, 2010 at 04:27:23AM +0400, Алексей Турбин wrote:

AT> Too late a question, but anyway, what do you expect?  Was it,
AT> like, 10% faster?  Did you measure?  Ain't you just ... around?

Hint1: H.264
Hint2: высокое разрешение

В таких случаях 1% уже решает -- можно ли на этом компьютере посмотреть
фильм, или нет.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Wed, Sep 01, 2010 at 05:13:41AM +0400, Денис Смирнов wrote:
> On Wed, Sep 01, 2010 at 04:27:23AM +0400, Алексей Турбин wrote:
> 
> AT> Too late a question, but anyway, what do you expect?  Was it,
> AT> like, 10% faster?  Did you measure?  Ain't you just ... around?
> 
> Hint1: H.264
> Hint2: высокое разрешение
> 
> В таких случаях 1% уже решает -- можно ли на этом компьютере посмотреть
> фильм, или нет.

You miss the point.  I ask them: do you have numbers?  The answer is,
basically, no, no numbers.  Is there, say, a 10% improvement which might
make a difference?  The answer is, like, hey, guy, we're just, like,
talking about optimization.  An optimized code is better than a
non-optimized one, you see?  You gotta optimize your code!

I'm not trying to say that 1 percent is not worthwhile (which is probably
not, though).  What I'm curious about is why you tend to support stupid
ideas.  Like, no numbers, but we feel you're one of us, aren't you?

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

On Wed, Sep 01, 2010 at 04:27:23AM +0400, Alexey Tourbin wrote:
> On Fri, Aug 27, 2010 at 11:52:30AM +0400, Konstantin Pavlov wrote:
> > Хотелось бы собрать оптимизированные для >= i686 библиотеки ffmpeg с
> > использованием CMOV.
> 
> Too late a question, but anyway, what do you expect?  Was it,
> like, 10% faster?  Did you measure?  Ain't you just ... around?

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

> > Куда правильно класть такие библиотеки в ALT?
> 
> /usr/lib/sse2 is a nice place (probably not only in ALT).
> But you should think twice before you do a thing.

Например?

-- 
[rider@linux rider]$ uptime
  3:27pm  up 313 days, 23:57,  4 users,  load average: 10.19, 8.59, 7.52
		-- rider in devel@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

On Wed, Sep 01, 2010 at 06:05:18AM +0400, Alexey Tourbin wrote:
> On Wed, Sep 01, 2010 at 05:13:41AM +0400, Денис Смирнов wrote:
> > On Wed, Sep 01, 2010 at 04:27:23AM +0400, Алексей Турбин wrote:
> > 
> > AT> Too late a question, but anyway, what do you expect?  Was it,
> > AT> like, 10% faster?  Did you measure?  Ain't you just ... around?
> > 
> > Hint1: H.264
> > Hint2: высокое разрешение
> > 
> > В таких случаях 1% уже решает -- можно ли на этом компьютере посмотреть
> > фильм, или нет.
> 
> You miss the point.  I ask them: do you have numbers?  The answer is,
> basically, no, no numbers.

> I'm not trying to say that 1 percent is not worthwhile (which is probably
> not, though).  What I'm curious about is why you tend to support stupid
> ideas.  Like, no numbers, but we feel you're one of us, aren't you?

Пожалуйста, не пишите того, чего не знаете или не удосужились подождать.

Вы, like, бакланопоцтитом болеете.

http://www.altlinux.org/FFmpeg#.D0.91.D0.B5.D0.BD.D1.87.D0.BC.D0.B0.D1.80.D0.BA_.D1.81_CMOV

-- 
> Похоже, обновление rpm не проходит.
Похоже, что у вас apt слишком старый, раз он rpm запускает.
Похоже, что у вас /bin/rpm статически собранный, раз он падает.
Похоже, что у вас rpm слишком старый, поскольку /bin/rpm собран
статически.

Вывод: похоже, что вам не стоит обновлять такую систему без промежуточного
репозитария.
		-- ldv in sisyphus@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Wed, Sep 01, 2010 at 11:38:06AM +0400, Konstantin Pavlov wrote:
> > I'm not trying to say that 1 percent is not worthwhile (which is probably
> > not, though).  What I'm curious about is why you tend to support stupid
> > ideas.  Like, no numbers, but we feel you're one of us, aren't you?
> 
> Пожалуйста, не пишите того, чего не знаете или не удосужились подождать.
> Вы, like, бакланопоцтитом болеете.
> http://www.altlinux.org/FFmpeg#.D0.91.D0.B5.D0.BD.D1.87.D0.BC.D0.B0.D1.80.D0.BA_.D1.81_CMOV

So it seems that you get, at best, something like one percent.
Which is merely better that nothing.

Um, there's a famous Linus' rant about CMOV out there, and he says that,
quote, CMOV is a piece of CRAP, unquote.
http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
You know, like, that CMOV, CRAP things.  Are you still comfortable with
four-letter words?

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

On Thu, Sep 02, 2010 at 09:06:07PM +0400, Alexey Tourbin wrote:
> On Wed, Sep 01, 2010 at 11:38:06AM +0400, Konstantin Pavlov wrote:
> > > I'm not trying to say that 1 percent is not worthwhile (which is probably
> > > not, though).  What I'm curious about is why you tend to support stupid
> > > ideas.  Like, no numbers, but we feel you're one of us, aren't you?
> > 
> > Пожалуйста, не пишите того, чего не знаете или не удосужились подождать.
> > Вы, like, бакланопоцтитом болеете.
> > http://www.altlinux.org/FFmpeg#.D0.91.D0.B5.D0.BD.D1.87.D0.BC.D0.B0.D1.80.D0.BA_.D1.81_CMOV
> 
> So it seems that you get, at best, something like one percent.
> Which is merely better that nothing.
> 
> Um, there's a famous Linus' rant about CMOV out there, and he says that,
> quote, CMOV is a piece of CRAP, unquote.
> http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
> You know, like, that CMOV, CRAP things.  Are you still comfortable with
> four-letter words?

Алексей, возможно, для перекодирования порнограмм с Натали Портман один
процент ускорения и несущественнен.

В моем случае это немного не так. И да, это письмо Тороволтоса я читал.

-- 
Если человек работает в консоли, значит у него в голове
определенно что-нибудь да есть.
		-- zerg in sisyphus@

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Thu, Sep 02, 2010 at 10:00:28PM +0400, Konstantin Pavlov wrote:
> > > Пожалуйста, не пишите того, чего не знаете или не удосужились подождать.
> > > Вы, like, бакланопоцтитом болеете.
> > > http://www.altlinux.org/FFmpeg#.D0.91.D0.B5.D0.BD.D1.87.D0.BC.D0.B0.D1.80.D0.BA_.D1.81_CMOV
> > 
> > So it seems that you get, at best, something like one percent.
> > Which is merely better that nothing.
> > 
> > Um, there's a famous Linus' rant about CMOV out there, and he says that,
> > quote, CMOV is a piece of CRAP, unquote.
> > http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
> > You know, like, that CMOV, CRAP things.  Are you still comfortable with
> > four-letter words?
> 
> Алексей, возможно, для перекодирования порнограмм с Натали Портман один
> процент ускорения и несущественнен.

That Natalie Porman thing worked well.  Quite better than I desired.
I've never expected this.  But anyway, I digress.  Hey, was it really
even a single percent?  Didn't you, like, cheat?  Assuming that you
didn't, have you ever heard of confidence intervals or beta-errors?

> В моем случае это немного не так. И да, это письмо Тороволтоса я читал.

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Konstantin Pavlov]

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

On Fri, Sep 03, 2010 at 12:07:31AM +0400, Alexey Tourbin wrote:
> Hey, was it really even a single percent?  Didn't you, like, cheat?
> Assuming that you didn't, have you ever heard of confidence intervals or
> beta-errors?

Результаты я получил не одним измерением и они статистически значимы.

-- 
 * swi боязливо огляделся по сторонам и тихонько просунул в приоткрытый
   инкаминг PyFortunes
<gns> и тут же налетел омон с автоматами, swi положили лицом на землю,
      обшмонали, под запись вытащили PyFortunes из инкоминга
<gns> swi: ну все чувак, знаешь что тебе за этот пакетик светит?
<gns> swi: "кому ты передавал? кто его должен был забрать?"
 * gns . o 0 (на всегда носить с собой подписанное gpg заявление с текущей
   датой: проходя мимо orphaned, увидел на земле пакет. поднял чтобы сдать в
   милицию)

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

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 12:16:49AM +0400, Konstantin Pavlov wrote:
> On Fri, Sep 03, 2010 at 12:07:31AM +0400, Alexey Tourbin wrote:
> > Hey, was it really even a single percent?  Didn't you, like, cheat?
> > Assuming that you didn't, have you ever heard of confidence intervals or
> > beta-errors?
> Результаты я получил не одним измерением и они статистически значимы.

There are major pitfalls.  Statistics is hard.  For example, you might
remember, recently I posted "quick survey" of hash functions.  My point
was that djb performed a bit better than jenkins.  I've made another
attempt just recently.  You know what.  Jenkins handle sparse sets a lot
better than djb.  It's only about very dense sets that djb might be a bit
advantageous.

So, things might grow complicated, really.  Of course, that's not your
fault.  And I'm not trying to make them complicated, either.  That's
just what things really are.-(

Anyway, when someone tells you he's got one percent an improvement.
The right thing to do is to ask, are you a major in statistical physics?

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Wed, Sep 01, 2010 at 11:36:02AM +0400, Konstantin Pavlov wrote:
> On Wed, Sep 01, 2010 at 04:27:23AM +0400, Alexey Tourbin wrote:
> > On Fri, Aug 27, 2010 at 11:52:30AM +0400, Konstantin Pavlov wrote:
> > > Хотелось бы собрать оптимизированные для >= i686 библиотеки ffmpeg с
> > > использованием CMOV.
> > 
> > Too late a question, but anyway, what do you expect?  Was it,
> > like, 10% faster?  Did you measure?  Ain't you just ... around?
> 
> На тех машинах, где мне довелось проверить, прирост производительности
> составил порядка 1%.  В моём случае любой прирост производительности
> важен.

Вам очень сложно будет защищать прирост производительности в 1%.
Этот процент ведь даже довольно сложно измерить, с точки зрения теории.

> > > Куда правильно класть такие библиотеки в ALT?
> > 
> > /usr/lib/sse2 is a nice place (probably not only in ALT).
> > But you should think twice before you do a thing.
> 
> Например?

Я хотел сказать, что не стоит этого делать (хотя такая возможность
заложена).  Есть там этот hwcap, линкер может диспетчеризировать
по hwcap.  Но сколько там процентов накапает?  Опять один процент?
Будете смешить образованных людей?

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[REAL]

Michael Shigorin пишет:
> (и да, из-за этого хотелось бы втащить в gcc ручку насчёт
> возможности отварить приваренный FORTIFY_SOURCE)

А -U_FORTIFY_SOURCE не помогает?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Michael Shigorin]

On Fri, Sep 03, 2010 at 01:33:37AM +0400, Alexey Tourbin wrote:
> Но сколько там процентов накапает?  Опять один процент?

Жалко, что ли?  На кластере вон и полпроцента немало стоят.
(и да, из-за этого хотелось бы втащить в gcc ручку насчёт
возможности отварить приваренный FORTIFY_SOURCE)

> Будете смешить образованных людей?

Ярким примером чесания в затылке образованным человеком было
письмо Solar Designer в bugtraq@ со словами "oops, а про чрут
в чруте я и не подумал".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 06:30:34AM +0300, Michael Shigorin wrote:
> On Fri, Sep 03, 2010 at 01:33:37AM +0400, Alexey Tourbin wrote:
> > Но сколько там процентов накапает?  Опять один процент?
> 
> Жалко, что ли?  На кластере вон и полпроцента немало стоят.

С такими величинами возникют вопросы по части статистики, типа
действительно там набежало один процент.  Потому что но вот понимаешь,
у тебя сейчас например выдает +1%.  Но это не значит, что оно
действительно работает быстрее.  Просто цифры немного отличаются.
В определенном интервале нельзя сделать вывод, что это действительно
быстрее.  На других данных и на другом CPU у тебя уже покажет -1%.

Потом ещё обычно оптимизация "для бедных" тестируется на богатых
процессорах.  Но смысл тестировать cmov на c2d?  Замерять?
Там уже всё другое, микроархиектура другая.

На этом умные люди собаку съели.  Кирилл k001 как-то писал (когда
пытался измерить разницу в производительности порядка одного процента),
что это зависит на самом деле от того как вентилятор крутится.

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Led]

On Friday 03 September 2010 14:20:30 Alexey Tourbin wrote:
> On Fri, Sep 03, 2010 at 06:30:34AM +0300, Michael Shigorin wrote:
> > On Fri, Sep 03, 2010 at 01:33:37AM +0400, Alexey Tourbin wrote:
> > > Но сколько там процентов накапает?  Опять один процент?
> >
> > Жалко, что ли?  На кластере вон и полпроцента немало стоят.
>
> С такими величинами возникют вопросы по части статистики, типа
> действительно там набежало один процент.  Потому что но вот понимаешь,
> у тебя сейчас например выдает +1%.  Но это не значит, что оно
> действительно работает быстрее.  Просто цифры немного отличаются.
> В определенном интервале нельзя сделать вывод, что это действительно
> быстрее.  На других данных и на другом CPU у тебя уже покажет -1%.
>
> Потом ещё обычно оптимизация "для бедных" тестируется на богатых
> процессорах.  Но смысл тестировать cmov на c2d?  Замерять?
> Там уже всё другое, микроархиектура другая.

Потестируйте на атомах (практически, единственная "живая" на сегодня не-x86_64 
x86 архитектура), которые НЕ-out-of-order, а самые что ни на есть тупые 
in-order, в которых даже добавление -mtune-i686 к -march=core2 даёт 
существенный прирост, ощётимый даже "на глаз" к производительности

P.S. Давайте сначала похваем устриц (а не вспоминать ощущение тех, кто хавал 
их несколько лет назад), прежде чем что-то утверждать, ок?


-- 
Led

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 03:49:30PM +0300, Led wrote:
> > С такими величинами возникют вопросы по части статистики, типа
> > действительно там набежало один процент.  Потому что но вот понимаешь,
> > у тебя сейчас например выдает +1%.  Но это не значит, что оно
> > действительно работает быстрее.  Просто цифры немного отличаются.
> > В определенном интервале нельзя сделать вывод, что это действительно
> > быстрее.  На других данных и на другом CPU у тебя уже покажет -1%.
> >
> > Потом ещё обычно оптимизация "для бедных" тестируется на богатых
> > процессорах.  Но смысл тестировать cmov на c2d?  Замерять?
> > Там уже всё другое, микроархиектура другая.
> 
> Потестируйте на атомах (практически, единственная "живая" на сегодня не-x86_64 
> x86 архитектура), которые НЕ-out-of-order, а самые что ни на есть тупые 
> in-order, в которых даже добавление -mtune-i686 к -march=core2 даёт 
> существенный прирост, ощётимый даже "на глаз" к производительности

Существенный прирост.  Это сколько примерно? )
Кстати на атомах cmov дает меньше всего.
http://www.altlinux.org/FFmpeg

> P.S. Давайте сначала похваем устриц (а не вспоминать ощущение тех, кто хавал 
> их несколько лет назад), прежде чем что-то утверждать, ок?

Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели
тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это
на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей,
сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает
"тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там
выходит около одного процента в лучше случае (а на атомах - меньше).
Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет смысла.

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Led]

On Friday 03 September 2010 20:03:29 Alexey Tourbin wrote:
> On Fri, Sep 03, 2010 at 03:49:30PM +0300, Led wrote:
> > > С такими величинами возникют вопросы по части статистики, типа
> > > действительно там набежало один процент.  Потому что но вот понимаешь,
> > > у тебя сейчас например выдает +1%.  Но это не значит, что оно
> > > действительно работает быстрее.  Просто цифры немного отличаются.
> > > В определенном интервале нельзя сделать вывод, что это действительно
> > > быстрее.  На других данных и на другом CPU у тебя уже покажет -1%.
> > >
> > > Потом ещё обычно оптимизация "для бедных" тестируется на богатых
> > > процессорах.  Но смысл тестировать cmov на c2d?  Замерять?
> > > Там уже всё другое, микроархиектура другая.
> >
> > Потестируйте на атомах (практически, единственная "живая" на сегодня
> > не-x86_64 x86 архитектура), которые НЕ-out-of-order, а самые что ни на
> > есть тупые in-order, в которых даже добавление -mtune-i686 к -march=core2
> > даёт существенный прирост, ощётимый даже "на глаз" к производительности
>
> Существенный прирост.  Это сколько примерно? )
> Кстати на атомах cmov дает меньше всего.
> http://www.altlinux.org/FFmpeg

Я говорил о том, что Atom - in-order, поэтому древнее письмо Линуса про 
ненужность CMOV на out-of-order процессоре к атому отношения не имеет. А 
также про то, что прирост даёт "-march=core2 -mtune=i686" по сравнению с 
просто "-march=core2" - как следствие in-order

>
> > P.S. Давайте сначала похваем устриц (а не вспоминать ощущение тех, кто
> > хавал их несколько лет назад), прежде чем что-то утверждать, ок?
>
> Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели
> тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это
> на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей,
> сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает
> "тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там
> выходит около одного процента в лучше случае (а на атомах - меньше).

По указанной ссылке вообще трудно делать оценку: не указаны флаги компиляции - 
не понятно что значит "скомпилировано с CMOV - скомпилировано без CMOV". Да и 
FFmpeg очень сильно оптимизирован "вручную", асм-кодом и SIMD'ами, чтоб это 
было показателем. Если бы я проверял, то, наверное, ипользовал бы разные 
сборки xvid (с --disable-assembly).

> Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет
> смысла. 

-- 
Led

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 06:30:34AM +0300, Michael Shigorin wrote:
> > Будете смешить образованных людей?
> 
> Ярким примером чесания в затылке образованным человеком было
> письмо Solar Designer в bugtraq@ со словами "oops, а про чрут
> в чруте я и не подумал".

Can't you be please be more specific and concrete?  And provide a link?
I've never heard of this story, I'm telling you.  It's intriguing. )

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexander Bokovoy]

2010/9/3 Alexey Tourbin <at@altlinux.ru>:
> Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели
> тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это
> на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей,
> сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает
> "тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там
> выходит около одного процента в лучше случае (а на атомах - меньше).
> Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет смысла.
В MeeGo долго энтузиасты пытались убедить товарищей из Интела, что
нужно поддерживать что-нибудь, не поддерживающее SSSE3 (ниже
Core2Duo). Интел, понятное дело, гнет свою палку. Phoronix в мае делал
сравнение четырех дистрибутивов на нетбуке, для меня единственным
значимым различием было почти четырехкратное ускорение загрузки
дистрибутива по сравнению с Fedora 13 (8 секунд против 23), но это
скорее заслуга btrf и меньшего количества сервисов, чем аппаратного
ускорения. Сравнение делалось на одном и том же нетбуке.
http://www.phoronix.com/scan.php?page=article&item=meego_10_perf&num=1

Однако тут важным моментом будет наличие грамотно векторизующего
компилятора. Интеловский компилятор в среднем позволяет отбить 13-15%
при соблюдении ряда специальных манипуляций с кодом (прагмы и проч.),
вырастая и в два-три раза при удачных случаях. Но некоторые из этих
оптимизаций были добавлены только в GCC 4.5 и все равно они уступают
интеловскому компилятору. А ручной оптимизации уступает все подряд.

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

Сегодня коллега ускорил в три с половиной раза собственный код:
http://maemo.gitorious.org/meego-image-editor/libquill/commit/aba7db8a8fcb8474d9107dcd9e142f18d07b51bf,
как можно увидеть, никакими аппаратными оптимизациями там и не пахнет.
Это при том, что и так чтение thumbnail было в рамках приличия.

Практика показывает, что верить в "у нас тут код вручную оптимизирован
под SSE" на x86 микроархитектурах становится крайне неблагодарным
занятием. Микроархитектуры плывут по поддерживаемому функционалу и
особенности их реализации иногда убивают все прошлые оптимизационные
заслуги.

-- 
/ Alexander Bokovoy

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 08:24:31PM +0300, Alexander Bokovoy wrote:
> 2010/9/3 Alexey Tourbin <at@altlinux.ru>:
> > Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели
> > тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это
> > на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей,
> > сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает
> > "тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там
> > выходит около одного процента в лучше случае (а на атомах - меньше).
> > Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет смысла.
> В MeeGo долго энтузиасты пытались убедить товарищей из Интела, что
> нужно поддерживать что-нибудь, не поддерживающее SSSE3 (ниже
> Core2Duo). Интел, понятное дело, гнет свою палку. Phoronix в мае делал
> сравнение четырех дистрибутивов на нетбуке, для меня единственным
> значимым различием было почти четырехкратное ускорение загрузки
> дистрибутива по сравнению с Fedora 13 (8 секунд против 23), но это

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

> скорее заслуга btrf и меньшего количества сервисов, чем аппаратного
> ускорения. Сравнение делалось на одном и том же нетбуке.
> http://www.phoronix.com/scan.php?page=article&item=meego_10_perf&num=1

То есть оказалось что реальная производительность в меньшей степени зависит
от параметров железа.  Это большой ментальный прогресс.

> Однако тут важным моментом будет наличие грамотно векторизующего
> компилятора. Интеловский компилятор в среднем позволяет отбить 13-15%
> при соблюдении ряда специальных манипуляций с кодом (прагмы и проч.),
> вырастая и в два-три раза при удачных случаях. Но некоторые из этих

Отбить 13% я ещё готов поверить, но в 2-3 раза?
Это чо-то какой-то загон очень большой.

> оптимизаций были добавлены только в GCC 4.5 и все равно они уступают
> интеловскому компилятору. А ручной оптимизации уступает все подряд.
> 
> Это я к тому, что поднимать планку базовой платформы, конечно, можно,
> но я бы лучше сконцентрироваться на нахождении неоптимизированных
> фрагментов кода и их исправлять. А уж потом и вручную оптимизировать
> для конкретной микроархитектуры.
> 
> Сегодня коллега ускорил в три с половиной раза собственный код:
> http://maemo.gitorious.org/meego-image-editor/libquill/commit/aba7db8a8fcb8474d9107dcd9e142f18d07b51bf,
> как можно увидеть, никакими аппаратными оптимизациями там и не пахнет.
> Это при том, что и так чтение thumbnail было в рамках приличия.

Ну вот понимаешь, ты говоришь "в три с половиной раза", тебе самому
не смешно?  Процессор это же не конь в вакуме, он тянет данные с
мемори-контроллера, для обработки изображений ему нужно тянуть очень
много.  Сейчас такты стоят дешевле чем гонять данные по шине.
Я не понял этот коммит, он у меня плохо отображется.  Нельзя ли его
представить в виде diff?

> Практика показывает, что верить в "у нас тут код вручную оптимизирован
> под SSE" на x86 микроархитектурах становится крайне неблагодарным
> занятием. Микроархитектуры плывут по поддерживаемому функционалу и
> особенности их реализации иногда убивают все прошлые оптимизационные
> заслуги.
> 
> -- 
> / Alexander Bokovoy

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexander Bokovoy]

2010/9/3 Alexey Tourbin <at@altlinux.ru>:
> Вот это самое наглое сравнение, за него надо дать по жопе (понимаая всю
> твою иронию).  Разговоры про скорость загрузки - это опера нищих.
> Просто у людей гибернация и суспенд реально не работают, поэтому они
> думают что всё время нужно загружаться, и что скорость загрузки имеет
> значение.  Но все эти люди не могут быть бесконечно слепы, пскольку в
> других местах гибернация и суспенд работают, работают очень прилично.
Во-от. Выходим на обсуждением правильного вопроса. :)

>> Однако тут важным моментом будет наличие грамотно векторизующего
>> компилятора. Интеловский компилятор в среднем позволяет отбить 13-15%
>> при соблюдении ряда специальных манипуляций с кодом (прагмы и проч.),
>> вырастая и в два-три раза при удачных случаях. Но некоторые из этих
>
> Отбить 13% я ещё готов поверить, но в 2-3 раза?
> Это чо-то какой-то загон очень большой.
Это традиционный загон при попытка продать свою технологию в стиле "а
вот у нас тут неонка все сама делает, вам не нужно будет держать
высококвалифицированных сотрудников". Да, в 2-3 раза, но на задачах,
которые gcc пока хорошо не раскручивает. При этом про ручную
оптимизацию они даже не спорят -- "конечно оно будет быстрее, но и
специалисты дороже". Вот и весь загон.

>> Сегодня коллега ускорил в три с половиной раза собственный код:
>> http://maemo.gitorious.org/meego-image-editor/libquill/commit/aba7db8a8fcb8474d9107dcd9e142f18d07b51bf,
>> как можно увидеть, никакими аппаратными оптимизациями там и не пахнет.
>> Это при том, что и так чтение thumbnail было в рамках приличия.
>
> Ну вот понимаешь, ты говоришь "в три с половиной раза", тебе самому
> не смешно?  Процессор это же не конь в вакуме, он тянет данные с
> мемори-контроллера, для обработки изображений ему нужно тянуть очень
> много.  Сейчас такты стоят дешевле чем гонять данные по шине.
> Я не понял этот коммит, он у меня плохо отображется.  Нельзя ли его
> представить в виде diff?
Там есть переключатель вверху справа между inline и side-by-side.
Проблема была в том, что имя файла для thumbnail вычислялось при
каждом проходе планировщика задач. Это вычисление включает в себя и
fstat, и вычисление md5 от имени оригинала (так положено по
спецификации thumbnailing). Так что совсем даже не смешно.

-- 
/ Alexander Bokovoy

Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin]

On Fri, Sep 03, 2010 at 08:20:53PM +0300, Led wrote:
> On Friday 03 September 2010 20:03:29 Alexey Tourbin wrote:
> > > Потестируйте на атомах (практически, единственная "живая" на сегодня
> > > не-x86_64 x86 архитектура), которые НЕ-out-of-order, а самые что ни на
> > > есть тупые in-order, в которых даже добавление -mtune-i686 к -march=core2
> > > даёт существенный прирост, ощётимый даже "на глаз" к производительности
> >
> > Существенный прирост.  Это сколько примерно? )
> > Кстати на атомах cmov дает меньше всего.
> > http://www.altlinux.org/FFmpeg
> 
> Я говорил о том, что Atom - in-order, поэтому древнее письмо Линуса про 
> ненужность CMOV на out-of-order процессоре к атому отношения не имеет. А 
> также про то, что прирост даёт "-march=core2 -mtune=i686" по сравнению с 
> просто "-march=core2" - как следствие in-order

Слушайте, подождите, Вы сказали "существенный прирост".  Существенный
прирост это сколько примерно?  У Вас там где-то правда отросло? )

> По указанной ссылке вообще трудно делать оценку: не указаны флаги компиляции - 
> не понятно что значит "скомпилировано с CMOV - скомпилировано без CMOV". Да и 
> FFmpeg очень сильно оптимизирован "вручную", асм-кодом и SIMD'ами, чтоб это 
> было показателем. Если бы я проверял, то, наверное, ипользовал бы разные 
> сборки xvid (с --disable-assembly).

История с ffmpeg не совсем простая, но больше одного процента пока никто
не выжал.  Как бы так.

[devel] [JT] Re: Оптимизированные для i686 и выше библиотеки.

[Michael Shigorin]

On Fri, Sep 03, 2010 at 09:23:07PM +0400, Alexey Tourbin wrote:
> > > Будете смешить образованных людей?
> > Ярким примером чесания в затылке образованным человеком было
> > письмо Solar Designer в bugtraq@ со словами "oops, а про чрут
> > в чруте я и не подумал".
> Can't you be please be more specific and concrete?  And provide a link?
> I've never heard of this story, I'm telling you.  It's intriguing. )

Ай трайд ту файнд ит бат сорта фэйлд.

Фаунд эн эркайв спешли фо ю, майт трай ту сифт through ит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/