[devel] Fwd: lj_udrepper: Text Relocations

[devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

textrelocs.html -- довольно интересный текст.


----- Forwarded message from rss2mail2 -----

Text Relocations at 03-06-2006 17:50:03
http://udrepper.livejournal.com/10666.html
   People treated creating DSOs with text relocations so far cavalier
   offense. The runtime automatically works around the problems the
   programmers are responsible for and the costs and risks are not
   immediately visible unless one thinks about the issue.

   This changed with the SELinux memory protection bits which are enabled
   in FC5 and later. Text relocations are a fatal flaw of a DSO or PIE
   and must be avoided. Since people complain that it's hard to fix the
   problem I've written code and wrote a little article on [0] how to fix
   them.

   For completeness I should mention that it is possible to label DSOs so
   that the kernel allows text relocations. This is done using the
   textrel_shlib_t label. But this really never should be regarded as a
   solution, it's a work-around. Denying text relocations is a major
   security feature.

   [0] http://people.redhat.com/drepper/textrelocs.html

----- End forwarded message -----

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Dmitry V. Levin]

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

On Tue, Jun 06, 2006 at 07:29:21PM +0400, Alexey Tourbin wrote:
> textrelocs.html -- довольно интересный текст.
> 
> ----- Forwarded message from rss2mail2 -----
> 
> Text Relocations at 03-06-2006 17:50:03
> http://udrepper.livejournal.com/10666.html
>    People treated creating DSOs with text relocations so far cavalier
>    offense. The runtime automatically works around the problems the
>    programmers are responsible for and the costs and risks are not
>    immediately visible unless one thinks about the issue.
> 
>    This changed with the SELinux memory protection bits which are enabled
>    in FC5 and later. Text relocations are a fatal flaw of a DSO or PIE
>    and must be avoided. Since people complain that it's hard to fix the
>    problem I've written code and wrote a little article on [0] how to fix
>    them.
> 
>    For completeness I should mention that it is possible to label DSOs so
>    that the kernel allows text relocations.

А в некоторых ядрах эту сомнительную возможность можно отключать частично
или совсем.


-- 
ldv

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 6 июня 2006 18:29 Alexey Tourbin написал(a):
> textrelocs.html -- довольно интересный текст.
>
>
> ----- Forwarded message from rss2mail2 -----
>
> Text Relocations at 03-06-2006 17:50:03
> http://udrepper.livejournal.com/10666.html
>    People treated creating DSOs with text relocations so far cavalier
>    offense. The runtime automatically works around the problems the
>    programmers are responsible for and the costs and risks are not
>    immediately visible unless one thinks about the issue.
>
>    This changed with the SELinux memory protection bits which are enabled
>    in FC5 and later. Text relocations are a fatal flaw of a DSO or PIE
>    and must be avoided. Since people complain that it's hard to fix the
>    problem I've written code and wrote a little article on [0] how to fix
>    them.
>
>    For completeness I should mention that it is possible to label DSOs so
>    that the kernel allows text relocations. This is done using the
>    textrel_shlib_t label. But this really never should be regarded as a
>    solution, it's a work-around. Denying text relocations is a major
>    security feature.
>
>    [0] http://people.redhat.com/drepper/textrelocs.html
>
> ----- End forwarded message -----

Ага, особенно вот это "порадовало":

"If the problem is indeed the result of hand-written assembler code the 
solution is not as simple as adding a compiler/assembler flag. The code needs 
to be rewritten. This is architecture specific and can vary widely between 
every single instance. We are not going into those details here. Find a 
person with sufficient assembly programming skills if this problem appears."

:(

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Dmitry V. Levin]

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

