[devel] Fwd: lj_udrepper: Text Relocations

[devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 15:29 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 15:42 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 15:48 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 15:51 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 15:54 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 16:01 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 16:02 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 16:15 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 16:24 UTC (permalink / raw)]

Re: [devel] Fwd: lj_udrepper: Text Relocations

[@ 2006-06-06 17:02 UTC (permalink / raw)]

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.