[ Dragi Tata @ 13.03.2002. 23:37 ] @
Interesantan članak:

http://www.eventhelix.com/Real...omparingCPPAndCPerformance.htm

Molim za komentare.
[ leka @ 14.03.2002. 00:48 ] @
D.T. pre svega hvala za link - odstampao sam oba teksta. Super su primeri...
Nisam imao vremena da ozbiljno citam, jedino sto mogu da kazem je da treba obratiti paznju ne samo na brzinu ovde, vec treba obratiti paznju na velicinu koda i nacin izvedbe...

C kod ce dati brzi program, ali zato C++ kod je mnogo pregledniji i kraci...

Sta misle ostali?
[ Milan Aksic @ 14.03.2002. 06:07 ] @
Vrlo dobar text, mada moram da priznam da mi je dolovao malo zbunjujuce, na trenutak, kada sam video C implementaciju (virtuelne) klase i v-table ;)
Da li je opet C kod definitvno brzi od C++ ... i da li pri ocenjivanju performansi treba uzimati u svim uslovima/primenama brzinu kao primarni faktor !? Velicina, odrzavanje, vreme za pisanje koda, sigurnost, resursi ... nisu mnogo manje bitniji faktori.
Mislim da bi trebalo, za odredjenu stvar treba upotrebiti pravi resenje, ipak:

In a well designed object oriented system, a virtual function call would typically replace a switch statement so virtual function invocation might actually be faster than conventional coding techniques. For example, a generic draw statement in a "C" based paint program would involve switching over the type of shape and then invoking the corresponding draw function. In C++, this logic will be replaced by a virtual function call.

Verujem da ce jos (duze) vreme oba jezika nalaziti svoju primenu u raznim oblastima.
Mada, ipak mislim da C++ pruza vecu snagu. Zasto ? Jer je uvek moguce, bez mnogo problema, u C++ kod korstiti C kod, dok obrnuto ide malo teze ;)

Pozdrav.
[ Predrag Damnjanovic @ 14.03.2002. 09:46 ] @
Ova dva texta upredjuju 'C++ sa C-om', dakle uzeti su primeri iz OOP-a i pokusali su da ih prevedu na C.
Normalno je da ces da imas veci kod kada OOP implementiras u C, tu nije ni bilo diskusije.

Ali, pitanje je ovde da li je ovaj C++ kod, kad se iskompajlira, stvarno brzi i manji.
Binarni zapisi, koliko znam, ne podrzavaju OOP :), dakle sav OOP kod mora da se prevede u binarni oblik.
Pitanje je, ne dobijamo li isti kod kad se oba primera prevedu u binarni oblik?
Cak sta vise, mislim da se u binarnom fajlu (koji je nastao od C++ koda) ubaci jos sto sta, sto jos vise uspori ceo kod.

I kad bi uporedili 'C sa C++-om', dakle da se uzme C primer i da ga urade na OOP nacin - bila bi druga prica, svi znate ko bi bio brzi, i ciji i kod i sors bi bio manji.
[ Ivan Dimkovic @ 14.03.2002. 10:39 ] @
Danasnji sistemi su postali toliko brzi da je insistiranje na nekom procentu brzine a zarad udobnosti rada smesno - lakse je dokupiti 10% brzi procesor za $100 nego raditi projekat u necemu sto se teze i skuplje (mnogo skuplje od $100) odrzava!

Sve je stvar nekog veceg plana, mislim da je ta brzina najmanje bitan parametar - postoje mnogo bitnije stvari koje bi nekog naterale da koristi C umesto C++ i obrnuto.

Moguce je i kombinovati C i C++ pa neke module koji se pozivaju mnogo puta u sekundi implementirati u C-u ili cak asembleru a ostatak projekta u C++ - time se ne zrtvuje organizacija projekta, itd...


Verovatno se secate da su sve kompjuterske igrice pisane u cistom asembleru, i da je pominjanje C-a bilo ravno svetogrdju - svi su govorili kako samo u asembleru moze da se generise najbrzi kod, itd... svi znamo kako se danas pisu igre :)

[ Predrag Damnjanovic @ 14.03.2002. 11:08 ] @
Citat:
Ivan Dimkovic:
Danasnji sistemi su postali toliko brzi da je insistiranje na nekom procentu brzine a zarad udobnosti rada smesno - lakse je dokupiti 10% brzi procesor za $100 nego raditi projekat u necemu sto se teze i skuplje (mnogo skuplje od $100) odrzava!