On Tue, Jun 06, 2006 at 06:48:38PM +0300, Led wrote:
[...]
> Ага, особенно вот это "порадовало":
> 
> "If the problem is indeed the result of hand-written assembler code the 
> solution is not as simple as adding a compiler/assembler flag. The code needs 
> to be rewritten. This is architecture specific and can vary widely between 
> every single instance. We are not going into those details here. Find a 
> person with sufficient assembly programming skills if this problem appears."
> 
> :(

На это есть простой рецепт о двух пунктах:
1. Не пишите на ассемблере без необходимости.
2. Избегайте необходимости писать на ассемблере.


-- 
ldv

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 6 июня 2006 18:51 Dmitry V. Levin написал(a):
> On Tue, Jun 06, 2006 at 06:48:38PM +0300, Led wrote:
> [...]
>
> > Ага, особенно вот это "порадовало":
> >
> > "If the problem is indeed the result of hand-written assembler code the
> > solution is not as simple as adding a compiler/assembler flag. The code
> > needs to be rewritten. This is architecture specific and can vary widely
> > between every single instance. We are not going into those details here.
> > Find a person with sufficient assembly programming skills if this problem
> > appears."
> >
> > :(
>
> На это есть простой рецепт о двух пунктах:
> 1. Не пишите на ассемблере без необходимости.
> 2. Избегайте необходимости писать на ассемблере.

Я-то избегаю... Как исправлять, если это уже написано? Например, сложный 
кодек?

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Tue, Jun 06, 2006 at 07:42:28PM +0400, Dmitry V. Levin wrote:
> >    For completeness I should mention that it is possible to label DSOs so
> >    that the kernel allows text relocations.
> 
> А в некоторых ядрах эту сомнительную возможность можно отключать частично
> или совсем.

В SELinux отключается и отключено по умолчанию, об этом написано по ссылке.

verify-elf мог бы давать более точную диагностику -- названия функций,
в которых встречаются text relocations.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Tue, Jun 06, 2006 at 06:54:21PM +0300, Led wrote:
> > На это есть простой рецепт о двух пунктах:
> > 1. Не пишите на ассемблере без необходимости.
> > 2. Избегайте необходимости писать на ассемблере.
> 
> Я-то избегаю... Как исправлять, если это уже написано? Например, сложный 
> кодек?

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

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Konstantin A. Lepikhov]

<цитата от="Dmitry V. Levin">
> On Tue, Jun 06, 2006 at 07:29:21PM +0400, Alexey Tourbin wrote:
>> textrelocs.html -- довольно интересный текст.
>>
>> ----- Forwarded message from rss2mail2 -----
>>
>> Text Relocations at 03-06-2006 17:50:03
>> http://udrepper.livejournal.com/10666.html
>>    People treated creating DSOs with text relocations so far cavalier
>>    offense. The runtime automatically works around the problems the
>>    programmers are responsible for and the costs and risks are not
>>    immediately visible unless one thinks about the issue.
>>
>>    This changed with the SELinux memory protection bits which are
>> enabled
>>    in FC5 and later. Text relocations are a fatal flaw of a DSO or PIE
>>    and must be avoided. Since people complain that it's hard to fix the
>>    problem I've written code and wrote a little article on [0] how to
>> fix
>>    them.
>>
>>    For completeness I should mention that it is possible to label DSOs
>> so
>>    that the kernel allows text relocations.
>
> А в некоторых ядрах эту сомнительную возможность можно отключать частично
> или совсем.
может, добавить это в altsecurity? :)

-- 
WBR et al.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 6 июня 2006 19:02 Alexey Tourbin написал(a):
> On Tue, Jun 06, 2006 at 06:54:21PM +0300, Led wrote:
> > > На это есть простой рецепт о двух пунктах:
> > > 1. Не пишите на ассемблере без необходимости.
> > > 2. Избегайте необходимости писать на ассемблере.
> >
> > Я-то избегаю... Как исправлять, если это уже написано? Например, сложный
> > кодек?
>
> Обычно есть эквивалент на Си.  Если проигрыш по скорости меньше чем
> в полтора раза, то наверное стоит его активировать.

Мне обычно попадаются с проигрышем в скорости в 3-10 раз...

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Tue, Jun 06, 2006 at 07:29:21PM +0400, Alexey Tourbin wrote:
> http://udrepper.livejournal.com/10666.html

Кстати у него в блоге ещё интересные записи есть.  Например вот эта:
Developers != Distributors http://udrepper.livejournal.com/10109.html

Касается поддержки "стабильных" продуктов.  В общем оффтопик... :)

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [060606 19:39]:
> textrelocs.html -- довольно интересный текст.
Даёшь textrel=strict ? ;-)

P.S. И на коробку наклейку - "Одобрено Дреппером" ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Dmitry V. Levin]

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

