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-поток пробовали "разжимать"?

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