[devel] gcc -O2 vs gcc -Os performance

[devel] gcc -O2 vs gcc -Os performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4129 bytes --]

Greetings!

Subj: по мотивам одноименной истории из linux-kernel -- см. тред
http://lists.insecure.org/lists/linux-kernel/2003/Feb/0984.html

Andi Kleen (ak_at_suse.de):

	-Os on 2.95 is not too useful. It only started becomming useful
	on 3.1+, even more so on the upcomming 3.3.

	e.g. there was one report of ACPI shrinking by >60k by
	recompiling it with -Os on 3.1. ACPI is only slow path code so
	that is completely reasonable.

Alan Cox (alan_at_lxorguk.ukuu.org.uk):

	gcc 3.2 is a lot smarter about -Os and it makes a very big size
	difference according to the numbers the from the ACPI guys.

Martin J. Bligh (mbligh_at_aracnet.com):

	2901299 vmlinux.O2
	2667827 vmlinux.Os

	Kernbench-2: (make -j N vmlinux, where N = 2 x num_cpus)
					 Elapsed User System CPU
		2.5.59-mjb3-gcc32-O2 45.86 564.75 110.91 1472.67
		2.5.59-mjb3-gcc32-Os 45.74 563.96 111.06 1475.17

Linus Torvalds (torvalds_at_transmeta.com):

	That's since a large part of the premise of the -Os speed
	advantage is that it is better for icache (usually not an issue
	for microbenchmarks) and that it is better for load/startup
	times (generally not a huge issue for kernels, since the real
	startup costs of kernels tend to be entirely elsewhere).

	So I suspect -Os tends to be more appropriate for user-mode
	code, and especially code with low repeat rates. Possibly the
	"low repeat rate" thing ends up being true of certain kernel
	subsystems too.

	Think of it this way: if you win 10% in size, you're likely to
	map and load 10% less code pages at run-time. Which is not a big
	issue for traditional data-centric loads, but can be a _huge_
	deal for things like GUI programs etc where there is often more
	code than data.


Я решил провести собственное "userland" небольшое исследование.  Для
этого я пересобрал пакеты dillo и perl с "%define _optlevel s".

dillo -O2:
300792	/usr/bin/dillo
217358	dillo-0.7.1-alt1.i686.rpm

dillo -Os:
247544	/usr/bin/dillo
206148	dillo-0.7.1-alt1.i686.rpm

perl -O2:
1213020	/usr/lib/libperl.so.5.8
3345684	perl-5.8.0-alt1.1.i686.rpm
1400875	perl-base-5.8.0-alt1.1.i686.rpm
820888	perl-devel-5.8.0-alt1.1.i686.rpm
44051	perl-suidperl-5.8.0-alt1.1.i686.rpm
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 37 wallclock secs (37.05 usr +  0.01 sys = 37.06 CPU) @ 28294.01/s (n=1048576)
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 36 wallclock secs (36.84 usr +  0.00 sys = 36.84 CPU) @ 28462.98/s (n=1048576)
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 37 wallclock secs (37.00 usr +  0.01 sys = 37.01 CPU) @ 28332.23/s (n=1048576)
$

perl -Os:
1057258	/usr/lib/libperl.so.5.8
3333843	perl-5.8.0-alt1.1.i686.rpm
1345924	perl-base-5.8.0-alt1.1.i686.rpm
818170	perl-devel-5.8.0-alt1.1.i686.rpm
42578	perl-suidperl-5.8.0-alt1.1.i686.rpm
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 35 wallclock secs (34.19 usr +  0.00 sys = 34.19 CPU) @ 30669.08/s (n=1048576)
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 34 wallclock secs (34.33 usr +  0.00 sys = 34.33 CPU) @ 30544.01/s (n=1048576)
$ perl -MBenchmark -e 'timethis(2**20, "\$y=sin(3.14)+cos(3.15);\$y=~s/\$y/./igs;")'
timethis 1048576: 34 wallclock secs (34.33 usr +  0.01 sys = 34.34 CPU) @ 30535.12/s (n=1048576)
$

Машина Celeron333.

Выглядит очень привлекательно: размер бинарей уменьшается на 10-20%, а
падение производительности: у ядра почти не падает, а у перла -- в
данном частном случае растёт на 8-9%!!!!!!  Скорее всего, это именно
из-за маленького кэша у Celeron'а.  При этом измеряется некая
абстрактная производительность в идеальных условиях; в реальных условиях
реальная производительность может расти ещё больше.

Кроме того, уменьшается (хотя и не так сильно) размер RPM пакетов, что
достаточно важно как для подготовки однодисковых дистрибутивов, так и
для уменьшения интернет-трафика.  А также для создания минимальных
систем! :)

Какие будут мнения?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: gcc -O2 vs gcc -Os performance

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

On Wed, Mar 12, 2003 at 04:56:16AM +0300, Alexey Tourbin wrote:
> Какие будут мнения?

Для начала сделать rpm macro?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [devel] gcc -O2 vs gcc -Os performance