On Tue, Jun 06, 2006 at 09:46:43PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [060606 19:39]:
> > textrelocs.html -- довольно интересный текст.
> Даёшь textrel=strict ? ;-)
> 
> P.S. И на коробку наклейку - "Одобрено Дреппером" ;-)

Я встречал несколько высказываний на эту тему от некоторых других
разработчиков, и высказывания эти были существенно покрепче тех, что
использовал Дреппер.


-- 
ldv

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Dmitry V. Levin]

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

On Tue, Jun 06, 2006 at 08:01:03PM +0400, Alexey Tourbin wrote:
> On Tue, Jun 06, 2006 at 07:42:28PM +0400, Dmitry V. Levin wrote:
> > >    For completeness I should mention that it is possible to label DSOs so
> > >    that the kernel allows text relocations.
> > 
> > А в некоторых ядрах эту сомнительную возможность можно отключать частично
> > или совсем.
> 
> В SELinux отключается и отключено по умолчанию, об этом написано по ссылке.
> 
> verify-elf мог бы давать более точную диагностику -- названия функций,
> в которых встречаются text relocations.

Другими словами, ты хочешь видеть пакет elfutils в базовой сборочной среде?


-- 
ldv

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Mikhail Zabaluev]

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

В Втр, 06/06/2006 в 18:54 +0300, Led пишет:
> > > Ага, особенно вот это "порадовало":
> > >
> > > "If the problem is indeed the result of hand-written assembler code the
> > > solution is not as simple as adding a compiler/assembler flag. The code
> > > needs to be rewritten. This is architecture specific and can vary widely
> > > between every single instance. We are not going into those details here.
> > > Find a person with sufficient assembly programming skills if this problem
> > > appears."
> > >
> > > :(
> >
> > На это есть простой рецепт о двух пунктах:
> > 1. Не пишите на ассемблере без необходимости.
> > 2. Избегайте необходимости писать на ассемблере.
> 
> Я-то избегаю... Как исправлять, если это уже написано? Например, сложный 
> кодек?

Посмотреть, не реализованы ли самые ощутимые внутренние циклы в
liboil :)


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] eu-findtextrel

[Dmitry V. Levin]

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

On Tue, Jun 06, 2006 at 08:01:03PM +0400, Alexey Tourbin wrote:
> verify-elf мог бы давать более точную диагностику -- названия функций,
> в которых встречаются text relocations.

Например, в пакете libfame-0.9.0-alt4
$ eu-findtextrel libfame-0.9.so.0.0.0 |sort -u
either the file containing the function 'fame_syntax_mpeg1_t_constructor' or the file containing the function 'fame_syntax_mpeg4_t_constructor' is not compiled with -fpic/-fPIC

Хотите это видеть по умолчанию?

Забавно, этот же пакет существует в сборке для x86-64, разумеется без
text relocations, которых там не предусмотрено.

У меня возникла мысль помечать бинарные пакеты, в которых нет объектов с
text relocations, каким-нибудь тэгом, чтобы их можно было легко вычислять
или, например, запрещать установку пакетов без такого тэга.  Или проще
дождаться, пока все мигрируют с x86 на x86-64?


-- 
ldv

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 12:24:31AM +0400, Dmitry V. Levin wrote:
> On Tue, Jun 06, 2006 at 08:01:03PM +0400, Alexey Tourbin wrote:
> > On Tue, Jun 06, 2006 at 07:42:28PM +0400, Dmitry V. Levin wrote:
> > > >    For completeness I should mention that it is possible to label DSOs so
> > > >    that the kernel allows text relocations.
> > > 
> > > А в некоторых ядрах эту сомнительную возможность можно отключать частично
> > > или совсем.
> > 
> > В SELinux отключается и отключено по умолчанию, об этом написано по ссылке.
> > 
> > verify-elf мог бы давать более точную диагностику -- названия функций,
> > в которых встречаются text relocations.
> 
> Другими словами, ты хочешь видеть пакет elfutils в базовой сборочной среде?

Всё для человека! :)  Название функции гораздо понятнее, чем 0x0.
Соответственно больше шансов, что пакет будет исправлен.  Хотя надо было
сразу это делать, когда началась борьба с text relocations.  Теперь уже
большая часть пакетов исправлена.

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

[devel] [JT] Re: eu-findtextrel

[Michael Shigorin]

