Rychlost. C++ || JAVA || C# ???

Ako narocne su tie matematicke operacie v porovnani s otvaranim suborov? Ono ak je to skutocne elementarne, tak najviac casu zaberie aj tak pristup na disk, a je to vlastne jedno. Ak su to operacie ale tiez relativne casovo narocne, co tak obzriet sa po fortrane? Niektore prekladace su uz tak pokrocile v optimalizacii, ze napisat tu istu vec trivialnym sposobom v c-cku s hlupejsim prekladacom moze dat o desiatky percent horsi vysledok.

no...ve fortranu se nenapsal jeste ani jednu radku kodu...
mat. operace = prumerovani (scitani, deleni), pocitani logaritmu
pak celkem dost trideni (asi quick sortem)
pristup na disk bude v mensi mire nez mat. operace

No vidis, mas prilezitost naucit sa nieco noveho ;) Faktom je, ze fortran je idealny na podobne ulohy, v c-cku by si tiez kod pisal stylom "float a(MYTYPE a1, MYTYPE a2){ int i; float b=0; for(i=0; i<size(a1)) b+=at[i];return b/i}, a nevyuzijes ziadne zlozitejsie konstrukcie (resp. v c++ sa o to mozes pokusit a vyhrat sa s pretazovanim operatorov, ak si masochista ;)).
Ak chces ale jednoz tych troch, zabudni na javu - sialene pomala zalezitost, a predpokladam ze c# tiez este nema dostatocne vyspele kompilatory, aby boli schopne rozumnej optimalizacie.
Takze bud c++ (v ceckovom style) alebo c++ ako bolo c++ myslene (a to ti prajem prijemnu zabavu ;))

ee :-) fortran se ted ucit nebudu...ale vyresil sem to tak, ze to budu psat v C++ ale vsechno pod jednou tridou, tedy vlastne v C stylu. Dva dny sem se tady s tim moril a uz na to nemam nervy. Jsem proste rozmazlenej z JAVY a C#. A to sem si driv rikal, jak je C++ prijemnej jazyk :-)

Klidne to napis v C# nebo Jave. V matematickych ulohach, ani pri cteni disku nejsou o moc pomalejsi. Zpomaleni nastava az pri vyjimkach (to znamana, nepouzivej vyjimky), pretezovani a dalsich objektovych vecech. A pak i desitky procent zpomaleni vypoctu bohate dozenes pri rychlejsim vyvoji aplikace.

Hlavne si opravdu davej bacha na to, at prilis (nevyhnes se jim) nevyuzivas objekty. Pri nich je pak zpomaleni velmi vyrazne.

Taky bych Ti mozna doporucil udelat si ve vsech trech jazycich dummy aplikace, ktere nebudou delat nic moc uzitecneho, ale vyzkousis si na nich to zpomaleni. Aspon pak budes mit duvod, proc sis pro implementaci zvolil to, co sis zvolil.

A nezapomen trosku polaborovat s velikosti bufferu pri cteni a ukladani na disk. Pozor, pri prenosu na jiny pocitac uz nemusi byt pravda to, co jsi nameril treba doma.

Nj, na matlab&co jsem zapomel, mea culpa.
Ale fortran je fortran ;)

MATLAB NEPOUŽÍVAT!!! Nic pomalejšího asi nenajdete.

Jak na co. Kdyz se rozumi problemu a jde to vektorizovat, tak je to rychle dost. A hlavne je to velmi rychle napsane.

Otazkou je, co znamena "dost rychle". N-radove zpomaleni oproti C/Fortran tam bude zcela urcite ...

je idealni leda tak do muzea. o ty vykopavce jsem uz roky neslysel.

kdy jsi to psal? 1995? driv? ja delal asi pred 5 lety test rychlosti javy a c++ pro ciste matematicke operace. vysledek: naprosto stejna rychlost. jsou veci kde java trochu prohraje, ale urco se to netyka celociselnych operaci. c# bude asi to samy.

ani cisty cecko ti neda zadnou opravdovou vyhodu. ztrata casu