[Victor Forsyuk]

On Wed, Mar 12, 2003 at 04:56:16AM +0300, Alexey Tourbin wrote:
> Greetings!
> 
> Subj: по мотивам одноименной истории из linux-kernel -- см. тред
> http://lists.insecure.org/lists/linux-kernel/2003/Feb/0984.html

[..skip...]

> Машина Celeron333.
> 
> Выглядит очень привлекательно: размер бинарей уменьшается на 10-20%, а
> падение производительности: у ядра почти не падает, а у перла -- в
> данном частном случае растёт на 8-9%!!!!!!  Скорее всего, это именно
> из-за маленького кэша у Celeron'а.  При этом измеряется некая
> абстрактная производительность в идеальных условиях; в реальных условиях
> реальная производительность может расти ещё больше.
> 
> Кроме того, уменьшается (хотя и не так сильно) размер RPM пакетов, что
> достаточно важно как для подготовки однодисковых дистрибутивов, так и
> для уменьшения интернет-трафика.  А также для создания минимальных
> систем! :)
> 
> Какие будут мнения?

Звучит впечатляюще. Что важно, уменьшение размера способно положительно
влиять на производительность именно на малокешевых, бюджетных процессорах -
для которых пусть и маленькое, но улучшение более важно, чем для "крутых"
процессоров, производительности которых обычно с головой хватает для
выполняемых задач.

Если же -Os способно заметно по ощущениям ускорить startup таких монстров
как KDE - и вовсе замечательно будет.

[devel] Re: gcc -O2 vs gcc -Os performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Wed, Mar 12, 2003 at 10:37:11AM +0200, Michael Shigorin wrote:
> > Какие будут мнения?
> 
> Для начала сделать rpm macro?

Макрос уже есть (%define _optlevel s).

Дело в другом.  Нужно протестировать подобным образом ещё несколько
пакетов, и если результаты будут подтверждаться, можно будет выставить
его по умолчанию.

Только тестирование должно быть независимым, т.е. его должен делать
не я. :)


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: gcc -O2 vs gcc -Os performance

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Wed, Mar 12, 2003 at 03:57:05PM +0200, Victor Forsyuk wrote:
> Звучит впечатляюще. Что важно, уменьшение размера способно положительно
> влиять на производительность именно на малокешевых, бюджетных процессорах -
> для которых пусть и маленькое, но улучшение более важно, чем для "крутых"
> процессоров, производительности которых обычно с головой хватает для
> выполняемых задач.

"Крутые процессоры" -- это тоже абстракция, потому что крутые машины
обычно не простаивают, на них "толкается" большое число процессов.
В этом смылсе L1/L2 кэш и RAM никогда не бывают лишними, потому что их
всегда можно использовать более эффективно (например, несколько лишних
страниц под буферный кэш вместо RSS).  Это же тоже выигрыш, хотя он и не
является "оптимизацией" в специфическом смысле.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: gcc -O2 vs gcc -Os performance

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hello Victor,

On Wed, Mar 12, 2003 at 03:57:05PM +0200, Victor Forsyuk wrote:
>
> > Машина Celeron333.
> > 
> > Выглядит очень привлекательно: размер бинарей уменьшается на 10-20%, а
> > падение производительности: у ядра почти не падает, а у перла -- в
> > данном частном случае растёт на 8-9%!!!!!!  Скорее всего, это именно
> > из-за маленького кэша у Celeron'а.  При этом измеряется некая
> > абстрактная производительность в идеальных условиях; в реальных условиях
> > реальная производительность может расти ещё больше.
> > 
> > Кроме того, уменьшается (хотя и не так сильно) размер RPM пакетов, что
> > достаточно важно как для подготовки однодисковых дистрибутивов, так и
> > для уменьшения интернет-трафика.  А также для создания минимальных
> > систем! :)
> > 
> > Какие будут мнения?

Мне неинтересно, у меня Pentium 4 :)
По мне, наоборот, лучше -O3 (с inlining'ом и пр.),
каковой я уже давно практикую.

> Если же -Os способно заметно по ощущениям ускорить startup таких монстров
> как KDE - и вовсе замечательно будет.

KDE компилятор не поможет -- там генерация кода, диктуемая C++,
раздувает размеры и таблицы relocation (очень чувствительная
вещь для startup).

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Love makes the world go 'round, with a little help from intrinsic angular
momentum.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: gcc -O2 vs gcc -Os performance

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 2829 bytes --]

On Thu, Mar 13, 2003 at 01:57:09AM +0300, Mikhail Zabaluev wrote:
> Мне неинтересно, у меня Pentium 4 :)
> По мне, наоборот, лучше -O3 (с inlining'ом и пр.),
> каковой я уже давно практикую.

Цифры?  Здесь только цифры имеют значение.  Вы можете запустить
прилагаемый тест на вашем P4?  Только честно. :)

В тесте используются:

- компилятор gcc-3.2.1-alt2
- bzip2-1.0.2-alt7 как пает для тестирования (*в spec-файле нужно
  предварительно закомментировать _optlevel*)
- openoffice-1.0.2-alt2.src.rpm, как пакет, содержащий очень большой
  bz2 файл
- машинка Cel333/128RAM; конечно, это не P4/1G, но, по моим ощущениям,
  таких машинок сейчас много; кроме того, базовая платформа у нас вообще
  i586

Результаты теста:

TEST FOR -O0
243.95user 1.10system 4:05.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (111major+912minor)pagefaults 0swaps
243.75user 1.12system 4:05.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (111major+912minor)pagefaults 0swaps
243.57user 1.34system 4:05.48elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (111major+912minor)pagefaults 0swaps
TEST FOR -O1
163.39user 1.31system 2:45.19elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (104major+912minor)pagefaults 0swaps
163.44user 1.40system 2:45.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (104major+912minor)pagefaults 0swaps
163.82user 1.13system 2:45.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (104major+912minor)pagefaults 0swaps
TEST FOR -O2
170.76user 1.29system 2:52.77elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (105major+912minor)pagefaults 0swaps
171.07user 1.08system 2:52.64elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (105major+912minor)pagefaults 0swaps
171.04user 1.14system 2:52.73elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (105major+912minor)pagefaults 0swaps
TEST FOR -Os
152.55user 1.25system 2:34.23elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps
152.54user 1.20system 2:34.26elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps
152.76user 1.13system 2:34.35elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps
TEST FOR -O3
169.54user 1.39system 2:51.54elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps
170.00user 1.03system 2:51.62elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps
169.74user 1.20system 2:51.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (106major+912minor)pagefaults 0swaps

Похоже, что -Os является наиболее удачным набором оптимизаций.

[-- Attachment #1.2: bztest.sh --]
[-- Type: application/x-sh, Size: 336 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: gcc -O2 vs gcc -Os performance

[Igor Homyakov]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]


* Alexey Tourbin <at @ altlinux . ru> [030509 13:29]:

> - компилятор gcc-3.2.1-alt2
> - bzip2-1.0.2-alt7 как пает для тестирования (*в spec-файле нужно
>   предварительно закомментировать _optlevel*)
> - openoffice-1.0.2-alt2.src.rpm, как пакет, содержащий очень большой
>   bz2 файл
> - машинка Cel333/128RAM; конечно, это не P4/1G, но, по моим ощущениям,
>   таких машинок сейчас много; кроме того, базовая платформа у нас вообще
>   i586

Немного изменил скрипт, sync у меня делается в цикле перед bzcat и увеличил
число итераций. сборки для i586/i686/pentium3. Результаты меня **немного**
удивили.

Вот мои результаты (PIII/384Mb).

P.S.
    Оказывается "-Os" рулит ....
-- 
Igor Homyakov
<homyakov at altlinux dot ru>
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=190141

[-- Attachment #2: bz_bench.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 856 bytes --]

[devel] Re: gcc -O2 vs gcc -Os performance

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

Hello Igor,

On Wed, May 14, 2003 at 11:07:56AM +0400, Igor Homyakov wrote:
>
>     Оказывается "-Os" рулит ....

... для bzip2. Для более определённого ответа нужна разнообразная
смесь задач.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
(1) Everything depends.
(2) Nothing is always.
(3) Everything is sometimes.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: gcc -O2 vs gcc -Os performance

[Igor Homyakov]

* Mikhail Zabaluev <mhz@altlinux.org> [030514 14:21]:
> Hello Igor,

> On Wed, May 14, 2003 at 11:07:56AM +0400, Igor Homyakov wrote:
> >
> >     Оказывается "-Os" рулит ....

> ... для bzip2. Для более определённого ответа нужна разнообразная
> смесь задач.

Согласен, давайте делать тесты !

-- 
Igor Homyakov
<homyakov at altlinux dot ru>
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=190141

Re: [devel] Re: gcc -O2 vs gcc -Os performance

[Igor Homyakov]

* Mikhail Zabaluev <mhz @ altlinux.org> [030514 14:21]:
> Hello Igor,

> On Wed, May 14, 2003 at 11:07:56AM +0400, Igor Homyakov wrote:
> >
> >     Оказывается "-Os" рулит ....

> ... для bzip2. Для более определённого ответа нужна разнообразная
> смесь задач.

предлагаю проверить на сборке ядра, соответственно пересобирать
(-O{0,1,2,3,s}) надо будет gcc

-- 
Igor Homyakov
<homyakov at altlinux dot ru>
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=190141

[devel] Re: gcc -O2 vs gcc -Os performance -- gcc-3.3

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On Wed, May 14, 2003 at 02:38:26PM +0400, Igor Homyakov wrote:
> предлагаю проверить на сборке ядра, соответственно пересобирать
> (-O{0,1,2,3,s}) надо будет gcc

Кстати два дня назад вышел gcc-3.3.  Его на тему оптимизации ковыряли,
так что там могло что-то измениться.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]