On Wed, Jun 07, 2006 at 12:59:30AM +0400, Dmitry V. Levin wrote:
> У меня возникла мысль помечать бинарные пакеты, в которых нет
> объектов с text relocations, каким-нибудь тэгом, чтобы их можно
> было легко вычислять или, например, запрещать установку пакетов
> без такого тэга.

Provides: rpm(TextRel)?

> Или проще дождаться, пока все мигрируют с x86 на x86-64?

Вот наверное.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Tue, Jun 06, 2006 at 07:24:29PM +0300, Led wrote:
> В сообщении от 6 июня 2006 19:02 Alexey Tourbin написал(a):
> > On Tue, Jun 06, 2006 at 06:54:21PM +0300, Led wrote:
> > > > На это есть простой рецепт о двух пунктах:
> > > > 1. Не пишите на ассемблере без необходимости.
> > > > 2. Избегайте необходимости писать на ассемблере.
> > >
> > > Я-то избегаю... Как исправлять, если это уже написано? Например, сложный
> > > кодек?
> >
> > Обычно есть эквивалент на Си.  Если проигрыш по скорости меньше чем
> > в полтора раза, то наверное стоит его активировать.
> 
> Мне обычно попадаются с проигрышем в скорости в 3-10 раз...

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

Остаются только числодробильные задачи (тот же BLAS или сжатие видео),
которые не лимитированы абсолютными потребностями реалтайма.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Sergey Pinaev]

On Wed, 7 Jun 2006 10:47:04 +0400
Alexey Tourbin <at@altlinux.ru> wrote:

> Нужно ещё оценивать абсолютный выигрыш, а не только относительный.
> Например, медиа-плеер вряд ли стоит оптимизировать ассемблерными
> вставками, потому что в реальной системе вряд ли будет запущено более
> одной (активной) копии плеера, и она будет откусывать довольно
> незначительный процент CPU (у меня например mplayer в top'е вообще не
> видно, когда он играет видео).

Не у всех на столах двухгигагерцовые процессоры.

-- 
mail="Sergey Pinaev <dfo@antex.ru>"
url="http://`echo $mail | sed 's/.* <\(.*\)@\(.*\)>/\1.\2/'`"

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 11:24:39AM +0400, Sergey Pinaev wrote:
> On Wed, 7 Jun 2006 10:47:04 +0400
> Alexey Tourbin <at@altlinux.ru> wrote:
> 
> > Нужно ещё оценивать абсолютный выигрыш, а не только относительный.
> > Например, медиа-плеер вряд ли стоит оптимизировать ассемблерными
> > вставками, потому что в реальной системе вряд ли будет запущено более
> > одной (активной) копии плеера, и она будет откусывать довольно
> > незначительный процент CPU (у меня например mplayer в top'е вообще не
> > видно, когда он играет видео).
> 
> Не у всех на столах двухгигагерцовые процессоры.

Работаем на перспективу. :)

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 7 июня 2006 09:47 Alexey Tourbin написал(a):
> On Tue, Jun 06, 2006 at 07:24:29PM +0300, Led wrote:
> > В сообщении от 6 июня 2006 19:02 Alexey Tourbin написал(a):
> > > On Tue, Jun 06, 2006 at 06:54:21PM +0300, Led wrote:
> > > > > На это есть простой рецепт о двух пунктах:
> > > > > 1. Не пишите на ассемблере без необходимости.
> > > > > 2. Избегайте необходимости писать на ассемблере.
> > > >
> > > > Я-то избегаю... Как исправлять, если это уже написано? Например,
> > > > сложный кодек?
> > >
> > > Обычно есть эквивалент на Си.  Если проигрыш по скорости меньше чем
> > > в полтора раза, то наверное стоит его активировать.
> >
> > Мне обычно попадаются с проигрышем в скорости в 3-10 раз...
>
> Нужно ещё оценивать абсолютный выигрыш, а не только относительный.
> Например, медиа-плеер вряд ли стоит оптимизировать ассемблерными
> вставками, потому что в реальной системе вряд ли будет запущено более
> одной (активной) копии плеера, и она будет откусывать довольно
> незначительный процент CPU (у меня например mplayer в top'е вообще не
> видно, когда он играет видео).
>
> Остаются только числодробильные задачи (тот же BLAS или сжатие видео),
> которые не лимитированы абсолютными потребностями реалтайма.

