ARCHIV

Mně osobně by zajímala rychlost inkrementální kompilace. Protože to je to jediné, kdy mně rychlost kompilace vůbec nějak zajímá.

Jak rychle probíhá konečná, plná kompilace, kterou udělám jednou za uherský rok při release verzi je mi úplně jedno. Je to nepodstatný parametr.

Jinak Whetstone měří pouze rychlost floating point, což je jediné, kdy clang podle testů mohl nějak konkurovat. Takže závěr asi bude, že optimalizace floating operací v gcc bude špatně navržená v mezijazyce.

Jinak osobně u kompilátoru je pro mně kritická spolehlivost. Od bolestivých zkušeností s Borland kompilátory, které sice kompilovaly rychle, ale člověk následně musel kontrolovat často ve strojáku, zda je jeho kód vůbec přeložen dobře je to důležitý parametr. A Borland nedělal málo chyb ve strojáku!

Mám trochu strach, zda krok na clang nebude krokem zpět. Vidím tu velkou snahu o povrchnost. Neustálá prezentace rychlosti kompilace, která je navíc vykoupena horším a pomalejším kódem je něco co ve mně zachovává rozpaky – a nevidím zde jedinou výhodu – prostě jedno je důsledkem druhého.

Důležitým atributem je SPOLEHLIVOST a BEZCHYBNOST výsledného strojového kódu a také jeho EFEKTIVITA.

Co mně těší je, že gcc už přišel na to, že pokud bude psán v jazyce C, nedokáže to už odřídit. Stejně tak jako na to přišel llvm. Vidím jako nezbytné přepsat gcc do C++ a zejména přepsat jeho frontend.

Forkování a vývoj lepšího kompilátoru, co měl nahradit gcc už jsme v historii jednou měli. Skončilo to sloučením s gcc, vývoj kompilátoru není sranda.

llvm ale neni zadny projekt zacatecniku. V macOS je pouziva jiz nejaky ten rok a ve FreeBSD 9 bude jako alternativni kompilator k dosavadnimu GCC 4.2. U kompilatoru je nejdulezitejsi aby nebyl zpraseny a dobre se rozsiroval. Rychlost generovaneho kodu neni tak dulezita, zoptimalizovat se to lepsi bytecode -> asm transformaci da vzdy.

„zoptimalizovat se to lepsi bytecode -> asm transformaci da vzdy“

Na tomto omylu jste postavil tvrzení, ale on je to omyl.

Každý kompilátor má meze v optimalizaci dané jeho architekturou. Jinak řečeno, llvm tím, že zabetonovalo mezijazyk si také zabetonovalo a určilo strop, za který se už v optimalizaci nedoáhne jinak, než zahozením, či totálním přepracováním llvm.

Jestli se to dá lépe zoptimalizovat určuje právě přesná forma mezijazyka.

To, že něco používá macos mně moc kvalitativně nepřesvědčuje. MacOS je spíš o vnější nablýskanosti, než o vnitřní technické dokonalosti a dobrých technických parametrech. A vždycky byl.

Rychlost generovaného kódu samozřejmě důležitá je. Zkuste říci třeba tvůrcům videokodeků, nebo vědeckotechnickým pracovníkům, kteří pouštějí výpočty trvající řadu hodin, že na rychlosti nezáleží. Doporučuji se předtím vybavit padákem, až poletíte.

Nejdůežitější u C/C++ kompilátoru je:

1) spolehlivost výsledného kódu (tedy aby výsledek dělal přesně to co bylo ve zdrojáku)
2) rychlost výsledného kódu
pak dlouho dlouho nic
pak zase dlouho dlouho nic
a pak až nějaké další parametry

Pokud budete mít C/C++ kompilátor, který bude generovat pomalý kód a nebude Vám to vadit, proč tedy vlastně vůbec psát v C/C++? Proč nepoužít třeba Javu?

Jazyky C/C++ mají význam jen proto, že dávají rychlý a efektivní výsledný kód. Pokud tohle kompilátor nedá, pak není důvod proč C/C++ vůbec používat. Je halda vysokoúrovňovějších jazyků, když Vám nezáleží na rychlosti, které mají rychlejší vývoj.

