|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Rogulev 2:5031/7.13 05 Jun 2006 08:21:42
To : Alex Korchmar
Subject : Re: FC5 тормозит
--------------------------------------------------------------------------------
є іpивет, Alex!
01 июн 06 в 20:17, Alex Korchmar писал опеpу. А опеp, Sergey Rogulev, читал:
AK> потому что знает какова польза от этих ключей в реальных применениях.
AK> Я вот тоже знаю.
SR>> в 5мб и 500кб все еще, несмотря на все SATA-2, видна невооруженным
SR>> глазом.
AK> видна, только -O99 не сделает тебе из 5mb 500kb. (э... собственно,
AK> -funroll-loops УВЕЛИЧИВАЕТ размер кода. Как и -mtune=pentium и выше.
AK> Разумеется, не в десять раз, но тем не менее.)
во-первых я не понимаю причем здесь unroll-loops. я даже не уверен в том, что O6
их включает. в явном виде они не включены, а доку на O6 мне сейчас искать
лениво, там ключей много врубается (если ты не в курсе, в мане описаны только до
O3). года три назад читал, но уже давно забыл.
что касается mtune - то оно может как увеличить так и уменьшить код, это как
повезет. в среднем фифти-фифти, по крайней мере увеличение незначительное. зато
выигрыш в быстродействии бывает, и сильный.
относительно конкретно приведенного мной ключа, то я могу привести только
практические результаты. под рукой валялась PCRE-6.6, я компильнул ее в 3х
вариантах:
1) дефолт от RHEL4AS (то есть -O2)
размер libpcreso.0.0.1 - 163256
libpcrecpp.so.0.0.0 - 186699
libpcreposix.so.0.0.0 - 10806
2) при компиляции объявляю -O6 -mtune=athlon-xp
размер libpcreso.0.0.1 - 109396
libpcrecpp.so.0.0.0 - 38880
libpcreposix.so.0.0.0 - 7167
3) а теперь добавляю к (2) еще -fomit-frame-pointers (все чем я пользуюсь я
компилю именно так. по крайней мере стараюсь)
размер libpcreso.0.0.1 - 110933
libpcrecpp.so.0.0.0 - 39480
libpcreposix.so.0.0.0 - 7199
разница, если видишь, в среднем почти в полтора раза, а на одной из либ - в 5
раз.
вывод - твое теоретизирование это конечно интересно, но прежде чем садиться в
лужу - попробуй.
в приведенном случае выигрыш в размере не слишком большой, но в других случаях
бывает и очень приличный. на сквиде я получил разницу в размерах бинари в 3
раза, особенно заметный эффект был на каком-то старом голдеде - при дефолте
бинарь была 14(!) мб, после компиляции с -O6 - 800кб. на Xfree у меня получилось
где-то в 2-2,5 раза (объем всех бинарей вместе), Xorg еще не пробовал.
для чего мне это было надо? сначала - из-за загрузки с nfs, дающей максимум
100кб/с. а потом понравилось ;)
AK> Hу а практика такова: когда-то, когда я был на пять лет моложе и
AK> менее ленив, процессоры еще были большими, а скорость их мерялась
AK> в мегагерцах, пересобрал я ключевые части системы с максимальной
AK> (разумной, не unroll-all-loops, конечно) оптимизацией. Померял -
AK> прослезился. Выигрыш на моих задачах оказался практически на уровне
AK> ошибки измерения. Следует заметить, что gcc с тех пор не слишком
AK> изменился - все ключевые достижения в оптимизаторе появились как раз
AK> тогда.
я что, где-то обещал что оно будет быстрее работать? вот уж фигушки, я таких
экспериментов не проводил и ничего такого говорить не буду, вполне возможно что
скорость работы даже уменьшается. но вот _грузиться_ софт типа гнома и прочего
начинает (естественно, "на глаз") просто в разы быстрее. и время отклика на
мышетоптание падает _очень_ заметно. проверено на практике.
PS да, и O6 != Os, если ты так подумал. Os делает бинарь еще чуток меньше, но
тогда работа тормозит заметно...
\\DEV\RSA rsa(собака)shwamp.murmansk.ru [Team .........](вставить по вкусу)
--- GoldED+/W32 1.1.5-030809
* Origin: Living in interesting times (2:5031/7.13)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