"Сжатие видео - не лимитированы абсолютными потребностями реалтайма" - 
голословное делетантское утверждение (ИМХО).

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 12:06:16PM +0300, Led wrote:
> > Остаются только числодробильные задачи (тот же BLAS или сжатие видео),
> > которые не лимитированы абсолютными потребностями реалтайма.
> 
> "Сжатие видео - не лимитированы абсолютными потребностями реалтайма" - 
> голословное делетантское утверждение (ИМХО).

Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
особого смысла разжимать быстрее, чем нужно успевать показывать.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Kirill A. Shutemov]

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

On 14:42 Wed 07 Jun, Alexey Tourbin wrote:
> Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
> особого смысла разжимать быстрее, чем нужно успевать показывать.

А если в фоне ещё ядро собирается? ;)

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

Лучше /media/... - иначе будет несовместимость с FHS-2.3, думаю что лишняя
неоправданная несовместимость нам не нужна.
		-- ldv in devel@

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 7 июня 2006 13:42 Alexey Tourbin написал(a):
> On Wed, Jun 07, 2006 at 12:06:16PM +0300, Led wrote:
> > > Остаются только числодробильные задачи (тот же BLAS или сжатие видео),
> > > которые не лимитированы абсолютными потребностями реалтайма.
> >
> > "Сжатие видео - не лимитированы абсолютными потребностями реалтайма" -
> > голословное делетантское утверждение (ИМХО).
>
> Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
> особого смысла разжимать быстрее, чем нужно успевать показывать.

Вы говорили то, что говорили: "Остаются только числодробильные задачи (тот же 
BLAS или сжатие видео), которые не лимитированы абсолютными потребностями 
реалтайма."

А на счёт разжатия... Может и нет смысла "разжимать быстрее, чем нужно 
успевать показывать"... на однопользовательской однозадачной системе. даже 
если так, хороший h264-поток пробовали "разжимать"?

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 01:52:42PM +0300, Kirill A. Shutemov wrote:
> On 14:42 Wed 07 Jun, Alexey Tourbin wrote:
> > Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
> > особого смысла разжимать быстрее, чем нужно успевать показывать.
> А если в фоне ещё ядро собирается? ;)

Тогда основные тромоза будут обусловлены IO.  Попробуйте запустить osec
и посмотреть видео -- тормоза будут дажа на самом мощном процессоре
(особенно если шина IDE).

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 01:54:16PM +0300, Led wrote:
> В сообщении от 7 июня 2006 13:42 Alexey Tourbin написал(a):
> > On Wed, Jun 07, 2006 at 12:06:16PM +0300, Led wrote:
> > > > Остаются только числодробильные задачи (тот же BLAS или сжатие видео),
> > > > которые не лимитированы абсолютными потребностями реалтайма.
> > >
> > > "Сжатие видео - не лимитированы абсолютными потребностями реалтайма" -
> > > голословное делетантское утверждение (ИМХО).
> >
> > Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
> > особого смысла разжимать быстрее, чем нужно успевать показывать.
> 
> Вы говорили то, что говорили: "Остаются только числодробильные задачи (тот же 
> BLAS или сжатие видео), которые не лимитированы абсолютными потребностями 
> реалтайма."

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

Я хотел сказать, что для первого класса задач, типа mpg123 или mplayer,
ассемблерную оптимизацию можно отключить, потому что они и так будут
играть достаточно быстро (just good enough), а быстрее и не надо.

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

> А на счёт разжатия... Может и нет смысла "разжимать быстрее, чем нужно 
> успевать показывать"... на однопользовательской однозадачной системе. даже 
> если так, хороший h264-поток пробовали "разжимать"?