Napsal jsem dalsi dil tohodle serialu. GCC neni taky zadny zazrak, jenomze je tu s nami uz dlouhou dobu a tak jsme si na jeho chyby zvykli. Kuprikladu -O3 negeneruje vzdy rychlejsi kod nez -O2, pokud vubec vygeneruje spravny kod.

Je pravda ze GCC generuje v soucasnosti rychlejsi C kod nez Clang, ale rozdil je dost maly. Rozhodne bych ale netvrdil ze clang je diky llvm bitkodu jiz na hranicich svych moznosti a ze to rychleji nepujde. V nekterych pripadech je clang kod treba o 30% rychlejsi nez GCC.

Nejlepsi kompilator na x86 je pravdepodobne ten od Intelu. Obvykle v testech vitezi.

Vyhoda C je ze je to nizkourovnovy jazyk. C++ neni rychlejsi nez Java. Ono se ani v praxi full C++ moc nepouziva prave kvuli vykonu. C++ kompilatoru se da rici ze nektere features nepouzivame a on pak generuje rychlejsi kod. Full C++ v naproste vetsine pripadu s Javou prohraje u jednodusich testu je to dneska mezi Java a C++ nerozhodne a Java toho umi vic. Dneska se v Jave pisi i 3D veci, ktere byli drive vyhradni domenou C++.
Dneska bych C++ pro novou aplikaci nepouzil pokud by se nejednalo o cilovou skupinu ktera to potrebuje mit v C++ z duvodu kompatibility s ostanimy knihovnami.

Já zareaguji jenom na konec.

C++ je samozřejmě rychlejší, max. stejně rychlý, než Java. Samozřejmě, že C++ prohraje rychleosti ve všech testech, které připravili javisté. A kde C++ modul napsal javista.

Javisté už dokázali leccos. Například, že Java v samozřejmě seriózních testech už dokázala i to, že Java je rychlejší, než strojový kód procesoru. Je jenom otázkou času, kdy javisté dokáží, že Java překoná rychlost světla a zruší platnost fyzikálních zákonů. Samozřejmě podle svých dokonalých testů.

Jeden z oblíbených triků javovských testů je nepoužívat efektivní C/C++ konstrukce. A dalším trikem pak je srovnávat Javu se špatně zkompilovaným gcc. Pár testů od javistů (asi 20) jsem prostudoval, od té doby je neberu vážně.

Nicméně, k předchozímu. Vše je dané architekturou. Jestliže si někdo zabetonuje mezikód, připravil si také umělou hranici. A dříve, nebo později se to samozřejmě projeví.

To, že je „malý“ rozdíl mezi rychlostí výsledného kódu? Vy si opravdu děláte srandu, že? Každá další desetinka procenta optimalizace v rychlosti výsledného kódu navíc se dostává krvavějším a těžším úsilím a čím výše jste, tím víc a víc úsilí vás stojí stejný postup. Ten malý rozdíl může být velmi velmi těžko překonatelný a bude stát mnoho potu, krev a slz, pokud se vůbec překoná. I když v číslech je to „malý“ rozdíl.

Bez ohledu na současný stav – každý program má limit daný architekturou. A na něj dříve, či později narazí. Můžete mi argumentovat jak chcete, ale llvm se z čistě technických důvodů nikdy hvězdou nestane. Pohybuji se v sw 25 let, a než abychom si tu hráli na fanouškovství llvm, počkejte si. Nic mi nezdůvodňujte, já s Vámi stejně nesouhlasím. Vzpomeňte si za pár let na llvm a na mně a na tento dialog. Uvidíte, že llvm žádnou díru do světa neudělá. Bude max. alternativou.

Ono udělat fork operačního systému a fork kompilátoru – ve smyslu začít odznovu s jinou koncepcí, to je neuvěřitelně mnoho práce. To dopadne dobře jenom tehdy, když:

a) Dobře zvolíte koncepci (sw architekturu) projektu.
b) Jste připraveni makat jako šroubi, a pracovat řadu let s několika kvalitními lidmi a dotáhnout to do konce – protože to jsou rozsáhlé projekty.

