OOPack: C/C++ tests

na slashdot.org imashe link za sravnenie mezhdu Intel C/C++ i GCC, i dokato go gledah - se natuknah na OOPack testa - znaeh za nego oshte otdavna - no ne mu bjah daval takova goljamo znachenie... Obache dosta golemi razliki pokazwa testa pri srawnenie na C sus C++ - na njakoi mesta C++ analogichnia kod e 5-puti po-baven! wow!

[линк] (wizhte za OOPack)

tirulirutatuutuu

Само 5 пъти ? Мислех че повече.
Зависи на колко нива е наследяването - например :-)))))))))))
Абе нали пишеш игри - не ти ли е правило впечатление преди ?

UB40 !

Не си напълно прав, че кодът е "аналогичен".
Тестът OOPack, също както и Stepanov Benchmark, измерват така нареченото "abstraction penalty" за C++ при различните компилатори. Тоест правят едно и също изчисление по различни начини и мерят разликите в производителността. Отделните начини се различават по нивото на абстракция - най-простото ниво е чисто C, а за всяко следващо се използват все по-сложни C++ конструкции. По-горните нива поставят високи изисквания към компилаторските оптимизации. Intel Compiler в момента е шампион, но все още не е перфектен. GCC също се представя доста добре, поне спрямо миналата година. GCC 3.0 куриозно генерираше по-добър C++ код отколкото C при теста на Stepanov, поради грешка в една от оптимизациите.
Да се върна на тезата си - кодът не е "аналогичен", понеже C++ вариантите са с умишлено усложнено описание. Естествено е, че може и на C++ да се пише също като на C, тогава разлика няма да има. Но когато операциите се обвият в няколко слоя абстракция, все някоя оптимизация ще се счупи. Btw, и двата теста - OOPack и Stepanov, се използват от разработчиците на GCC, а предполагам че и с другите компилатори е така.

Ne sum gledal OOPack skoro, prosto widjah cifrite - mozhe bi testa e subektiven.

No C++ nalaga kak da sa organizirani dannite mnogo ili malko.

Imash klas A, i klas B naslednik na A - tova znachi che ako imash obekt b ot klas B - to dannite mu winagi shte sa organizirani taka che purwo w pametta da sa tezi na A, a sled tova na B - w edna oshte po-slozhna hierarhia - 10 niva i navutre - tova postavja seriozni problemi sus keshiraneto na pametta. Naprimer neka Z da e poslednoto nivo wuw takava hierarhia - ako se poluchawa taka che Z chesto izpolzwa danni ot A (da kazhem objectID, ili razni drugi takiva) - to chesto se narushawa cache-corehenciata - i dannite koito stoijat mezhdu A i Z sa mnogo nadalacech.

Problema e che C++ ne ti dawa wuzmozhnost da si organizirash dannite ot nasledenite klasove kakto trjabwa. Razbira se tova ne sa go smetnali za neobhodimost.

Da ne govorim che turseneto po virtualni tablitzi izgarja kesha naj-burzo.

razbira se tuka govorim samo za skorost, kogato se stigne (kakto pishe w primera) do User Interface i podobni C++ e w silata si. Tam ne se tursi skororst na izpulnenie.

tirulirutatuutuu

Силата на C++ далеч не е само в наследяването на класовете. Съгласен съм, че vtable lookup-ът изгаря кеша, но ако се наложи да направиш същото нещо на чисто C пак ще го изгаря, само че сорсът ще е 10 пъти по голям.

C++ не дава възможност да организираш данните от наследените класове сам, защото това би било в противоречие с полиморфизма. Ако искаш друго разположение, просто не използвай наследяване - използвай класовете като обикновени структури.

C++ не е бавен. Той предоставя някои нови механизми спрямо C. Ако не ги ползваш, разлика няма. Можеш и на C да напишеш нещо, което да имитира наследяване, полиморфизъм, и виртуални функции, но по-голяма скорост няма да постигнеш. А нещата, които можеш да направиш в C++ с templates, никой друг език не ги може. За справка - [линк].

Ако наистина си твърдо убеден, че "C++ е по-бавен от C", опитай следното. Сравни бързодействието на едно сортиране посредством qsort() от <stdlib.h>, и на едно посредством std::sort() от <algorithm>. Дори и в калпавите имплементации на стандартната C++ библиотека (например Dinkumware-то във VC 6.0), std::sort() е по-бързо. Ако използваш STLport пък разликата вече е очевадна. Можеш да сравниш и леснотата, освен скоростта

ne wsushnost ne sum ubeden che C++ e po-baven ot C, winagi sum si mislil che podobni testove nishto ne pokazwat.

Wse edno da srawnim dve koli, no ednata tuj kato mozhe da mukne remarke (edin wid C++) trjabwa i sus remarketo da ja testwame kolko e burza :)

Edinstwenia problem kojto imam sus C++ e tova che dava prekaleno goljama svoboda na horata, i kakto znaete za da sushtestwuwa goljama svoboda trjabwa i po-obshirni, puk i strogi zakoni (e.g. Amerika za tova ima postojanno popravki w konstitutziata).

Malko sa iztrolirah az, kato che li :) :)

Sushto predimstwata koito dava C++ kato che li se zloupotrebjawa s tjah - naprimer sledsttwie Obektnoto orientirane - paketirame wsichko wuw strukturi(klasove) - no edin den kolegata e reshil da slozhi daden obekt ot njakakuw klas kato lokalna promenliva wuw funkcia - i se chudim zashto ne dostiga stek - ili zashto habin kesha taka burzo (golemi skokove wuw kesha sushto ne sa dobro neshto). Ili puk templatiziraneto za wseki razlichen enum tip, i sushto slaganeto na masa kod wuw header-failovete - tova vupreki che dawa hintove na kompilera kak da optimizira po-dobre - sushto pravi i koda dosta po-goljam - a po-goljam kod znachi i po-burzo habene na kesha (ako shtete mi wjarwate - no na PS2 pod gcc sus -O1 (optimizatzii za mjasto) igrata dawa po-dobur frame-rate ot tazi sus -O2 - prosto zashtoto koda beshe njakude sus 10-20% po-maluk i se pesteshe po-dobre kesha - toj ne e mnogo goljam pod PS2).

tirulirutatuutuu

Ми да, така е :) Понякога, inline-ването прави кода по-бавен. Тогава оптимизирането "for size" носи и по-голяма скорост. Всичко е според зависи, и всяко нещо трябва да се тества индивидуално. Трябва да има inline-ване, но с мярка, не безразборно.

Вярно е и че много се злоупотребява с някои възможности. Щом се научи някой нов трик и хайде, да го набутаме в програмата, нищо че не е за там. В това отношение намирам Scott Meyers за много полезен, води до отрезвяване и очиства от някои пороци