Vlákno názorů k článku
GCC 5 kompiluje rychle, pořád ale zaostává za Clangem
od Mirda - Technicky vzato se průměrný program kompiluje v poměru...
-
Mirda (neregistrovaný)
Technicky vzato se průměrný program kompiluje v poměru 1:1000000000000, tento poměr udává počet kompilací vůči počtu běhů. A zároveň to znamená, že je poměrně jedno, jak dlouho se ten program bude kompilovat, protože co je důležité, je to, jak rychle ten program běží. Asi by nebyl problém ani s 20-ti minutovou kompilací, kdyby tento program pak běžel 10x rychleji než při kompilaci běžné.
Takže se ptám a to na to nejpodstatnější, jaký je rozdíl v rychlosti běhu jednotlivých programů pod těmito prohlížeči a proč to tu není uvedené.
-
Ondra Satai NekolaZlatý podporovatelTo je pravda tak na pul. Kdyz vyvijis, tak je pro tebe setsakra dulezita rychla zpetna vazba mezi tim, co jsi udelal a jak se to projevi. A naopak je casto rychlost vysledku celkem nepodstatna, dulezite je, ze vypadne spravny vysledek v rozumnem case a ze by mohl vypadnout za polovinu casu nikoho nezajima...
Pod jakymi prohlizeci?
-
Karel (neregistrovaný)
To se vracíte do doby sálových počítačů. Programátor několik dní programuje, pak předá výsledek týmu "od překladačů" a jde domů. Druhý den se pak dozví výsledek.
Dnes se programuje obvykle trochu jinak. Dnes programátoři běžně používají kompilátor na test syntaxe. Běžně se udělá kompilace, spustí se sada testů a pak se pracuje dále. Představa, že by se na výsledek kompilace čekalo 20 minut, je dost děsivá. Proto se jde opačným směrem - snažíme se o co nejrychlejší kompilaci, používáme metody, kdy není potřeba program kompilovat vždy celý apod.
Co vy popisujete je až ten poslední krok, kdy se kompiluje verze pro zákazníka. Jenže to je něco, co já jako vývojář, dělám jen dvakrát do roka.
-
Mirda (neregistrovaný)
Nojo, jako programátora mě zajisté zajímá, jak rychle to bude zbastlené, protože místo čtení kódu zkouším a mačkám F5. Takže nějaký QUICK překlad potřebuji, ALE programátor je jen šmudla, který to ušmudlí. Používá to uživatel a tam se šetří výpočetní výkon, resp. je nejvíc vidět přínos rychlosti.
-
Petr M (neregistrovaný)
Člověk trpí selektivní slepotou a nepostihne všechny aspekty. Když se zaměří na středníky na koncích řádků, může přehlídnout třeba neinicializovaný pointer, když kontroluje inicializaci proměnných, nevidí třeba přetečení proměnné... Musel by kontrolovat jedno po druhým a to by byly hodiny čtení.
Proto je standardní postup po změně v kódu build s volbou -wall a unit test. Commit až ve chvíli, kdy je bez jediné chyby v logu překladu a nepadají unit testy. Viz defenzivní programování, TDD, DDT,...
A ještě jedna věc, rychlý kompilátor zlepšuje kód. Kdyby se to kompilovalio hodinu a měl bych za 20 minut skončit v práci, tak si řeknu "opravím to zítra" a druhý den bude něco důležitějšího... A kód v klidu hnije...
Mimochodem, ten zmíněný poměr je někde jinde. Když třeba započítám starty systémů pro řízení JE nebo telekomunikační družice... (i když to se v Clangu nepíše....)
-
Ondra Satai NekolaZlatý podporovatel
Jak už nade mnou píše Petr, to není šmudlání, to je nutnost.
Ideální zpětná vazba jsou pro cyklus write/compile/test maximálně sekundy, jinak s ztrácí pozornost programátora.
-
Ondra Satai NekolaZlatý podporovatel
Ne nutně to musíš použít, ale když už chceš, tak je tahle rychlá zpětná vazba nutná. Čekat tak deset sekund už svádí k tomu začít řešit něco jiného ab začít multitasking.
Btw vy najedete tdd, že?
-
Ondra Satai NekolaZlatý podporovatel
TDD není pro každého. Ale je to příklad situace, kdy se některé požadavky projeví naplno.
-
j (neregistrovaný)
Nevim, prganim se primarne nezivim, takze jsem v tom oboru amater, ale kdyz neco pisu, tak treba hodinku ci dve kodim, pak to zbezne probehnu vizuelne, kouknu co mi to kde hlasa za syntakticky chyby .... a teprve pak pustim kompilaci a jdu vyzkouset co sem napsal. Rozhodne me pak nevytrhne, jestli se to bude kompilovat minutu nebo dve (nebot se kompilujou jen zmeny, zbytek se linkuje s uz prekompilovanejma zdrojakama). Stejne si nejspis pudu udelat kafe.
A (kupodivu) kdyz si treba kompuluju modul do uz prekompilovanyho kernelu, tak ze behem minutky slozi cely jadro ... divny.
Co by me ale nasralo zarucene, kdybych neco kompiloval 10x a i podesaty to hlasilo chyby ve zcela nicnedelajicim zakomentovanym kusu kodu (coz jak z diskusi vyplyva je prave velmi blizke tomu, jak funguje clang).
...
BTW: Zmena v SQL where cosi = 1 na cosi = 0. Doba realizace ... mesic. Pocet pokusu ... asi 15. Nastroj ... .NET. ... i takhle funguji nekteri dodavatele. Ale jelikoz sem nekolikrat mel tu cest ty M$ nastroje videt in natura, tak se ani nedivim. Zmenit query ve zdrojaku bez toho, aby dotycny mel pristup k databazi ... prakticky nemozne. Zmenit jej s pristupem k databazi == smazat cely konektor a vytvorit novy. Proste lol. -
j (neregistrovaný)
Vazne bych chtel videt, jak se neco kompiluje 20x rychleji .... Pokud dobre vidim, uspora neni ani 50%. Takze rozdil bude na tema 20m vs 15m a to jeste ve velmi specifickych pripadech. A jelikoz to je tak +- doba, za kterou se prekompiluje celej cerstvej (=nepredkompilovanej) kernel navrch na obstaroznim HW, coz jsou miliony radku kodu, tedy pomerne velmi rozsahly projekt ...
-
Karel (neregistrovaný)
Chápu to správně, že vývoj aplikací pro mobilní telefon provádíte přímo a pouze na mobilním telefonu? Se stylusem, nebo patláte po displayi?
Protože jiné vysvětlení vašeho skálopevného názoru, že pro build verzi a development verzi musím v každém případě použít naprosto stejná nastavení kompilace a optimalizace, nenacházím.