U llvm je a) špatně. Možná je jeho koncepce čistější, to bezesporu. A přehlednější. Ale s limitem pro kvalitu výsledného kódu. Už z principu architektury nemůže být llvm nikdy tak dobrý, jak kompilátor, který si nezaleje do betonu mezikód. I když na začátku může i llvm překvapovat, tahle koule tam je.

A ohledně b) je otázkou.

Takže znovu říkám, nemusíte mi argumentovat. Jsem přesvědčen o svém. A byl jsme za 25 let několikrát v životě rebel, který skekticky mluvil o projektu, který se stal celebritou a měl zářivé zítřky jako o bublině.

Počkejte si pár let, pak napište znovu článek o llvm a přiložte tyto mé argumenty. Perfektně Vám vysvětlí, proč se llvm hvězdou válcující vše nestal.

Kdyz se podivate na tyhle testy tak vidite ze ty kompilatory jsou dost vyrovnane. Rozhodne neni zadny z nich tak pomaly aby byl nepouzitelny.
http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1

Je pochopitelne mozne, ze projekt muze byt tak dobre zoptimalizovan za male zrychleni se zaplati velkou lidskou praci. Dalsi optimalizace se pak uz nevyplati. pripad llvm to ale nebude protoze ten se nedavno stal teprve selfhosting. Navic cil llvm projektu neni mit ty cisla lepsi nez GCC.

ja si neuspech vykladam jinak. clang je pouzitelny prekladac C a llvm se ted zacalo pouzivat v nekterych projektech misto kodovani asm, protoze se v llvm lepe dela. To mi nepripada jako neuspesny projekt. Ja si uspesny projekt predstavuji tak, ze se pouziva a to o llvm plati. Investori by necpali do llvm prachy kdyby to byl pro ne nepouzitelny projekt. LLVM dopadl dobre, protoze vysledek je pouzitelny.

K te jave mrknete na diskuzi zde http://www.linuxsoft.cz/article.php?id_article=1658

u te rychlosti javy a c++ jde prave o tu vasi SW architekturu. JIT kompilator javy si jednak muze dovolit agresivnejsi optimalizace (vcetne takovych, ktere vedou na "nekorektni" kod) a druhak ma k dispozici daleko vice informaci pro provadeni techto optimalizaci. Dalsi souvisejici jev je, ze java nijak nespecifikuje jak budou aspekty jazyka implementovany, jsem zvedavy jak by treba implementace C++ realizovala PILC.

Nicmene to neni v dnesni dobe prilis relevantni, daleko relevantnejsi je, ze C++ je proste obludne komplikovany jazyk. Ze to vadi zacinajicim programatoru prilis relevantni neni, ovsem to, ze kompilatory C++ jsou diky tomu neuveritelne pomale uz relevantni je (a ze urcit jestli vstup odpovida gramatice C++ je NP-uplny problem je jenom detail).

a abych se zapojil na nejakou stranu velke diskuze, tak prohlasim, ze prave vyse uvedene problemy C++ jsou duvod, proc se mi LLVM nelibi. Tim ze je to napsane v C++ tak je to neuveritelne giganticke. Fakt je, ze gcc je z vicemne politickych duvodu strasny bastl, ale alespon to neni 50MiB duplicitne expandovanych sablon a jineho C++ chaosu. Pro volne stojici kompilator je to asi jedno, ale pro to co jsem od LLVM ocekaval (a autori zrejmne take) je to naprosto nevhodne.

To, že je C++ bastl se ví. Někdy ale není moc na výběr takže můžete volit jen mezi C a C++ a většina lidí zvolí C++, přece jen je objektově orientované a má STL, což se hodí. Není moc z čeho vybírat.
Kdyby byl llvm napsaný třeba v Jave tak by ho komunita nebrala. Tyhle lidé mají k javě averzi.

Základní problém, který si milovníci Javy neuvědomují je následující:

1) Kompilátor by fungoval jen tam, kde je standardní a plně vybavená JVM. To je na mnohonásobně menším počtu platforem, než je C++.

2) Rychlost kompilace, především té inkrementální, je pro vývojáře zajímavá. Java ať chce jak se snaží bude pomalejší.

Především ta 1) je dost zajímavá.