delej jak sces, ale zapomen na fortran.... naprosta ztrata casu.

fortran se stále ještě používá a používat bude, protože jsou v něm obrovské matematické, vědecké a jiné knihovny. a není to až tak strašný jazyk. ale volil bych ho jen tehdy, pokud bych měl pro to velmi pádný důvod a to tu asi nebude.

pokud jsou operace čistě nad základními matematickými typy - tedy int, long, float, double, pak je asi rychlost javy a c# srovnatelná plus mínus s c++. pokud ale už počítáme matice a složitější typy, pak java a c# už začíná ztrácet, pokud se nepoužije specializovaná knihovna (existuje vůbec taková pro javu?), neboť začne narůstat režie javy a c#, která není v c++.

proč bych ale javu pro složitější matematiku určitě nepoužil je fakt, že nemá přetěžování operátorů. počítat v tom matice, polynomy, vektory a další bez operátorů bych nechtěl. to je nedostatek, který v javě nezmizí ani s žádnou doplňující knihovnou. strašně to zamlžuje zdrojový kód a mnohem snáze se přehlédnou chyby, pokud v tom máte plno matematiky a operací. pokud volíte mezi javou a c#, zvolte raději c#, kde máte možnost operátorů.

> java a c# už začíná ztrácet, pokud se nepoužije specializovaná > knihovna (existuje vůbec taková pro javu?)

Pro Javu existuje knihovna JAMA (math.nist.gov/javanumerics/jama). Nemám s ní ale skoro žádné zkušenosti, programoval jsem s ní jeden nebo dva zápočty a na to byla dobrá.

Že jste o tom vy roky neslyšel ještě nic neznamená. Jediné, co se z toho dá usuzovat, je to, že prostě nejste člověk pohybující se na poli numerické matematiky. Toť vše :-)

Matlab je na praci s cisly velmi dobry, zvlaste nektere knihovny. Umi generovat i C/C++ kod a v nekterych pripadech si lide dali opravdu praci.

Matlab je všechno možné, jen ne rychlý.

Kdyz se v nem umi programovat, tak je rychly dost.

Z Matlabu se dají volat dll knihovny, psané v C. Ale pokud není vysloveně potřeba užít matlab jako takový (tj. např. simulink), tak bych to v něm nedělal. Maximálně prototyp, když bych si nebyl jistý řešením, ale výpočty rozhodně ne.

Dal bych C/C++. Jak matematiku, tak praci s pametovymi strukturami by tam melo jit napsat daleko optimalneji.

Po zkušenostech s věcmi jako je počítání fourierovy transformace, syntéza řeči, vyhledávací algoritmy a výpočetní geometrie mohu říct jen toto:
1. Pokud to má být rychlé a je málo času na ladění - použít Javu
2. Pokud to má být rychlé, mám moře času a rád optimalizuji - použít C++
3. Musí to být co nejrychlejší, každé promile výkonu přináší velký užitek - použít C a udržet ho kompaktní

Důvody:
A. Java obsahuje JIT a velice agresivní metody optimalizace, umí přestavět aplikaci za běhu a pokud nezačnete vytvářet haldy objektů, pak dává mnohem lepší výsledky než "dobře napsaný" program v C/C++
B. Jazyk C/C++ přeci jen nabízí lepší možnosti jak řídit výkon a optimalizovat. Je to práce pro odborníka, který má hodně zkušeností a ovládá práci s profilerem. Výsledek je nesrovnatelně pracnější než v případě Javy, ale také je o poznání lepší
C. Jazyk C++ není jen rozšířením jazyka C, některé věci prostě dělá po svém a jinak. Ne vždy rychleji. Navíc pokud se použijí "standardní prostředky" C++, bude výkon opět nižší než v případě C, kde si to budete muset napsat sám a tedy máte prostor k optimalizaci. Virtuální metody nebo STL nejsou cesta k výkonově optimálním výsledkům.

A jako obvykle: pro jazyky Java a C/C++ platí, že nejdůležitější je algoritmus. Ten může znamenat rozdíly výkonu několika řádů. Samotný "výkon jazyka" pak při dodržení základních zásad programování dělá nejvýše desítky procent.

