Re: [devel] Fwd: lj_udrepper: Text Relocations

[Led <led@altlinux.ru>]

В сообщении от 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.