Нет, не пробовал.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 7 июня 2006 14:11 Alexey Tourbin написал(a):
> On Wed, Jun 07, 2006 at 01:54:16PM +0300, Led wrote:
> > В сообщении от 7 июня 2006 13:42 Alexey Tourbin написал(a):
> > > On Wed, Jun 07, 2006 at 12:06:16PM +0300, Led wrote:
> > > > > Остаются только числодробильные задачи (тот же BLAS или сжатие
> > > > > видео), которые не лимитированы абсолютными потребностями
> > > > > реалтайма.
> > > >
> > > > "Сжатие видео - не лимитированы абсолютными потребностями реалтайма"
> > > > - голословное делетантское утверждение (ИМХО).
> > >
> > > Свое ИМХО я Вам уже писал. :)  Я говорил о расжатии видео -- его нет
> > > особого смысла разжимать быстрее, чем нужно успевать показывать.
> >
> > Вы говорили то, что говорили: "Остаются только числодробильные задачи
> > (тот же BLAS или сжатие видео), которые не лимитированы абсолютными
> > потребностями реалтайма."
>
> Я готов пояснить.  Есть задачи, типа просмотра видео, где абсолютные
> потребности производительности оцениваются исходя из того, что нужно
> успеть сделать "в секунду".  Если успеваем разжать сколько нужно в
> секунду, то дальнейшая оптимизация более или менее бесполезна (а
> ассемблерная оптимизация даже вредна).  BLAS и сжатие видео как раз к
> этому классу приложений НЕ относятся, потому что в случае с научными
> расчетами или сжатием видео "слишком быстро" не бывает.  Эти задачи не
> привязаны к реалтайму, то есть "не лимитированы абсолютными
> потребностями реалтайма".

Ещё раз: необходимость сжатия видео именно  в реалтайме - реальная и часто 
встречающаяся задача!

>
> Я хотел сказать, что для первого класса задач, типа mpg123 или mplayer,
> ассемблерную оптимизацию можно отключить, потому что они и так будут
> играть достаточно быстро (just good enough), а быстрее и не надо.

Ещё раз: "быстрее не надо" в том случае, если у вас однопользовательская и/или 
однозадачная ОС, то есть ві всегда работаете в системе один и делаете 
одновременно что либо ТОЛЬКО одно: либо смотрите видео, либо смотрите, как 
что-то компилится, либо смотрите на меняющиеся циферки видеокодера:)

>
> Для второго класса задач очевидных абсолютных оценок нет (научные
> расчеты могут иметь произвольную сложность), поэтому для них
> актуальность оптимизации остается, и ассемблерные вставки можно
> оправдать.  В частности, BLAS сейчас собран с ассемблерными вставками.

AFAIK в gcc тоже есть асемблерные вставки. Дело не в асм-вставках, а в том как 
и ПРАВИЛЬНО делать. Так вот, из рекомендаций по ПРАВИЛЬНОСТИ асм-вставок 
самая "конкретная" - "перепишите асм-код правильно" :)

>
> > А на счёт разжатия... Может и нет смысла "разжимать быстрее, чем нужно
> > успевать показывать"... на однопользовательской однозадачной системе.
> > даже если так, хороший h264-поток пробовали "разжимать"?
>
> Нет, не пробовал.

Попробуйте:)

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 02:22:58PM +0300, Led wrote:
> > Я готов пояснить.  Есть задачи, типа просмотра видео, где абсолютные
> > потребности производительности оцениваются исходя из того, что нужно
> > успеть сделать "в секунду".  Если успеваем разжать сколько нужно в
> > секунду, то дальнейшая оптимизация более или менее бесполезна (а
> > ассемблерная оптимизация даже вредна).  BLAS и сжатие видео как раз к
> > этому классу приложений НЕ относятся, потому что в случае с научными
> > расчетами или сжатием видео "слишком быстро" не бывает.  Эти задачи не
> > привязаны к реалтайму, то есть "не лимитированы абсолютными
> > потребностями реалтайма".
> 
> Ещё раз: необходимость сжатия видео именно  в реалтайме - реальная и часто 
> встречающаяся задача!

Я об этом не подумал.  Но я написал, о чем я подумал: о том, что не вижу
mplayer в верхних строчках top, когда он играет видео.

> Ещё раз: "быстрее не надо" в том случае, если у вас однопользовательская и/или 
> однозадачная ОС, то есть ві всегда работаете в системе один и делаете 
> одновременно что либо ТОЛЬКО одно: либо смотрите видео, либо смотрите, как 
> что-то компилится, либо смотрите на меняющиеся циферки видеокодера:)

В многопользовательской системе производительность упирается прежде
всего в IO, а не в процессор.  Так как nice от дисковой активность не
помогает.  По крайней мере так было на ядрах 2.4.