diky moc za podnetne komentare...

Naprosto jednoznacne od nejrychlejsiho: C++, C#, Java (na MS Win) a C++, Java, C# (na Linuxu). Pokud nepotrebujes mit kraviny jako kazdy cislo = samostatny objekt a jde ti ciste o rychlost, pak radove nejrychlejsi je C++ s mnohem mensimi naroky na pamet (jen co potrebujes - narozdil od C#/Java kde co potrebujes + cela rezije GC a objektovosti). Nevahej a kod!

jeste by se treba hodilo dodat, ze jestli tam pracujes s velkyma cislama, cca v radu 200 a vice mist, tak bych doporucil pouzit c++ a knihovnu NTL a tim si usetrit neuveritelne moc prace...

Virtuální metody nebo STL nejsou cesta k výkonově optimálním výsledkům. Nejsem C++ zelot, ale tohle je nesmysl.

Pri mldach cyklu je rozdil mezi rychlejsim nevirtualnim volanim celkove jen v nekolika nebo desitkach ms, alespon v pripade vc8 nebo g++. Navic zapis a cteni do souboru spotrebuje daleko vice casu. Navic se to tyka implementace prekladace, ne standardu C++.

Za druhe otazka rychlosti STL je hlavne dana opet implementaci, opet se to netyka standardniho C++. Takze muzete narazit na nejakou spatnou implementaci STL, ale o tom pochybuju. STL knihovny, ktere se nejvice pouzivaji v produkcnim prostredi jsou navrzene lidma, kteri to umi navrhnout. Pochybuji, ze Vy byste to zvladnul, bez jejich znalosti lepe.

Proboha, jak to můžete poměřovat v milisekundách? To je přece naprostý nesmysl! To je jako říct že při výrobě kyseliny chlorovodíkové metoda X spotřebuje obecně o 10 tun soli méně oproti metodě Y.
Že "Virtuální metody nebo STL nejsou cesta k výkonově optimálním výsledkům" je svatá pravda a pokud tvrdíte že ne, tak jste to vy, kdo o tom nemá ani páru! Celé OOP se týká zefektivnění vývoje za cenu méně efektivního výsledku. To je prostě fakt který lze matematicky dokázat.
Vaše démonizace profi vývojářů je opět velice naivní.
A pokud by náhodou někdo argumentoval super hyper optimalizátory, pak tvrdím, že žádný, podtrhuji, _žádný_ optimalizátor není schopen vyprodukovat efektivnější kód, než jaký je schopen napsat člověk zběhlý v Assembleru. Neboli - možnosti jakéhokoliv optimalizátoru jsou omezené a v případě jazyků jako Java, C++ a C# je jejich úkolem spíše udělat výsledný kód aspoň rozumně přijatelný než jaký by byl po "čisté" kompilaci.
Pokud jde o numerické výpočty pak jednoznačně doporučuji Fortran. Efektivita kódu z C++ nebo dokonce z Javy se mu těžko přiblíží.

Ja myslel, ze nejlepsui je vsechno programovat v assembleru, tak jaky Fortran?

Proč v assembleru? Máte rozum? Žádné zbytečnosti, psaní ve strojáku je to nejlepší. :-)

Domnívám se, že každý jazyk je vhodný k něčemu jinému. Tj. chceme-li získat co nejefektivnější výsledný kód, málokdy se nám to podaří pouze s pomocí jednoho programovacího prostředku, nutně to pak vede k různým kompromisům. Osobně nejvíce používám kombinaci C s Assemblerem a v případě embedded aplikací Forth + Assembler.

Semtam nějakou embedded divočinu napíšu ("samozřejmě" v C), o Forth jsem zavadil na Rootu víc než v letu... takže budu určitě plácat ;) - Forth je pouze pro procesory "zásobníkové" (STACK v mým AMD se oklepal :))? Udal bys, prosím, příklad takového procesoru (8, 16bit)? Dík