Sto jes' jes', priznajem da je bolje OOP za velike projekte.
To i ne sporim.
Ali ako objektivno govorimo o brzini, C je brzi.
[ Dragi Tata @ 14.03.2002. 16:32 ] @
Po meni, poenta gornjeg članka nije u tome da se dokaže da je jedan ili drugi jezik brži (u ovom slučaju, to i nema smisla, jer je C podskup C++a, pa je svaki C program istovremeno i C++ program), već treba uočiti koje programske konstrukcije u C++u mogu da dovedu do usporavanja koda, a koje ne. Recimo, ja sam mislio da se glavni penali plaćaju kod upotrebe virtuelnih funkcija, ali ovi ljudi tvrde da su glavni gubici brzine kod poziva konstruktora i destruktora; ne znam, ali ja uglavnom konstruktore i destruktore pišem inline (osim ako su baš komplikovani) a tad nema poziva...

Posebno je interesantna opservacija da je kod generisan od C++ a "kompaktniji" pa lakše stane u keš. Ako je to istina, onda u stvari većina C++ programa radi brže nego odgovarajući C programi. Moraću da napravim neke testove kad budem imao vremena, pa da proverim.

A što se upotrebe assemblera tiče, interesantno je da će moderni C/C++ kompajleri da naprave brži kod nego što je to u stanju da uradi većina assembler programera. A posebno je zgodno što u slučajevima kad smo sigurni da ćemo napraviti brži kod "ručno" u assembleru, to možemo da ubacimo u C/C++ funkciju i tako dobijemo istovremeno brzinu i preglednost.
[ masetrt @ 05.04.2002. 00:36 ] @
Citat:
Ivan Dimkovic:
Danasnji sistemi su postali toliko brzi da je insistiranje na nekom procentu brzine a zarad udobnosti rada smesno - lakse je dokupiti 10% brzi procesor za $100 nego raditi projekat u necemu sto se teze i skuplje (mnogo skuplje od $100) odrzava!



Sve je stvar nekog veceg plana, mislim da je ta brzina najmanje bitan parametar - postoje mnogo bitnije stvari koje bi nekog naterale da koristi C umesto C++ i obrnuto.



Moguce je i kombinovati C i C++ pa neke module koji se pozivaju mnogo puta u sekundi implementirati u C-u ili cak asembleru a ostatak projekta u C++ - time se ne zrtvuje organizacija projekta, itd...





Verovatno se secate da su sve kompjuterske igrice pisane u cistom asembleru, i da je pominjanje C-a bilo ravno svetogrdju - svi su govorili kako samo u asembleru moze da se generise najbrzi kod, itd... svi znamo kako se danas pisu igre :)





Po mom skromnom misljenju tu si potpuno u pravu(ali samo tu, citao sam neke tvoje druge odgovore)
[ Ivan Dimkovic @ 05.04.2002. 00:41 ] @
Ako mislis da neki moj odgovor nije dobar, slobodno iznesi svoje misljenje u tom forumu kako bi mogli argumentovano da diskutujemo o tome, i ako se pokaze da si u pravu ja cu svakako prihvatiti sugestiju, zato forum i sluzi :)

Proizvoljne konstatacije "ali samo tu (si u pravu)" ne mogu da prihvatim jer mislim da su bas (i samo) to - proizvoljne konstatacije.
[ Dragi Tata @ 07.04.2002. 23:02 ] @
Nasuprot Marku, ja se slažem sa većinom Ivanovih postova, ali ne i sa ovim. Performanse su još uvek jako bitne u svetu računara, a uvek će i da budu. Naravno, postoje i programi koji ne zahtevaju veliku brzinu rada, ali takvi programi se obično pišu u nekim drugim programskim jezicima.
[ Ivan Dimkovic @ 08.04.2002. 01:07 ] @
Pa mislim da sam dodao uslov, ako je maximum brzine ipak bitan za projekat - u modernim kompajlerima je uvek moguce neke funkcije implementirati u asembleru ako je brzina kritican parametar - ovo je moguce raditi i u C++ i u C.

U poslu koji ja radim (multimedia compression) obicno se prvo odradi potpuno cist ANSI-C (ili ISO C++) kod, koji se bez problema kompajlira na svim sistemima. Posle optimizacije kvaliteta i ciscenja gresaka se kod "zamrzne" - a onda se rade posebne verzije za target CPU, uz primenu sve sile optimizacija (MMX/SSE/SSEII matematicke funkcije i vektorska algebra)

Za DSP cipove se obicno svaka kriticna funkcija optimizuje asemblerski, dok se ne postigne real-time execution na najjeftinijem DSP-u.

Moj izbor je obicno ANSI-C sa Intel SPL bibliotekom i malo __inline assemblera. C++ obicno ne koristim, ali cak i da ga koristim ne verujem da bi doslo do nekog znacajnog gubitka u performansama, jer bih izbegavao virtuelne funkcije koje su bottleneck u C++ programima.

DSP portovanje obicno ne radim, kolega iz partnerske firme je portovao neki moj projekat na TriMedia platformu i mislim da je kod ostao cist ANSI-C, sa eventualno malih kozmetickih promena (bio je problem kod nekog zaokruzivanja) - Za takve stvari bih ipak preporucio cist C, jer jos ima DSP firmi koje imaju slabe C++ kompajlere.