From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Led To: ALT Devel discussion list Date: Wed, 7 Jun 2006 14:22:58 +0300 User-Agent: KMail/1.9.1 References: <20060606152921.GA9823@localhost.localdomain> <200606071354.16411.led@altlinux.ru> <20060607111142.GI9823@localhost.localdomain> In-Reply-To: <20060607111142.GI9823@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200606071422.58410.led@altlinux.ru> Subject: Re: [devel] Fwd: lj_udrepper: Text Relocations X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 11:22:39 -0000 Archived-At: List-Archive: List-Post: В сообщении от 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.