"A pokud by náhodou někdo argumentoval super hyper optimalizátory, pak tvrdím, že žádný, podtrhuji, _žádný_ optimalizátor není schopen vyprodukovat efektivnější kód, než jaký je schopen napsat člověk zběhlý v Assembleru."

To je pravda jen do urcite velikosti kodu. Predstavte si funkci, ktera bude delat strasne slozite veci se strasnou spoustou promennych a v C bude treba na 4000 radku. Tvrdim, ze i z gcc vyleze lepsi kod nez z toho nejlepsiho assembleristy.

A vubec - je jeste v lidskych silach psat opravdu efektivni kod pro dnesni hypersuper multijadrove venku CISC uvnitr RICS procesory? Staci se podivat na aplikace, kde a rychlosti zalezi a kde klicove rutiny psane v assembleru jsou male funkce a kde stejne trva az nekolik let nez se vyladi na maximalni vykon.

Prováděl jsem testy na toto téma a jsou zde: http://www.neo.cz/~tomas/java.net/2006/05/test-rychlosti-java-c-c-na-ms-windows.html

Nezanedbatelny rozdil muze byt i mezi jednotlivymi kompilatory toho sameho jazyka. Tady je priklad pro Fortran 90: http://www.polyhedron.com/pb05/linux/f90bench_p4.html Na to jak je gfortran novy si stoji prekvapive dobre (narozdil od g95). Bohuzel tam chybi kompilator od Sunu, ktery je zatim jen v betaverzi.

Informace v dotazu k odpovědi nestačí.
Z dotazu lze odvodit, že je poněkud omezený čas na vývoj a umíte (zřejmě) C#. Otázka rychlosti - čas běhu aplikace musí být minimální nebo stačí, aby to doběhlo v nějakém rozumném čase? Jak velké je to "celkem" u matic - jde o matice s řádem 10, 100 nebo 1000000?
Jsou matice nějak zvláštní (řídké, symetrické, ...)?
Z dotazu se zdá, že preferujete práci se sloupci matic. Musí to být jeden program? Musí běžet vše na jednom stroji?

Osobně bych se pokusil data ze souborů vyzobat něčím hotovým (např. perl) a dále bych řešil samotné zpracování matic.

Pokud jsou úloha preferuje určité operace a jde o větší matice (s řádem řekněme nad 1000) zkusil bych buď najít hotovou knihovnu nebo vytvořit spec. třídu optimalizovanou na danou úlohu. Preferoval bych jazyk, který (dobře) umím, případně se kterým si nejlépe rozumí použitá knihovna. Pro opravdu velké úlohy a/nebo speciální matice rychlost více ovlivní použitý algoritmus než samotný jazyk (např. jak je matice uložená v paměti, zda je nutno při třídění přesouvat data v paměti, je nutno přesouvat sloupce nebo lze změnit číslo sloupce, ...)

Jedna se o matice v radu 10^2 x 10^1. Nejedna se o zadne specialni matice (ridke, symeticke, regularni apod..) Zadne specialni maticove operace se zde provadet nebudou. Pouze se spoctou stredni hodnoty jednotlivych sloupcu a seradi se podle velikosti. CO bych videl jako nejvice zpomalujici faktor, je nacitani a prace s velkym poctem souboru radu asi 10^3. Pro ukladani matic, jsem se rozhodl vyuzit STL vector. Ale zda se mi, ze to nebude to prave orechove. V mem pripade se nyni jedna priblizne o 1700 matic radu 42x500. Kazda tato matice se nacita ze 42 souboru. Nad temito maticemi se dale pocitaji stredni hodnoty vsech sloupcu a dale prumery vesech radku. Takze zadne slozite operace. Praveze vim, ze v C (C++) se da nejvice bastlit, pokud to clovek fakt neumi, tak jsem radeji chtel sahnout po necem, co je trosku vic user-friendly. Jakoze treba Java nebo C#. Ale zase na druhou stranu, pozadacek od zadavatele byl C++, s tim, ze to neni nutne ale "bylo by dobre" to udelat v C++.
Honza