> > Для второго класса задач очевидных абсолютных оценок нет (научные
> > расчеты могут иметь произвольную сложность), поэтому для них
> > актуальность оптимизации остается, и ассемблерные вставки можно
> > оправдать.  В частности, BLAS сейчас собран с ассемблерными вставками.
> 
> AFAIK в gcc тоже есть асемблерные вставки. Дело не в асм-вставках, а в том как 
> и ПРАВИЛЬНО делать. Так вот, из рекомендаций по ПРАВИЛЬНОСТИ асм-вставок 
> самая "конкретная" - "перепишите асм-код правильно" :)

asm-вставки делать концептуально неправильно.  Получается плохо
поддерживаемый и непереносимый код.  Если же выигрыш получается
значительным, то это нужно доказать, исходя из
1) относительного прироста производительности;
2) абсолютных потребностей в производительности;
2) класса решаемых задач.

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

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led]

В сообщении от 7 июня 2006 14:41 Alexey Tourbin написал(a):
> On Wed, Jun 07, 2006 at 02:22:58PM +0300, Led wrote:
> > > Я готов пояснить.  Есть задачи, типа просмотра видео, где абсолютные
> > > потребности производительности оцениваются исходя из того, что нужно
> > > успеть сделать "в секунду".  Если успеваем разжать сколько нужно в
> > > секунду, то дальнейшая оптимизация более или менее бесполезна (а
> > > ассемблерная оптимизация даже вредна).  BLAS и сжатие видео как раз к
> > > этому классу приложений НЕ относятся, потому что в случае с научными
> > > расчетами или сжатием видео "слишком быстро" не бывает.  Эти задачи не
> > > привязаны к реалтайму, то есть "не лимитированы абсолютными
> > > потребностями реалтайма".
> >
> > Ещё раз: необходимость сжатия видео именно  в реалтайме - реальная и
> > часто встречающаяся задача!
>
> Я об этом не подумал.  Но я написал, о чем я подумал: о том, что не вижу
> mplayer в верхних строчках top, когда он играет видео.
>
> > Ещё раз: "быстрее не надо" в том случае, если у вас однопользовательская
> > и/или однозадачная ОС, то есть ві всегда работаете в системе один и
> > делаете одновременно что либо ТОЛЬКО одно: либо смотрите видео, либо
> > смотрите, как что-то компилится, либо смотрите на меняющиеся циферки
> > видеокодера:)
>
> В многопользовательской системе производительность упирается прежде
> всего в IO, а не в процессор.  Так как nice от дисковой активность не
> помогает.  По крайней мере так было на ядрах 2.4.

Она упирается в IO если: диск - один, кеш - маленький ( мало оперативки), все 
ресурсоёмкие задачи много читаюпишут с/на диск. Но в этом случае и думать 
нЕчего - нужно добавить винт:)

>
> > > Для второго класса задач очевидных абсолютных оценок нет (научные
> > > расчеты могут иметь произвольную сложность), поэтому для них
> > > актуальность оптимизации остается, и ассемблерные вставки можно
> > > оправдать.  В частности, BLAS сейчас собран с ассемблерными вставками.
> >
> > AFAIK в gcc тоже есть асемблерные вставки. Дело не в асм-вставках, а в
> > том как и ПРАВИЛЬНО делать. Так вот, из рекомендаций по ПРАВИЛЬНОСТИ
> > асм-вставок самая "конкретная" - "перепишите асм-код правильно" :)
>
> asm-вставки делать концептуально неправильно.  Получается плохо
> поддерживаемый и непереносимый код.  Если же выигрыш получается
> значительным, то это нужно доказать, исходя из
> 1) относительного прироста производительности;
> 2) абсолютных потребностей в производительности;
> 2) класса решаемых задач.

С этим и не спорил:)

-- 
Led.

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Yury Aliaev]

Alexey Tourbin scripsit:

>>>незначительный процент CPU (у меня например mplayer в top'е вообще не
>>>видно, когда он играет видео).
>>
>>Не у всех на столах двухгигагерцовые процессоры.
> 
> 
> Работаем на перспективу. :)

