Názory k článku
GCC 5 kompiluje rychle, pořád ale zaostává za Clangem
-
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.
-
Ondra Satai NekolaZlatý podporovatel
Zalezi na okolnostech, viz vyse.
Nekdy je preferovana vlastnost rychlost prekladu, jindy rychlost vysledneho kodu. -
Peter FodrekZlatý podporovatelNa to stale nioe je jednoznacna odpoved
Clang 3.4 offered faster performance of compiled C/C++ code in several areas but GCC 4.9 also brings some performance improvements of its own over the current stable release. Clang still certainly outperforms GCC when it comes to compile times, but aside from that the compiler performance competition is rather mixed depending upon the particular code-base, workload, and processor.
http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=5su tu vysledky., kde je gcc o 15-20% rychlejsie ale aj vysledkuy, kde je kod spompilovany Clang/LLVM o 78% rychlejsi
http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=5
a
http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=3
-
Ondra Satai NekolaZlatý podporovatel
To se lepe rekne, nez udela. Zavislosti v kodu tvori (s trochou stesti acyklicky ;) ) graf a pruchod skrz nej se neda paralelizovat dle libosti.
-
rade-brno (neregistrovaný)
Ano - presne tak... O zbastleni nejakeho skriptu na paralelní kompilaci a nasledne "neparalelni" slinkovani jsem uz take uvazoval... (neco podobneho sem delal pri simulacich v Matlabu na vicejadrovych masinach pripadne na vice ruznych masinach, kdy se vystupy ukladaly do slozky v dropboxu a na závěr se z toho sestavily vektorove grafy - navic se do slozky drop boxu ukládály do textovych souboru prubezne informace o simulacich, takze "pan vedator" mel prehled o tom co se deje pěkně v mobilu) Jedine, co me od podobne vychytavky usite na miru c++ odradilo bylo to, ze po IT cistce sem dal pryc vsechny desktopy a pro jednojadrovy 4 roky stary NB s Atomem to nema cenu delat...
Ale nebylo by to nic sloziteho:
* v projektu (uvažujme IDE Code::Blocks) zakazu kompilaci vsech cpp souboru...
* nastavim cestu ke scriptu, ktery se ma pustit pred kompilaci...
* tento skript projde adresar a pro kazdy cpp soubor vytvory samostatny skript, ktery jednak provede kompilaci daneho cpp (treba main.cpp), ale po kompilaci take vytvori prazdny soubor main.cpp.done
* smazou se vsechny *.done soubory po predchozi kompilaci
* pusti se vsechny scripty (ktere byly vygenerovany pro kompilaci) s parametrem " &" (vse pojede na pozadi) a pak uz se jen v cyklu (se sleepem) kontroluje existence vsech *.done souboru...
* ve chvili, kdy existuji vsechny *.done soubory, muze se linkovat...Na 4 jadru by to byl hukot...
Zajiste zjišťovat stavy pres soubory neni elegantni, na druhou stranu je tím vyresen paralelni zapis/cteni do "sdílené pameti"...
Vetsi projekty se deli do podadresaru, ale není problem najit vesksre cpp SOUbory i takto zanorene...
Bylo by potreba poladit hodne drobnosti, ale pak by to byl hukot... :-) -
rade-brno (neregistrovaný)
No a jak tak koukam, tak zrovna Code Blocks umi paralelne kompilovat, to musím co nejdriv prověřit: http://forums.codeblocks.org/index.php?topic=15529.0
-
. (neregistrovaný)
???
Pokud řídíte kompilaci pomocí Makefile, existuje tu přepínač
make -j
Pokud má příslušný Makefile soubor správně udělané závislosti,
pustí se vše co se pustit muže a jak dobíhají předpoklady, pouštějí
se postupně závislé úlohy. Pochopitelně u větších projektu to spolehlivě
zavaří CPU, proto je dobré omezit maximální počet paralelně puštěných
úlohmake -j N
N se mi osvědčilo jako počet CPU x 2. Záleží ale na projektu a vkusu.
(man make)
-
OMG (neregistrovaný)
Potká se Pentium a 486 a 486 se ptá, kolik je 3 + 1. Pentium odpoví 5, 486 po chvilce přemýšlení povídá “to je ale špatně”, načež Pentium opáčí “to je jedno, hlavně, že je to rychle”.
Pokud se jedna o rozsahle projekty, existuje distribuovana kompilace. Pokud se jedna o uzivatelske aplikace, pak rychlost kompilatoru je irelevantni a pokud na ni poukazuji developeri jako na nutnost testu syntaxe, pak budto pouzivaji hloupy editor, nebo pracuji na spatne pozici.
-
koudy (neregistrovaný)
Děkuju! Naprostý souhlas :)
Už jsem se lek, že nad kódem přemýšlím nějak špatně, když mi vymyslet a napsat trvá o poznání déle než trvá kompilace.I pokud dělám na větším projektu, většinou provádím částečný build a jednou za čas je dobrá výmluva "kompiluju" http://xkcd.com/303/
-
Karel (neregistrovaný)
A vidíte, fakt, že vám to vymyslet a napsat trvá tak dlouho, by měl vašeho nadřízeného postavit do pozoru. Buď jste velmi pomalý a drobná úloha vám trvá věčnost, nebo naopak sekáte několik úloh najednou a pak doufáte, že v tom není chyba. Častější je ten druhý případ. To jsou lidé, kterým to po kompilaci padá a oni neví kde začít. S argumentem "no, ještě v říjnu to fungovalo" a smutným konstatováním, že netuší která z těch 23 úprav to rozbila, protože to netestoval po každé úpravě ale až teď po dvou týdnech.
-
koudy (neregistrovaný)
COTO?
To by mě zajímalo jak můžete po 3 větách vědět nad jakými problémy se zamýšlím a jak pracuji? :)
To o nadřízeném nebudu komentovat vůbec..."Trvá tak dlouho" jsem měl v poměru ke kompilaci a ta trvá pár sekund. ( a to určitě ještě přeháním, neskočím si ani pro kafe, při full buildu to na to kafe je jen tak tak )
Jsem programátor, ne čaroděj, nedoufám že něco funguje, ověřuju si to.@Petr M - noční build nemáme, pro způsob jakým vyvíjíme je to nepoužitelné. ( ostrá verze se vydává jednou za x, vždy na vyžádání od zákazníka )
kde x je velmi proměnlivé -
-
koudy (neregistrovaný)
:) líbí se mi, Váš přístup k problému!
Nevyvíjím pro běžného Frantu uživatele, proto nejde používat běžné postupy.
Nový SW si nasazuje zákazník na své produkční stroje, po jeho otestování.V mém případě nevidím přínos v buildu po každé změně. (je nutné mít aplikace ve stejné verzi jako má zákazník, kvůli testům/stížnostem/opravám/hledání chyb/...)
Samozřejmě se mohu plést a rád si poslechnu cizí názor/zkušenosti.
-
Ondra Satai NekolaZlatý podporovatel
Ty buildy po kazde zmene se nemuseji nutne nikde pouzivat (mimo nejakych automatickym testum), obvykle se archivuje poslednich par a pak se to odmazava. Dulezite jsou spis protoze kdyz nekdo pushne chybu (at uz rozbijejici v zakladu kompilaci, rozumneji atutomaticke testy), tak mu za chvili prijde mail s upozornenim. Detekuje se, ze stav v repu je nejaky podezrely.
-
koudy (neregistrovaný)
Není nad to otočit se na kolegu a říct "ty vo*e co jsi to dal do toho gitu?" ( vyvíjíme v 5 lidech, takže má člověk přehled, kdo s kým a za kolik - teda kdo na čem pracuje )
Většinou se snažíme do gitu dávat funkční celky a je domluva, že se úpravy "pushují" (sorry češtino) až když mi to chodí v testu a dělá to co má.
Kupodivu to zatím celkem dobře funguje.Chápu, že když se vyvíjí v 20+ lidech, je to o něčem jiném, u nás by ten přínos pravděpodobně nebyl až tak markantní a nevím zda bych to protlačil jako projekt, ale díky za rozumnou argumentaci, musím Vám dát za pravdu, že by se mi něco takového taky líbilo.
-
Petr M (neregistrovaný)
Ok, Franta a Lojza si stáhnou aktuální kód a každý nezávisle implementuje do jinýho modulu nějakou funkcionalitu. Oba použijí nějakou globální proměnnou, třeba status, a exportují z modulu přes external. Každá je jinýho typu, jeden použije enum, druhý char. Oba si to odzkouší, jede jim to a práci komitnou do repozitáře a jede se dál.
V pátek dojde šéf, že je potřeba do pondělka poslat release. Do konce šichty 5h, testování na 4h, domluvený, že vyzvedneš manželku s dětma a jedete na zaplacený víkend v zahraničí. Kliknete na Build a najednou 170 chyb i když oba pánové měli svůj lokální build v pořádku. Refaktor->Rename není možno použít, jmenuje se to přece stejně...
Oproti tomu použít oddělenou větev v GITu se zdrojákama pro release + skript pro vyčištění adresáře, stažení posledních zdrojáků z vývojové větve, build a kontrolu přítomnosti ELF hozený do cronu prakticky nic nestojí a zjistí se to do druhýho pracovního dne bez stresu...
NB má smysl už od dvou lidí, kteří editují zdrojáky.
-
koudy (neregistrovaný)
[OFFTOPIC]
Pro začátek: globálním proměnným je dobré se vyhýbat, pokud to jde, ale je mi jasné, že to uvádíte pouze jako příklad.Pokud počítáte s tím, že proměnou/funkci/... bude používat i někdo jiný je dobré mít domluven nějaký standard. Třeba že status bude vždy enum.
Což je celkem logický požadavek, už jen proto, že to je většinou samo-popisující.
Např.: "STAT_WE_ARE_FU*KED" asi nebude znamenat, že je vše v pořádku.
[OFFTOPIC]Tak jak je tu nastaven postup vývoje, dojde k tomu že si Franta stáhne upravené zdrojáky Lojzou, nebo opačně, k souběhu nedochází - vývojový team je tak malý, že víme co kdo dělá a jsme schopni se domluvit. Většinou ještě před tím, než se vůbec začne vyvíjet.
Kdybych testoval a zkoušel překládat 5h před odevzdáním, tak bych tu dlouho nebyl. :)
K tomu aby přišel šéf a řekl že musíme poslat build NIKDY nedojde!
Takhle to tu prostě nefunguje a ani fungovat nemůže.Náš postup vývoje je očividně naprosto odlišný od Vašeho.
Souhlasím s tím, že NB se hodí při vývoji, když na projektu dělá více lidí, nebo dělají každý v jiném časovém pásmu a podobně. ( pro open source je to asi nutnost )
Dokonce bych řekl že to má velký přínos, když vyvíjíte něco co může kdokoli testovat ( pro takový GIMP by bylo asi nepředstavitelné nemít NB )Čas vložený do odladění všech automatických testů, reportování a cron jobu (ok, tohle je pár řádek :) ) se mi prostě nevrátí.
-
Ondra Satai NekolaZlatý podporovatel
Pokud mas strach z nakladu na zavedeni, tak asi nemusis. Rozbehat jenkinse a v nem nastavit projekt je trivialni.
Ja vidim vyhodu hlavne v tom, ze kontroluje masina a ne lidi.
-
Ondra Satai NekolaZlatý podporovatel
Kdyz na to prijde, nemusis bezet na AIXu, muzes ho bezet, kde chces a nechat ho odpalovat buildy na AIXu pres ssh. Trebas...
-
Petr M (neregistrovaný)
- Pokud se jedna o rozsahle projekty, existuje distribuovana kompilace.
To jistě, můžu si třeba matematickou knihovnu nebo grafiku hodit do knihovny, definovat API a buildovat konkrétní knihovnu + aplikaci beze změn ostatních částí. Make to podporuje a nenní s tím problém. Nemá to ale smysl třeba pro 20 zdrojáků.
- Pokud se jedna o uzivatelske aplikace, pak rychlost kompilatoru je irelevantni a pokud na ni poukazuji developeri jako na nutnost testu syntaxe, pak budto pouzivaji hloupy editor, nebo pracuji na spatne pozici.
Ale ono platí "Cokoliv se samo děje, dobře se děje". Ušetřím si tím nějaký čas a eliminuju lidský chyby, takže ušetřím náklady.
Když píšu nějakou složitější funkcioanlitu, natvrdo hodím funkce a do nich kostry z (ne)existujících funkcí, protože odpovídají úrovni abstrakce. Chci todo list? Build, v reportu chyb seznam toho, co mám implementovat a ještě to v projektu není... něco dopíšu, zase build, ono se to samo aktualizovalo...
Nebo jiná forma automatickýho debilníčku:
#if COSI
...
#elif COSI_DALSIHO
...
#else
#error na cosi jsi zapomnel
#endif
Můžu vidět v IDE zašedlý všechno mimo #error. Ale jenom v případě, že je to zrovna na obrazovce. Po buildu to vidím, ať je to kdekoliv.Pak jsou i další důvody - statická aserce odhalí, že je v tabulce jiný počet prvků, než v enumu pro indexování, Statická analýza podle MISRA je taky z principu kompilace kódu, ...
A je rozhodně lepší kód, který se hlídá sám při kompilaci, než se spolehnout na syntax highlight nebo featury konkrétního IDE. Projekt / modul z něho se může udržovat třeba dalších pět, deset let a migrovat třeba na jinou platformu, takže opovrhovat kompilátorem a jeho schopností hledat chyby bych osobně považoval za nebezpečnější, než 20x denně mačkat na BUILD.
Dobrý pogramátor se chybám aktivně brání a cokoliv mu s tím pomůže, je vítáno. V rozumných mezích (čas, peníze) samozřejmě.