Jestli dobre rozumim nemusite se vubec trapit s FP vykonem - kazde cislo musite nacist, (a prevest z textove reprezentace na FP, pokud soubor neni binarni). Nakonec vam padne do nekolika malo souctu. Takze I/O bude uzkym hrdlem.

A jeste trochu obecne k uloham tohoto typu (pokud jde o praci, kde mate asi demonstrovat znalisti tak mozna nepouzitelne):

- Nejlepsi je pouzit nejakou osvedcenou knihovnu, kterou lze pouzit v jszyce ktery uz umite a hodi se pro dany typ ulohy.

- Vybrat spravny algoritmus byva dulezitejsi nez resit rozdily par procent v optimalite kodu ktere generuji ruzne komilatory.

- Hodne casu muzete usetrit pri praci s pameti. V c/c++ nebo fortranu to mate pod kontrolou, v C#/Java na to musite myslet a musite rozumet co dela VM / framework muze to byt paradoxne slozitejsi.

- Byva dobre myslet na to, aby se k datum pristupovalo v takovych sekvencich, ze budete mit dobry cache hit rate - procesory jsou rychle a sbernice pomale...

K rychlosti C++ bych řekl toto:

Rychlost kódu C++ velmi podstatně (snad až o mnoho desítek, možná i stovek procent) brutálně závisí na zkušenostech toho, kdo v něm programuje. Proto se testy na C++ zase tak moc brát v úvahu nedají. Pokud máte značné zkušenosti v C++, napíšete jednoznačně nejrychlejší kód.

Kdosi tu psal o rychlejším C, než C++, to je samozřejmě nesmysl. C++ má naprosto všechny prostředky jazyka C a dobrý programátor C++, kterému sdělíte, že prioritou je rychlost bude psát v C++ stejně rychlé kódy jako v C.

Samotné OOP v C++ není neefektivní, a rychlost volání virtuálních metod a další věci mají z hlediska rychlosti význam jen ve velmi speciálních případech. Používání tříd není v C++ z hlediska rychlosti rozhodující, je to skoro jedno.

Java a C# jsou určitě pomalejší, než C++, možná je C# trochu rychlejší. Jejich výhodou oproti C++ je prostě jednoduchost a zaručený výsledek, pokud moc programovat neumíte, a nebo se tím nechcete zabývat a chcete to mít rychle za sebou.

Dovolím si nesouhlasit. Eckel uvádí, že stejný kód zkompilovaný v C++ je proti C zhruba o 10% pomalejší. Já dodávám, že nejde o stejné kompilátory a ani nekompilují stejným způsobem. Z hlediska syntaxe je C++ pouze rozšířením jazyka C, ale z hlediska kompilátoru jde o dost rozdílné nástroje.

Já si zase dovoluji nesouhlasit dvojnásobně. Kompilátor C a C++ dnes mají jen rozdílný frontend, vše v pozadí včetně optimalizátoru je společné. Není pravda, ač je to rozšířená fáma, že C++ je pouze rozšířením jazyka C. C++ je v řadě věcí s C nekompatibilní, a existuje řada věcí, která je platná v C, ale neprojde v C++. Jinak pokud máte jeden kompilátor, tak není důvod jinak zpracovávat kód C a jinak C++. Dokonce nevím, proč by si jakýkoli výrobce kompilátorů zvolil jinou cestu, než maximálně společných částí pro oba jazyky. Nejsem kovaný v kompilátorech, ale selský rozum dlouholetého programátora mi napovídá, že z hlediska kompilátoru si neumím představit proč kompilovat oba jazyky jinak.

Neznám prostě jediný důvod, proč by C++ kód měl být byť jen o milióntinu procenta pomalejší. Je samozřejmé, že musíte kompilovat za stejných podmínek a stejným kompilátorem. Není k tomu prostě důvod.