Перспективы у всех разные ;-D К тому же отказываться от оптимального 
кода в пользу заведомо неоптимального мотивируя это только тем, что мол 
процессоры нынче быстрые и сжуют и такое -- жлобство, гейтсовщина и 
вредно сказывается на равновесии мира ;) (пафосный же я чел, однако!)

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 03:56:53PM +0400, Yury Aliaev wrote:
> Alexey Tourbin scripsit:
> 
> >>>незначительный процент CPU (у меня например mplayer в top'е вообще не
> >>>видно, когда он играет видео).
> >>
> >>Не у всех на столах двухгигагерцовые процессоры.
> > 
> > 
> > Работаем на перспективу. :)
> 
> Перспективы у всех разные ;-D К тому же отказываться от оптимального 
> кода в пользу заведомо неоптимального мотивируя это только тем, что мол 
> процессоры нынче быстрые и сжуют и такое -- жлобство, гейтсовщина и 
> вредно сказывается на равновесии мира ;) (пафосный же я чел, однако!)

На каждого пафосного чела найдется половой орган с винтом.  Что до
ассемблера, то здесь не Гейтс, а Томпсон и Ритчи первыми переписали
свое ядрышко на Си.

Код может быть оптимальным не только по производительности, но и
по поддерживаемости -- причем в ряде случаев важна поддерживаемость
случайным (но квалифицированным) maintainer'ом.

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

[devel] блин.

[Michael Shigorin]

Есть предложение завязывать с этим гнилым базаром типа
"учёные-инженеры" или "программисты-админы".  Ничего нового.

> Код может быть оптимальным не только по производительности,
> но и по поддерживаемости -- причем в ряде случаев важна
> поддерживаемость случайным (но квалифицированным)
> maintainer'ом.

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

В первую очередь определяет, тем не менее, майнтейнер.

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

Re: [devel] блин.

[Alexey Tourbin]

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

On Wed, Jun 07, 2006 at 03:25:09PM +0300, Michael Shigorin wrote:
> Есть предложение завязывать с этим гнилым базаром типа
> "учёные-инженеры" или "программисты-админы".  Ничего нового.

Товарищ старший лейтенант!  Рядовой Турбин с гнилым базаром -- за-вя-зал!!

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

Re: [devel] блин.

[Yury Aliaev]

Alexey Tourbin scripsit:
> 
>>Есть предложение завязывать с этим гнилым базаром типа
>>"учёные-инженеры" или "программисты-админы".  Ничего нового.
> 
> 
> Товарищ старший лейтенант!  Рядовой Турбин с гнилым базаром -- за-вя-зал!!
> 

Рядовой Аляев -- тоже ;)

Re: [devel] Fwd: lj_udrepper: Text Relocations

[Konstantin A. Lepikhov]

<цитата от="Alexey Tourbin">
<skip>
>> Ещё раз: "быстрее не надо" в том случае, если у вас однопользовательская
>> и/или
>> однозадачная ОС, то есть ві всегда работаете в системе один и делаете
>> одновременно что либо ТОЛЬКО одно: либо смотрите видео, либо смотрите,
>> как
>> что-то компилится, либо смотрите на меняющиеся циферки видеокодера:)
>
> В многопользовательской системе производительность упирается прежде
> всего в IO, а не в процессор.  Так как nice от дисковой активность не
> помогает.  По крайней мере так было на ядрах 2.4.
зато помогают всякие prefetch'и и разные алгоритмы планирования. По
крайней мере, в 2.6 какие-то предпосылки уже есть.

<skip>
> asm-вставки делать концептуально неправильно.  Получается плохо
> поддерживаемый и непереносимый код.  Если же выигрыш получается
> значительным, то это нужно доказать, исходя из
> 1) относительного прироста производительности;
> 2) абсолютных потребностей в производительности;
> 2) класса решаемых задач.
возьми код gogo и lame - gogo работает _на порядок_ быстрее, чем
"концептуальный" lame. Хотя насчет поддержки ты прав - читать asm с
комментами на японском сложно ;)

Также полезно почитать тред по "fPIC и textrel чистоте" Mesa - вкраце он
заканчивается словами "нефиг гонят кваку на серверах, а на домашней тачке
лишние fps'ы никогда не помешают". Поэтому мне до сих пор непонятно,
почему в нашей сборке Mesa упорно делается make linux-dri а не
linux-dri-x86.

Т.е. вреден не здравый оверхед, а нездоровая паранойя.

-- 
WBR et al.