Jinak ohledně argumentu výše ohledně optimalizací Javy a C++. Vím, že sjou to urban legends pro Javu, nicméně realita a praxe je jinde. Masívní optimalizace v Javě se nekonají, neboť se přičítají k času runtime běhu programu = zpomalují ho.

---

Celkově: O tom, jak Java převálcuje všechno Sun mluvil mnoho let. Bohužel by kromě nenávisti museli javisté také myslet.

Až bude Java na takovém počtu platforem, jako je C++. Až bude budoucnost Javy tak jistá a jasná, jako je u C++. Až bude Java mít takovou diverzitu JVM jako má C++ kompilátorů. Atd. Pak bude mít Java šanci toto dokázat aspoň v určitých oblastech.

Jinak C++ je koncipován jako rychlý jazyk a přitom minimálně konzumující zdroje systému a tomu je hodně podřízeno. To co Vám připadá jako bastl je optimalizace na rychlost. Jazyky jako třeba Java, které svojí rychlost (stále nižší, než C++) dohánějí heslem: „Všemu je možné dát rozumnou rychlost, pokud mnohonásobně více budeme plýtvat pamětí“, pak samozřejmě jazyk bude jiný.

---

Doporučuji javistům-fanatikům zde ten kompilátor v Javě napsat. Po neúspěšném pokusu byste to rádi vrátili do C++, protože Java se na toto nehodí. Viz důvody výše.

1. Platforem kde je funkcni JVM je vice nez dostatek pro prakticke pouziti. Pokud bychom potrebovali kompilator i jinde, tam muzeme crosskompilovat nebo kompilovagt pomoci distcc kdy budeme posilat kompilatoru zdrojaky ke kompilaci pres sit.

2. Java nemusi byt pomalejsi, zalezi zde na pouzitem algoritmu mnohem vice nez na pouzitem programovacim jazyce. Napsal jsem proxy cache, dns server a bgpd v java a byli rychlejsi nez jejich C ekvivalenty. Taky Sun Java web server je rychlejsi nez apache (ale jen o maly kousek).

3. Ohledne urbands legends pro javu. Vzdyt vy dopredu prohlasujete ze pokud Java zmasti C++ v benchmarku tak ho odmitate uznat. C++ je rychlejsi nez Java a pokud Java vyhraje tak je chyba v benchmarku. Moc vazne vas proto neberu.

Serverovska hotspot JVM vice JITuje a diky tomu je start programu pomalejsi, to je pravda ale bezi pak rychleji. Pokud nam pomaly start vadi Hotspot jvm client startuje rychleji. Pripadne se daji z java classu vyrabet primo exace, ale pouziva se to v praxi jen velmi zdridka, neni k tomu duvod.

Ne vzdy potrebujete mit podporu desitek platforem, podivejte se treba na debian/ubuntu - moc platforem to nepodporuje a jak je to uspesny projekt. Staci vykryt ty nejpouzivanejsi a to ma Java uz davno vykryto vcetne ruznych mobilnich zarizeni.

JVM existuje nekolik desitek - podivejte se sem http://java-virtual-machine.net/other.html (ponekud starsi) a http://en.wikipedia.org/wiki/List_of_Java_virtual_machines Kolik existuje C++ kompilatoru?

Sun byl v prosazeni Javy uspesny - podle statistik je uz dnes stejne popularni jako C a deli se s nim o prvni misto http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Kompilator v Javy bych rozhodne uspesne dokoncil. Cely zivot mi lidi rikali ze nemuzu v Jave psat tohle a tamto a vzdy byl vysledek dobry, v nekterych pripadech dokonce rychlejsi nez C ekvivalent. Slovo nemozne existuje pouze ve slovniku hlupaku. Podivejte se na Java databaze - Cloudscape AKA derby. I kdyz to neni nejrychlejsi Java databaze, kterou je http://www.h2database.com/ tak Cloudscape na vetsich datasetech vymlati Mysql4.

Byla to prvni pureJava databaze ktera ukazala vsem ze napsat dobrou db v Jave lze. Presvedcila neverici tomase. Kdyby lidi knourali ze v Jave neni mozne SQL databazi napsat tak bychom Cloudscape ani jinou db dneska nikdy nemeli protoze by to nemeli odvahu zkusit. Nesnasim lidi co poradi knouraji nejde, nejde. Jasne ze to nejde kdyz se o to ani nepokusi a premysleji ne jak ukol udelat, ale jak ho neudelat. Oni si snad mysli ze jsou placeni za to ze umi jen rikat nejde to, nejde to.

