From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <10201.127.0.0.1.1149695997.squirrel@mojo.unsafe.ru> In-Reply-To: <20060607114131.GJ9823@localhost.localdomain> References: <20060606152921.GA9823@localhost.localdomain> <200606071354.16411.led@altlinux.ru> <20060607111142.GI9823@localhost.localdomain> <200606071422.58410.led@altlinux.ru> <20060607114131.GJ9823@localhost.localdomain> Date: Wed, 7 Jun 2006 19:59:57 +0400 (MSD) From: "Konstantin A. Lepikhov" To: devel@lists.altlinux.org User-Agent: SquirrelMail/1.4.7 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AV-Checked: ClamAV using ClamSMTP 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 15:59:58 -0000 Archived-At: List-Archive: List-Post: <цитата от="Alexey Tourbin"> >> Ещё раз: "быстрее не надо" в том случае, если у вас однопользовательская >> и/или >> однозадачная ОС, то есть ві всегда работаете в системе один и делаете >> одновременно что либо ТОЛЬКО одно: либо смотрите видео, либо смотрите, >> как >> что-то компилится, либо смотрите на меняющиеся циферки видеокодера:) > > В многопользовательской системе производительность упирается прежде > всего в IO, а не в процессор. Так как nice от дисковой активность не > помогает. По крайней мере так было на ядрах 2.4. зато помогают всякие prefetch'и и разные алгоритмы планирования. По крайней мере, в 2.6 какие-то предпосылки уже есть. > asm-вставки делать концептуально неправильно. Получается плохо > поддерживаемый и непереносимый код. Если же выигрыш получается > значительным, то это нужно доказать, исходя из > 1) относительного прироста производительности; > 2) абсолютных потребностей в производительности; > 2) класса решаемых задач. возьми код gogo и lame - gogo работает _на порядок_ быстрее, чем "концептуальный" lame. Хотя насчет поддержки ты прав - читать asm с комментами на японском сложно ;) Также полезно почитать тред по "fPIC и textrel чистоте" Mesa - вкраце он заканчивается словами "нефиг гонят кваку на серверах, а на домашней тачке лишние fps'ы никогда не помешают". Поэтому мне до сих пор непонятно, почему в нашей сборке Mesa упорно делается make linux-dri а не linux-dri-x86. Т.е. вреден не здравый оверхед, а нездоровая паранойя. -- WBR et al.