Mamy nowe gcc4!. Już zbudowałem i wykonałem parę testowych kompilatów. Objętość samego GCC trochę wzrosła, pakiet 3.4.3 zajmował mi 48.63MB. 4.0.0 zajmuje już 51.39MB. Sam upgrade poszedł gładko, Hierophant nie narzekał na niespełnione zależności, więc chyba nie muszę się martwić o rekompilowanie programów używających libstdc++ ani inne takie...

Dwa szybkie testowe kompilaty dają interesujące wyniki. Paczka z ROX-Filerem po rekompilacji zmieniła rozmiar, z 980KB przeszła do 956KB. Albo to ogólna poprawa, albo flaga -Os znowu zwiększyła skuteczność (w serii gcc3 -Os z wydania na wydanie generowało coraz mniejszy kod :). IceWM podobnie, z 1.33MB zeszło do 1.27MB. Teraz leci mi kompilat gimpa, ciekawe czy on też się zmniejszy (i o ile...). Aha, MPlayer nie daje się skompilować. Po pierwsze trzeba mu wymuszać opcją ./configure uznanie w ogóle gcc4, po drugie chyba coś asemblerowego się wykłada przy kompilacji. Ale skoro gcc4 jest już oficjalny, to chłopaki z mplayera pewnie poprawią to w CVS "na dniach" (poprawią albo i nie, cholera ich wie). No miel-że się gimpie... ileż można...

Popełniłem błąd. Nie zbenchmarkowałem starego gcc przed upgradem. Szkoda, bo mógłbym ocenić czy "compilation time" się skrócił. Mam tylko taki jeden zapis z budowania kernela:

make all  282.29s user 19.01s system 92% cpu 5:25.26 total

Ale zweryfikowanie tego może być trudne, bo przy objętości kernela spore różnice może powodować choćby buforowanie plików na dysku...

...o, HBS z gimpem wszedł w fazę tworzenia pakietu końcowego. No to za chwilkę poznam wielkość nowej paczki. Gimp zbudowany przez gcc-3.4.3 miał 14.12MB (po wycięciu plików nagłówkowych itp.). A ten nowy ma... 13.76MB. No proszę. Czyżby nowe GCC wszędzie skutecznie generowało mi ciut mniejszy kod?

OK, to może jeszcze spróbuję ten kernel... benchmark był robiony po kompilacji, "make clean" i powtórnej kompilacji IIRC... a, nie, nic z tego:

In file included from drivers/i2c/i2c-core.c:29:
include/linux/i2c.h:58: error: array type has incomplete element type
include/linux/i2c.h:197: error: array type has incomplete element type

Czyli nie da się zbudować 2.6.11.7 za pomocą gcc4, a przynajmniej nie przy włączonym i2c. Może w którymś 2.6.12-pre to jest już poprawione? W changelogach przewijają się czasem poprawki pod gcc4...

...gqview-2.1.0... z 1.28MB zeszło do 1.24MB... glib 1.16MB->1.13MB, atk 272KB->268KB, pango 808KB->800KB. Na gtk+ nie mam teraz czasu, ale sprawdzę jeszcze xpdf, to C++, jego binarka ma teraz u mnie 776576 bajtów. Rozmiar całego pakietu zszedł z 4.10MB->3.94MB, a sama binarka /usr/bin/xpdf ma teraz 750080 bajtów.

No dobra, nie mam już czasu na zabawy. Wieczorem może skompiluję sobie Ognioliska i spróbuję ocenić też ew. zmiany w wydajności, choć nie sądzę by były widoczne gołym okiem. Otwarte pozostają nadal kwestie usterek typu "-Os konfliktuje z SSE/SSE2 (np. przy -march=athlon-xp) w glxgears czy gtk+" - ciekawe czy w nowym gcc4 ten problem zniknął już? Na te i inne pytania spróbuję niedługo odpowiedzieć. Stay tuned ;)

PS. W związku z wiosną motywem przewodnim FPR ogłaszam lody. Tak. Lody zamiast piwa ;)

Od: bies
Data: 20050422, 17:04
Szybki jesteś Waść. Ja dopiero dziś zobaczyłem notkę w RSS-ie Siódmego Strażnika. Na informacje o ew. polepszeniu wydajności oczywiście czekam. Ale dla mnie najważniejsza jest zgodność ze standardem ANSI C++ i dodanie strażników (sentinel). Temu trzeba się dokładnie przyjrzeć.

Sam fakt dodania uwag z TR1 też jest miły. Ech, żeby tylko wiedzieć co z nich zostanie w C++0x.

Od: Anonimowy koorek
Data: 20050424, 00:52
Ziew, gentuserzy juz zacieraja rece bo beda mieli nowy argument za tym, ze gentoo jest o niebo szybsze niz wszystko inne co czlowiek wymyslil. Coz, takie zycie, tzreba chyba juz tych gentuserow zaakceptowac bo na walke z nimi to mi juz sil brakuje ;-)