Názory k článku GCC 3.0

Tak tenhle clanek me vylozene potesil, dobra prace!

Tento clanok je ako pohladenie po dusi v porovnani s tym nedavnym clankom o Amige pri ktorom som skoro dostal srdcovy zachvat. Keby boli vsetky clanky na Root-e taketo kvalitne... Zostava iba dufat, ze sa najde viac skutocnych znalcov ochotnych napisat poriadne clanky.

Jen bych se rad autora zeptal, na Kernel-Devel vsichni
kdo testovali gcc3.0 tvrdi ze doslo k 10% zpomaleni
vysl. kodu, vi se o tom ?

O primo techto testech nevim, ale jinak je samozrejme nekolik testu
co se zhorsilo. Vetsinou s trochou trpelivosti to jde odstranit pouzitim napriklad -mpreferred-stack-boundary=2 ci -maccumulate-outgoing-args a podobnymi triky.
Problem v kernelu bude zejmena prerovnavani bloku, takze asi -mno-reorder-blocks.

Jak jsem v clanku psal, kvalita kodu je problematicka, snad priste :)

Pouzivam verzi 2.95 (KDevelop 1.4) a vadi mi ze GCC defaultne u funkci typu:

void a(int b)
{
}

hlasi warning ze parametr b nebyl vyuzit. U promennych je to v poradku ale u parametru by se warning podle me mel objevit az na pozadani. Borland a VC toto defaultne nehlasi. Take mi vadi ze nejsou urovne warningu a musim trapne zkoumat kazdy jednotlivy warning zda ho mam zapnout nebo vypnout.

Zde by to podle mne ten warning hlasit urcite melo. Chcete-li tomu zabranit, napiste:
void a(int )
{}

Souhlasim s tim, ze warning by se objevit mel, ale Vase konstrukce neprojde v C (v C++ ano). Schvalne to zkuste.
Resenim je spise __attribute__((unused)) nebo ekvivalentni makro.

No jo, ale kdyz do zdrojaku budu psat takove nesmyslne pragmy uz to nebude prenositelny :-(. A kdyz uz jsem tady mam jeste par pripominek:

1. Srovnavani unsigned a signed promennych by nemelo defaultne davat warning, to souvisi s prvnim prispevkem ktery jsem napsal.
2. Hlaska pri chybe je vetsinou mirne matouci a troufnu si tvrdit ze jine prekladace lepe vysvetli uzivateli co udelal blbe.

Jinak jako byvaly uzivatel VC a BC musim rict ze i pres pocatecni neduveru GCC se mi libi. Jeste to trochu "zuserfriendlit" a nebude to mit chybu. Pro me osobne je komfort prace s prekladacem (hlasky, warningy, moznosti nastaveni) dulezitejsi nez par procent vykonu.

Tak tam flakni
b = b;

A je to kompatibilni a bude (nejspis) vyoptimalizovano. ;)

Ad kvalita kodu:
Dokaze si nekdo predstavit, ze by GCC umelo optimalizovat pro nekolikacestnou pipeline Athlonu?
To by byl narez! Misto toho pridali nejaky Japonsky CPUs
o kterejch nikdo nikdy neslysel. Ach jo.

Gcc Athloni pipeline rozumi, ale zisky nejsou nejvetsi, jelikoz Athlon
si prerovnava sam a tak toho gcc uz tolik nenahoni.
Ve vyvoji je novy scheduler co umi lepsi popis, ale i ten neprinasi
podstatna zlepseni.

Chcel by som sa spytat, ci nekde je nejake porovnanie kompilatorov gcc, a inych( napr VC od MS, borlandacke veci a tak),alebo tie programy, co boli pouzite v teste,ktoreho vysledky su v clanku, su niekde? Inak fine clanok.Dik.

Benchmarky jsou nekde na www.byte.com, ale neni to dobry test
(prilis jednoduchy). Co se tyce vykonu, ma zkosenost je, ze inteli
C generuje lepsi kod (i desitky procent), visual C++ srovnatelny

Jeste upresnim. Co se tyce benchmarku, zalezi na programu. U specint2000 na Athlonu gcc trhne Intel C i Visual C v mnoha testech,
v jinych ale zase ne.
Celkove je Intel C 8% lepsi, visual C 10% horsi, borland C jsem netestoval.

Tohle je ale hodne vagni a neoficialni porovnani :)

U specFP je Intel C asi 20% lepsi, Visual C asi 3% lepsi.

V clanku se pise, ze existuje nekolik implementaci PCH pro GCC. Daji se nekde stahnout a vyzkouset?

Jednu z nich obsahuje NextStep (a po nem to zdedily dalsi applovske
systemy), ale ta do oficialniho stromu nepujde. Ostatni pokud vim ke stazeni nejsou.

Rozhodl jsem se zkusit gcc 3.0.0 v distribuci kterou sam stavim pro sve vlastni potreby, a dopadlo to zalostne. Zkompiloval jsem staticky linkovanym gcc (linkovane s glibc 2.2.2 z RH 7.1) knihovny glibc 2.2.3, pote jsem zkompiloval gcc 3.0.0 na novych knihovnach. Vse fungovalo do doby, nez jsem zkompiloval dynamicky fileutils-4.1 - segmentation fault u ls kdesi hluboko v threadove knihovne, naprosto stejny segmentation fault v nove zkompilenem make. Vratil jsem se ke staticke fazi a pouzil gcc 2.95.3 a k zadnemu SIGSEGV nedochazi.

Pokud vim, tak gcc 3.0 vyrabi binarne nekomatibilni glibc, ale chyba
neni na strane gcc.
Bude rozumne pockat, az to gblic vyvojari opravi.

Diky za clanek, je fakt dobry. Jen nerozumim teto vete:

Například u KDE aplikací po zapnutí podpory výjimek implementované v gcc 2.95 čas zavádění programu stoupne několikanásobně.

Opravdu se KDE zpomali? Podle smyslu toho odstavce by se melo zrychlit, ne?

Jde o to, ze kdyz nekdo prelozil kde s vyjimkama, tak bylo nesnesitelne lenive. U gcc 3.0.0 uz cena za vyjimky neni tak velka.

podporuje prepracovany stdlib uz "streams" a "locales" templates, nebo zatim porad jen "containers"

streamy ma, jestli locales, to netusim.