Dneska se v Jave JNI nepouziva pro zrychleni (prepsat kus java programu do C), ale jen pro pristup k API ktere java nema. Pokud vim tak pouziti native knihoven kvuli vykonu se pouziva v pythonu.

Ja jsem si vzdycky osobne vazil lidi co meli velke IT znalosti ale pokud mysleli porad stylem nejde, nejde tak jsem si je nanalepkoval jako nepouzitelne, protoze odmitali sve znalosti pouzit a byli proto pro mne bezceni. Proto jsem si vzdycky pro projekt vybral lidi co nemeli sice tak dobre IT znalosti ale meli odvahu a ochotu se ucit.

Kdyz uz jsme u tech programovacich jazyku. Co treba Python? Verite ze je v nem mozne napsat DVCS nebo by se taky poslusne pak vratili k C++? Autori BZR a HG se k nemu ocivine nevratili a problemy s vykonem zjevne nemaji a Python je vyrazne pomalejsi nez Java. Ja jsem onehda napsal defragmentic na UFS2 filesystem v Pythonu, zajimalo mne zda bude CPU nebo IO bound a zjistil jsem ze i na dost pomalem pocitaci - 250Mhz je IObound, takze je Python na tuto ulohu dostatecne rychly.

„Tyhle lidé mají k javě averzi.“

Základní averze k Javě vzniká na základě lží javistů. Těch je i v tomto diskusním vlákně plno. Nemá smysl je rozebírat, ale když už budete na podpory Javy lhát, dělejte to alespoň inteligentně, aby to nebylo tak zjevné.

Samotní javisté pak mnoha lžím uvěřili a myslí si, že je to pravda. Tím samozřejmě zmatou začátečníky, ale uvědomte si, že psaní kompilátoru se neúčastní žádná ořezávátka ani béčka. Psaní optimalizovaného kompilátoru je jedna z nejtěžších sw úloh a tím jsou z ní vyloučeni všichni podprůměrní i průměrní programátoři a účastnit se ho může jen zkušený nadprůměrný programátor.

Nadprůměrný programátor jednak má rozhled a jednat zná vlastnosti Javy. Po argumentech, které jste tu předvedli ohledně Javy si o Vás pomyslí „no jo, ještě moc zkušeností nemají, ale časme to zjistí“.

Zkušený programátor ví jak to je. Tyhle lži o Javě, například o masívní optimalizaci Javy, o její rychlosti, o její vhodnosti pro tyto účely, o neustálém vyvolávání domněnek o averzi k Javě, která se nápadně podobá volání jednoho etnika o rasismu, atd. – ty osloví jen nezkušené, max. průměrné programátory. Kvalitní vývojáře, kteří jsou nutní pro vývoj kompilátory – ty neoblbnete.

Nehledě na tom, že pokud budete portovat C/C++ kompilátor na novou platformu, daleko jednodušší je portovat C/C++ kód, než si k tomu přidat sadomasochisticky nejdřív portacvi JVM a jejich knihoven. A křížový vývoj je sice možný, ale ne vždy je ideální.

psat produkcni kompilator C v Jave je pochopitelne nesmysl. Ale take si myslim, ze neni uplne cesta jej psat v C++. Gcc je v C, ovsem to ze je to necitelny stezi udrzovany chaos prameni z uplne jinych problemu, nez ze by to bylo psane v C.

A tvrzeni, ze C++ je objektove orientovane spise dokazuje, ze nemate prilis predstavu, co ta "objektova orientace" vlastne znamena. Jediny platny dobry argument pro C++, ktery jsem kdy slysel je STL. Ovsem na druhou stranu STL (a Boost jakbysmet) vede na vysledny kod, ktery je plny zbytecne redundance a obecne neefektivni. Argument, ze dostatecne dobry kompilator toto odstrani je sice hezky, ale takovy kompilator neexistuje (a i kdyby existoval tak zrejme s onou snadnou interoperabilitou s C udela divy).