Ta Eckelova hlaska pochadza este z doby, ked C++ kompilatory prekladali do C (vidiet ten vysledok medzikompilacie byvalo niekedy velmi 'rajcovne') a potom sa ten "produkt" kompiloval do binarnehom kodu standardnym C-kompilatorom. Dnes je uz situacia uplne ina a vdaka otimalizacnym metodam sa uz neda ani priblizne urcit, kolko a ako dlho vlastne nejaku kus kodu pobezi, co sa dalo urobit kedysi davno v C-cku (dnes to este pouzivam pri programovani na mikrokontroleroch, kde su presne casove relacie niekedy velmi dolezite). Takze v diskutovanom probleme - ak je problem algoritmicky cisty (optimalizovany atd.), treba to pisat v dacom, co je najblizie k CPU - ak treba, tak aj podprogramy v asm atd. Veci, ktore viac zavisia od OS, komunikacia, vyuzivaju cudzie kniznice atd. pochopitelne nema vyznam pisat v asm, ale treba pouzit (hociktory vhodny) vyssi jazyk, lebo v takomto pripade zase plati stare zname, ze "kvoli stromom nevidime les".

Souhlas.

Ja muzu rict, ze bych doporucil C#, zvlast, pokud se ho ted ucite a v C++ jsi dloho nepsal.
1) Pokud budes pouzivat velke mnozstvi souboru, rychlost kodu tveho programu je temer irelevantni - zasadni bude rychlost tech IO operaci.
2) V C++ mohou byt nektere veci rychlejsi, ale v C# je mnoho veci snazsich, coz napriklad uvolnuje ruce programatorovi, aby se zabyval "high level" optimalizaci, coz muze znamenat ve vysledku rychlejsi kod.
3) Pokud vytipujes misto, ktere je vykonnostne opravdu kriticke a pritom v C# nejde napsat tak, jak by sis pral, treba pomuze unsafe mod.

4) Je mozne, ze to co pisu neni dobra rada, protoze to cos napsal skutecne nerika dost o tom, co vlastne delas. Pokud je ta prace zalozena na matematickem zpracovani cehosi, treba bude opravdu nejlepsi volbou nejaky specializovany matematicky software.

a co kategorie portable assembler, samozrejme stare dobre C (C99)?
nema sice ficury co C++ (pro praci s maticemi me napada pretezovani operatoru) ale
zase vis _presne_ co delas a _presne_ proc je to pomale/rychle.

z praxe, C v prumeru vychazi 4 rychleji na pcu/pamet nez C++, ale vecinou i lip, dano tim C++kari sou vecinou nejaky nahodny opicky co ani presne nevi co ten jazyk (a jak rychle) dokaze...

ze nema C interface a implementation? ale panacku, procpak se asi vsechno rozdeluje
do vice .c souboru a v .h sou takove ty extern ... :)

a ze C nema automatic memory management (garbage collector), vezte ze ma a to hned nekolik (z fleku treba Boehm - http://www.hpl.hp.com/personal/Hans_Boehm/gc/, vetsinou
se ale vyplati napsat si nejaky pseudovlastni pro danou ulohu).

.NET/Java atp jsou naprosto mimo a vhodne opravdu jen na RAD kde vypocetni cas je kratsi nez cas potrebny k napsani aplikace. Na nejake seriozni vypocty te s polointerpretovanymi jazyky vyhodej - to neni nic jineho nez mrhani vypocetnim casem a hlavne pameti - nad tou mas faktickou kontrolu opravdu jen v C. C++ je ta nejzassi hranice.

kategorie ciste (pseudo)funkcionalnich jazyku kde se zamerujes na algoritmickou cistotu/efektivitu (lisp,ocaml,haskell..) je trosku jina liga, tato uloha do nich pravdepodobne nespada.

a jestli fakt chces jenom provokovat oponenturu, tak to napis ve forthu (vetsinu casu stravi tim ze to budou lustit a zjistovat cim to prelozit)

Omlouvam se, ale nerozumim (i po docela dost letech praxe s obema jazyky) ... cim se tolik lisi prace s pameti v C a C++, ze tam nemam nad ni faktickou kontrolu?

A rozdil v rychlosti ... prijde mi, ze jediny rozdil, proc by mohlo byt C++ pomalejsi je ten, ktery jste uvedl - osoba programatora.

Jinak souhlasim.

Je to volovina, práce s pamětí v C a C++ se v zásadě neliší v ničem a v obou jazycích jí máte naprosto pod kontrolou.

