Vyplatí se učit C++?

[Ondřej Novák]

Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).

Souhlasím s tou Lua. Na skriptování nestvůr a jiných věcí asi není nic vhodnějšího.

PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela .

No hlavně nedělá horšího, pomalejšího nebo dražšího....

... i když, aby C++ programátor byl přínosný, musí být dobrý, a pokud je dobrý, nebude levný. Ale to možná platí i jinde.

[Reklama]

[zboj]

Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).

Souhlasím s tou Lua. Na skriptování nestvůr a jiných věcí asi není nic vhodnějšího.

PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela .

No hlavně nedělá horšího, pomalejšího nebo dražšího....

... i když, aby C++ programátor byl přínosný, musí být dobrý, a pokud je dobrý, nebude levný. Ale to možná platí i jinde.

To platí všude

[zboj]

<trolling>Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++.</trolling>

Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk.

<trolling>Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.</trolling>

Opravdu? Vidim tu snahu o trolling, protoze vas prispevek nejen, ze je jak od lopaty, navic je nepravdivy. (Coz nabizi otazku, zda opravdu neni od lopaty, ze...) Rozhodne neznam jen Javu, nejnovejsi verzi jsem dokonce snad ani nepouzil. Usekl jste si pekny trapas, vzdyt primo v tomto vlaknu propaguji Scalu a alternativni pristupy nekolikatou stranu (zminl jsem napr. i Haskell, Frege a F#).

A ze bych Javu vychvaloval, nebo dokonce "vynasel do nebes", to myslite opravdu vazne? Protoze asi nejste prilis bystry, tak mi nezbyva, nez se citovat:

... Nevim, jestli se citite urazen vyrokem, ze C++ je spatlanina (pejsek a kocicka), ale je to bohuzel pravda. A rozhodne to nerikam proto, abych "vyhral" diskuzi. Podobny nazor mam i na JavaScript, ve kterem nyni prevazne pracuji. A prestoze Java mi prijde o trochu lepsi, tak ma take hodne much (nejvetsi asi generika, ve srovnani s C# je to slabota, a to .NET moc nemusim). ...

Ja nepopiram high-level aspekt C++, jen jsem rikal, ze pokud pouzivate tento high-level pristup, tak je jedno, jestli delate v C++ nebo v Jave, dosahnete vykonostne stejneho vysledku (dokonce tu nekdo zminoval nejakou studii od Googlu). Pokud se pujde vice "low-level", tak velkym rozdilem bude cas a narocnost vyvoje vymenou za lepsi vykon. Tzn. napsat projekt v C++ vyjde zadavatele v kazdem pripade draz, nez v Jave. Vysledny produkt u high-level pristupu, pominu-li pametovou narocnost, bude davat stejne rychle stejne vysledky a tudiz je rozdilem pouze cena prace. Vzhledem k tomu, ze Java je navrzena tak, aby v ni mohl zacit delat skoro kdokoliv (az se nabizi ono drazdive slovo "opice"), se neni cemu divit, ze hodinova sazba zacinajiciho Javisty a CPPisty se asi budou pomerne dost lisit. No a u "low-level" pristupu s rucnim tunenim pristupu k pameti a opravdovymi zisky na vykonu to vyjde zakaznika velmi draho, protoze hodinova cena C++ profika je velmi vysoka. A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).

Predchozi tvzreni podporuje i Tiobe index. Nevim tedy, jak moc je realne vypovidajici, ale C++ vykazuje celkem patrny trend - dlouhodoby postupny pokles.

*: U indie her se davno pouzivaji "pomale" jazyky jako C# a Java. Co je zajimave, ze uz i do AAA her zacinaji prorazet, prestoze spise jen pro skriptovani a UI, jazyky a technologie jako Adobe Air (v podstate Flash, UI v MMORPG, napr. Tera), Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).

PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela .

Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.

Kód: [Vybrat]

class Complex {
public:
        double re;
        double im;
        Complex(double r, double i) : re(r), im(i) {}
        Complex operator+(const Complex& x) const {
                return Complex(re + x.re, im + x.im);
        }
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
    list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;


[Radek Miček]

Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.

Kód: [Vybrat]

class Complex {
public:
        double re;
        double im;
        Complex(double r, double i) : re(r), im(i) {}
        Complex operator+(const Complex& x) const {
                return Complex(re + x.re, im + x.im);
        }
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
    list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;


V Javě to na rozdíl od C# naráží na absenci hodnotových typů a na absenci specializace generik. Tj. hádám, že v Javě bude třeba udělat specializovaný seznam pro třídu Complex; uvnitř takový seznam může být implementován jako dvě pole doublů.

[zboj]

Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.

Kód: [Vybrat]

class Complex {
public:
        double re;
        double im;
        Complex(double r, double i) : re(r), im(i) {}
        Complex operator+(const Complex& x) const {
                return Complex(re + x.re, im + x.im);
        }
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
    list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;


V Javě to na rozdíl od C# naráží na absenci hodnotových typů a na absenci specializace generik. Tj. hádám, že v Javě bude třeba udělat specializovaný seznam pro třídu Complex; uvnitř takový seznam může být implementován jako dvě pole doublů.

Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".

[Reklama]

[noef]

Porovnám to pak na x86, ARM, MIPSu a PowerPC.

A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).

Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".

Jste si to spatne interpretoval - pokud chcete optimalizovat kdekoliv, tak spadnete k praseni. Pokud vyberete specifickou ulohu, u ktere z vlastnosti technologie vyplyva neefektivita... Uplne stejne se to muze udelat i naopak a "shodit" nejen C++ ale jakykoliv jazyk, jak ze jsou nevykone.

Pokud tohle povazujete za produkcni kod (reagujete na muj prispevek, takze asi ano), tak stejne pouzijete specializovanou knihovnu a neresite to takto kulatenim kola. Ocekavate, ze Java implementace bude pomalejsi, ale to jsem ja v prispevku, na ktery reagujete napsal, ze to tak casto bude . Rozdil je v tom, pokud bude opravdu rozdil ve vykonu i s pouzitim spec. knihovny, ze v Jave to zboucha kdejaky stredoskolak za chvilku, kdezto v C++ si za to reknou trochu vic a chvilka to byt nemusi. Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".

[zboj]

Porovnám to pak na x86, ARM, MIPSu a PowerPC.

A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).

Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".

Jste si to spatne interpretoval - pokud chcete optimalizovat kdekoliv, tak spadnete k praseni. Pokud vyberete specifickou ulohu, u ktere z vlastnosti technologie vyplyva neefektivita... Uplne stejne se to muze udelat i naopak a "shodit" nejen C++ ale jakykoliv jazyk, jak ze jsou nevykone.

Pokud tohle povazujete za produkcni kod (reagujete na muj prispevek, takze asi ano), tak stejne pouzijete specializovanou knihovnu a neresite to takto kulatenim kola. Ocekavate, ze Java implementace bude pomalejsi, ale to jsem ja v prispevku, na ktery reagujete napsal, ze to tak casto bude . Rozdil je v tom, pokud bude opravdu rozdil ve vykonu i s pouzitim spec. knihovny, ze v Jave to zboucha kdejaky stredoskolak za chvilku, kdezto v C++ si za to reknou trochu vic a chvilka to byt nemusi. Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".

Na mnohých příkladech je jasně vidět, že JIT mnoho výkonu nepřináší, a je jedno, je-li to způsobeno nedostatkem jazyka, nebo posunutým periheliem Merkuru. Knihovna nebyla použita schválně, a specializovaný seznam pro komplexní čísla v ní stejně není.

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

P.S. Rád si počkám na high-level kód v Javě "shazující" C++ (ale budu čekat dlouho, neb neexistuje, opět šlo jen o mlácení prázdné slámy...).

[Petr Novák]

Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".

Moje zkušenost v Linuxu je taková, že i triviální čistě aritmetický kód (bez nadměrných přístupů k memberům a k prvkům polí) je rychlejší v C++ než v Javě. To ale silně závisí na JIT a na překladači C++. U kompilátoru C++ nezáleží na časové náročnosti samotného překladu, záleží jen na výsledném strojovém kódu. JIT musí zvolit kompromis mezi časem překladu a výsledkem.

Naopak "makat" a dělat prasárny musím v Javě, aby výkonově dohnala přehledný ručně neoptimalizovaný kód v C++. Např. se to týká práce s binárními formáty, jak už tu někdo zmínil.

[Petr Novák]

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

[zboj]

Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".

Moje zkušenost v Linuxu je taková, že i triviální čistě aritmetický kód (bez nadměrných přístupů k memberům a k prvkům polí) je rychlejší v C++ než v Javě. To ale silně závisí na JIT a na překladači C++. U kompilátoru C++ nezáleží na časové náročnosti samotného překladu, záleží jen na výsledném strojovém kódu. JIT musí zvolit kompromis mezi časem překladu a výsledkem.

Naopak "makat" a dělat prasárny musím v Javě, aby výkonově dohnala přehledný ručně neoptimalizovaný kód v C++. Např. se to týká práce s binárními formáty, jak už tu někdo zmínil.

Pro C++ doporučuju clang, překládá rychleji než GCC a generuje kód pro všechny možné architektury (díky LLVM).

[zboj]

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift

[Radek Miček]

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix.

Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (LLVM based MSIL Compiler).

[Petr Novák]

To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift

Já jsem měl právě pocit, že WinRT jde udělat krom .NET i nativně v Cx nebo v C++ a pak je to normální binární EXE volající DLL a COM, jako hra pro DirectX. Je to ale jen pocit. Přiznám ale, že jsem to zatím prakticky neověřoval a možná ani nebudu. Protože po hrubém prostudování API jsem došel k závěru, že pro mou aplikaci stačí Win32 + DirectX s targetováním Windows 7 a speciální port pro Windows 8 nic extra nepřinese.

[čumil]

Nechci bejt pedant, ale počítaní referencí JE GC ... A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.

[zboj]

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix.

Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (LLVM based MSIL Compiler).

Je pravda, že ve WinRT je RC pomalé (a nejen RC), až je skoro nepoužitelné. Rychlé RC vyžaduje především velmi dobrou statickou analýzu kódu. Některé implementace mají i runtime optimalizaci (inspekce stacku), ale statická analýza (tj. v čase překladu) je základ.

(P.S. GC je rychlostí řádově srovnatelné s RC jen tehdy, má-li k dispozici cca. 4x více paměti, jinak výkon rapidně klesá. Nemusí to být vždy problém, ale třeba na RPi...)