From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 3 Sep 2010 22:04:21 +0400 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20100903180421.GC18134@altlinux.org> References: <20100827075230.GP14816@snowwhite.immo> <20100903033034.GF14287@osdn.org.ua> <20100903112030.GA3089@altlinux.org> <201009031549.30310.ledest@gmail.com> <20100903170329.GA18134@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] =?koi8-r?b?79DUyc3J2snSz9fBzs7ZxSDEzNEgaTY4NiDJINfZ28Ug?= =?koi8-r?b?wsnCzMnP1MXLyS4=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 18:04:21 -0000 Archived-At: List-Archive: List-Post: On Fri, Sep 03, 2010 at 08:24:31PM +0300, Alexander Bokovoy wrote: > 2010/9/3 Alexey Tourbin : > > Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели > > тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это > > на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей, > > сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает > > "тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там > > выходит около одного процента в лучше случае (а на атомах - меньше). > > Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет смысла. > В MeeGo долго энтузиасты пытались убедить товарищей из Интела, что > нужно поддерживать что-нибудь, не поддерживающее SSSE3 (ниже > Core2Duo). Интел, понятное дело, гнет свою палку. Phoronix в мае делал > сравнение четырех дистрибутивов на нетбуке, для меня единственным > значимым различием было почти четырехкратное ускорение загрузки > дистрибутива по сравнению с Fedora 13 (8 секунд против 23), но это Вот это самое наглое сравнение, за него надо дать по жопе (понимаая всю твою иронию). Разговоры про скорость загрузки - это опера нищих. Просто у людей гибернация и суспенд реально не работают, поэтому они думают что всё время нужно загружаться, и что скорость загрузки имеет значение. Но все эти люди не могут быть бесконечно слепы, пскольку в других местах гибернация и суспенд работают, работают очень прилично. > скорее заслуга btrf и меньшего количества сервисов, чем аппаратного > ускорения. Сравнение делалось на одном и том же нетбуке. > http://www.phoronix.com/scan.php?page=article&item=meego_10_perf&num=1 То есть оказалось что реальная производительность в меньшей степени зависит от параметров железа. Это большой ментальный прогресс. > Однако тут важным моментом будет наличие грамотно векторизующего > компилятора. Интеловский компилятор в среднем позволяет отбить 13-15% > при соблюдении ряда специальных манипуляций с кодом (прагмы и проч.), > вырастая и в два-три раза при удачных случаях. Но некоторые из этих Отбить 13% я ещё готов поверить, но в 2-3 раза? Это чо-то какой-то загон очень большой. > оптимизаций были добавлены только в GCC 4.5 и все равно они уступают > интеловскому компилятору. А ручной оптимизации уступает все подряд. > > Это я к тому, что поднимать планку базовой платформы, конечно, можно, > но я бы лучше сконцентрироваться на нахождении неоптимизированных > фрагментов кода и их исправлять. А уж потом и вручную оптимизировать > для конкретной микроархитектуры. > > Сегодня коллега ускорил в три с половиной раза собственный код: > http://maemo.gitorious.org/meego-image-editor/libquill/commit/aba7db8a8fcb8474d9107dcd9e142f18d07b51bf, > как можно увидеть, никакими аппаратными оптимизациями там и не пахнет. > Это при том, что и так чтение thumbnail было в рамках приличия. Ну вот понимаешь, ты говоришь "в три с половиной раза", тебе самому не смешно? Процессор это же не конь в вакуме, он тянет данные с мемори-контроллера, для обработки изображений ему нужно тянуть очень много. Сейчас такты стоят дешевле чем гонять данные по шине. Я не понял этот коммит, он у меня плохо отображется. Нельзя ли его представить в виде diff? > Практика показывает, что верить в "у нас тут код вручную оптимизирован > под SSE" на x86 микроархитектурах становится крайне неблагодарным > занятием. Микроархитектуры плывут по поддерживаемому функционалу и > особенности их реализации иногда убивают все прошлые оптимизационные > заслуги. > > -- > / Alexander Bokovoy