Velmi často se vyskytují názory obhajující C před C++ s různými smyšlenkami ve stylu "v C to mám víc pod kontrolou" (naprostá blbost), nebo "v C je lepší kontrola paměťi" (otázka: kde?), nebo spousta dalších lží.

C a C++ dokáže udělat stejně rychlý, efektivní program a v obou jazycích to máte pod kontrolou přesně jak budete potřebovat. Akorát v C _musíte_ řešit problémy, které C++ leckdy vyřeší za Vás, pokud ho o to požádáte.

Akceptovatelným důvodem proč lidé dávají přednost C před C++ v nových projektech je ten, že neumím C++ (pak je ale potřeba jasně sdělit, že C++ neumím a neztrapňovat se argumenty ve stylu, že v C++ nemám věci pod kontrolou, nebo je tam horší správa pěmti a podobnými nepravdami), nebo ten, že používám exotickou architekturu, kde neexistuje dobrý kompilátor C++ (pak často existuje jen kompromisní kompilátor C, často je třeba nutné definovat K&R syntaxi funkcí).

Pro spoustu lidí je C++ složité a pak dávají přednost C, ale je třeba aby nelhali.

A proc je teda kernel v C a ne v C++?
Ze by neumeli C++? To se mi nezda...

Co takhle zkusit Sphinx C-- :-)

četl jsem, že kernel Linuxu, nebo alespoň jeho část, byla před nějakou dobou LT přepsána do C++, ale LT nebyl spokojen z výkonem a proto se vrátilo zpět k C. Přiznávám se, že C++ neumím, ale to neznamená, že C++ je lepší než jazyky, které znám (C, Java, C#,...) :-)

Tomáš

Alokace objektu není v C++ náročnější, pokud se použije malloc/free. Alokace pomocí new/delete záleží na implementaci new/delete, a pokud chcete není nic jednoduššího, než si na několika řádcích vlastní new/delete napsat. Změřením rychlosti neměříte rychlost C++, ale konkrétní implementace.

Assembler nedoporučuji, protože pokud nejste opravdoví machři, jakých je možná pár na světě, tak C/C++ udělá rychlejší kód, než Vy v assembleru. Ono totiž napsat rychlý kód v něm není žádná legrace a není problém, aby nepatrná změna v kódu, třeba přehození dvou instrukcí způsobila změny rychlosti o desítky procent. Zápas mezi asm a Intel C/C++ kompilátor určitě vyhraje v rychlosti ten Intel C/C++ kompilátor. Výjimku tvoří jen pár velmi nabušených lidí na této planetě.

Alokace objektu není v C++ náročnější, pokud se použije malloc/free. Alokace pomocí new/delete záleží na implementaci new/delete, a pokud chcete není nic jednoduššího, než si na několika řádcích vlastní new/delete napsat. Změřením rychlosti neměříte rychlost C++, ale konkrétní implementace.

Assembler nedoporučuji, protože pokud nejste opravdoví machři, jakých je možná pár na světě, tak C/C++ udělá rychlejší kód, než Vy v assembleru. Ono totiž napsat rychlý kód v něm není žádná legrace a není problém, aby nepatrná změna v kódu, třeba přehození dvou instrukcí způsobila změny rychlosti o desítky procent. Zápas mezi asm a Intel C/C++ kompilátor určitě vyhraje v rychlosti ten Intel C/C++ kompilátor. Výjimku tvoří jen pár velmi nabušených lidí na této planetě.

Víte, ani LT neumí vše. LT prostě nemá zkušenosti s C++, které jsou potřeba pro efektivní psaní. Až bude LT tvrdit, že stavěl barák a nebyl spokojen, možná je to tím, že jsou lepší zedníci, než LT. A stejné je to i s LT a C++.

C++ je prostě jeden z jazyků, je to nejefektivnější jazyk pokud chcete z počítače vymáčknout maximum (s výjimkou strojáku). Pokud chcete tohle, je C++ lepší. Pokud chcete něco jiného, mohou existoval lepší jazyky na daný účel.