Za 12,3%.

Zavisi ko pise kod, ta brojka moze da bude cak i 12,98%, ako je "asm guru" pisao engine..

Hehe, damn right :)

Otkud vam tako precizni podaci do u decimalu - je l' to negde vec pise?

(Uzgred - ja sam mislio da je odgovor nesto tipa 30% tu negde... ali nije ni 12-13% za bacanje.)

Ne pise. Odgovori koje su dobio su sarkasticni. Razlog za to je tvoje pitanje..

Pre mozda 30 godina je pitanje "koliko puta je nesto brze napisano u assembly-ju nego to isto napisano u X jeziku?" i imalo nekog smisla, ali odavno to vise nije slucaj. Kompajleri su toliko razvijeni da generisu kod koji je optimizovaniji nego da ga je vecina (danasnjih) programera pisala rucno u asm-u.

A sto se konkretno 3D engine-a tice, bas bih voleo da vidim neki pisan u asm-u (a da je komercijalnog kvaliteta).. to se jednostavno ne isplati, a sto se prednosti u performansama tice ona je ili zanemarljiva ili nikakva, na danasnjem hadrware-u.

:) OK. Pitam iz radoznalosti.
Hmm... jesi li siguran oko ovog sa kompajlerima - sve funkcije (itd.) su pisane genericki da podrzavaju razlicite slucajeve primene date funkcije (razliciti tipovi promenljiva i razliciti metodi i sta sve ne) - nekako mi je logicno onda bilo pretpostaviti da bi brze radio kod pisan specificno za konkretnu radnju u programu i apsolutno nista vise...

Nije zapravo nikada jer razliciti ljudi pisu razlicito kvalitetan software. Moze neko bolji engine da napravi u c++ nego neko drugi u asm-u. Cak ne mozes porediti ni za slucaj da jedan covek radi oba i da je u oba ekspert jer ce pravljenjem jednog endzina steci neko iskustvo pa to vise nece biti isti onaj programer.


Zapravo je i nebitno. Grafika koja bi se izvrsavala na procesoru bi u svakom slucaju bila prespora. Grafiku izvrsava graficka kartica i to tako sto ima direktnu podrsku za directx i/ili opengl i skroz je nebitno iz kog jezika pozoves funkcije kad ces dobiti isto izvrsavanje. Jedina razlika bi bila u nekim drugim proracunima ali su oni manji deo problema a i tu se mnogo toga sada prebacuje na gpu.

@Blabla
Izmedju onoga sto pise u programu i onoga sto se desi na ekranu stoji i graficka karta, tj. njen drajver...tako da to ne ide bas tako kako ti mislis...
Osim ako bi pisao 3d engine za recimo Arduino :)

@Blablabla,

Ako pricamo o 3D Engine-u koji koristi hardversku 3D akceleraciju (OpenGL, Direct3D) onda je gubljenje vremena pokusavati raspisati ceo engine u asembleru posto CPU i ovako i onako nece procesirati tu geometriju nego GPU. Tu mozes eventualno da se posvetis pisanju optimizovanih shader-a a to je kod koji se izvrsava na GPU-u - nije asembler, ali je dovoljno low-level da imas kontrolu nad desavanjima.

Ako pricamo o nekom softverskom 3D engine-u - onda se eventualno isplati pisati neke kriticne delove u asembleru ako znas sta radis, opet nikako ne ceo kod. Ali da bi napisao brzi kod od nekog dobrog C kompajlera moras da budes bas dobar u tome sto radis.

Znaci, pocni od C/C++-a a onda ako imas neke delove za koje mislis da su spori, uradi sledece stvari - po redu bitnosti:

1. Da li ti je sam algoritam optimalan? Ako nije, nikakve optimizacije koda ti to nece nadomestiti.... Recimo ako ti treba depth-sorting za transparenciju, i to radis metodom grube sile - mozes da ga optimizujes koliko hoces, na vecem broju primitiva ima da ti zaustavi sve :)

2. Ako si siguran da ti je algoritam dobar, vidi da li si ga imlementirao u samom C/C++ kako treba imajuci u vidu platformu na kojoj radis i "best practices" za nju (uravnanje podataka, da li kompajler koristi odgovarajuce instrukcije za CPU, preciznost matematickih operacija, da li zoves koristis sistemske API-je kako treba, da li ne kopiras memoriju osim kada zaista treba itd...)

3. Tek kada si iscrpeo #1 i #2 - onda prelazis na analizu asemblerskog koda koji ti je generisao kompajler, i TEK onda, ako vidis da nesto nije otpimalno mozes da probas da raspises rucno rutinu koja je u pitanju...

Ova 3 koraka su ti najoptimalniji nacin - ako odmah krenes na #3 - em ces mozda propustiti neke mnogo krupnije stvari, em ces potrositi mnooogo vise vremena i na kraju mozda neces dobiti brzi kod.

Sto nas dovodi do sledece teme:
:D
3D engine napisan za GPU na masinskom jeziku koji radi sam (bez upotrebe tudjih rutina). =D q:9


...Ali ne - ozbiljno - moje prvobitno pitanje je bilo ne-prakticne nego cisto teorijske prirode -- evo: zamislimo da je neko po najboljim mogucim algoritmima napravio dva programa identicnih mogucnosti KOJI KORISTE ISKLJUCIVO CPU - dakle bez GPU --- jedan u C++-u jedan u asembleru - i onda - koliko brze bi radio ovaj u asembleru? Eto.

Znaci, cista teorija, potpuno optimalan program, idealno napisan, naravno da ce brze da radi u asembleru, zbog manjeg overheada.


Ali praksa je naravno nesto drugo... jos pogotovu kad uracunas programerovo vreme (=platu) :)

pre par godina su valjda neki nemci napravili FPS u samo 96kb. Asm il' ne, al' ja sam se odusevio :)
Evo linka : http://www.theprodukkt.com/home

To nema veze sa asmom, tu se radi o proceduralnom generisanju objekata, materijala, osvetljenja i svega ostalog na licu mesta. Cak su izbacili i alat, Werkkzeug, neku vrstu editora koja ti omogucava obicnom korisniku da uradi nesto slicno.

Da. Video sam pre par godina. Kriger. I meni je to bilo fantasticno - do duse malo mi je zapinjalo. Kapiram da su za svaku stvar koristili matematicku formulu (imajuci tu pre svega u vidu teksture i zvuk - kapiram da je sve sintetizovano a ne semplovano (sad vidim da je 3way to objasnio vec))... (Uzgred: takodje mi je skrenulo paznju i to da neki od njihovih produkkt-ova imaju viruse.)



Da. Pitanje je bilo: Za koliko brzi?




Heh, Kao sto sam rekao - pitanje je totalno teoretsko, bez prakticnih tematika i ~temologija~ (je l' ima ta rec? =D (google... a - ima 'epistemologija'... to mu dodje to onda)).

Nego - fascinira me ta fantazija: zamisli jednu prostoriju sa 100 osoba koji iz za'ebancije eto znaju da programiraju u nekom jeziku (ali, ono, posteno znaju -- respekt) i eto tako iz zezanja su tu; predstavi im se algoritam i ulazi i izlazi funkcija kako treba da budu - i pazi sad - za ono za sta treba jednoj osobi 100h rada (to je 10 dana ako radis 10h dnevno) - oni podelom posla urade za 1 sat! (znaci (prvobitno bar) samo radi postojanja, eto, nekog korisnog programa - nema firme, nema zamlacivanja sa svim stvarima koje s time dolaze - samo neki licni prostor i neko licno vreme (...moze i preko 'neta kolaboracija, ali nije to to - bolje je kad su svi na jednom mestu - nekako je mocan osecaj taj momenat svesti da takva grupa moze sve i odmah :D ~GODS~ :D ))

(Mislim - to mi je nekako naprosto fascinantno - samo kazem, ima neku cudnovatu draz taj koncept: od potpunog nepostojanja ideje preko stvaranja ideje za program do njegove ~ovozemaljske egzistencije~ moze da je dovoljno 1 h (i slovima: jedan sat - JEDAN sat (ne znam da li ste razumeli dobro pa cu da ponovim: JEDAN - znaci ono... ne znam kako da objasnim da bi bilo dovoljno jasno...)). ...U svakom slucaju korisnije od mnogih stvari na koje se dan inace uobicajeno potrosi.)

...



_{[Ovu poruku je menjao Blablabla dana 18.08.2011. u 23:01 GMT+1]}

Nismo dosli do odgovora na pitanje teme (moje prvobitno pitanje je bilo ne-prakticne nego cisto teorijske prirode -- zamislimo da je neko po najboljim mogucim algoritmima napravio dva programa identicnih mogucnosti KOJI KORISTE ISKLJUCIVO CPU - dakle bez GPU --- jedan u C++-u jedan u asembleru - i onda - KOLIKO BRZE bi radio ovaj u asembleru?).

Rade istom brzinom :)

Tajodgovor je isti kao da si rekao da radi 1000 puta brze. :D

Ako je nešto najbolje onda bolje od toga ne može sve jedno ko to napisao (kompajler ili čovek). Istom brzinom će raditi, tako da je moj odgovor tačan :)

Ne verujem da kompajler moze da optimizuje program toliko dobro koliko bi covek licno mogao da ga sazme.

U svakom slucaju - jedno je najbolje sto je moguce napisati program u C++, a sasvim deseto najbolje sto je moguce napisati program u asembleru (!) - zasigurno bi ovaj u asembleru radio brze - pitanje je samo koliko brze?

Uglavnom većina stvari koje ste spomenuli ovde su skroz nebitne za brzinu... Naime moderni procesori su toliko brzi da većinu vremena provode čekajući da se deo memorije iz RAM-a prebaci u cache ili iz višeg cache-a u niži. Tako da je ako se zaboravi na cache moguće napisati kod u asembleru koji ima manje instruckcija od C++ koda i ima mnogo lošije performanse. Problem sa C++ je da uglavnom programeri koji pišu u C++ nemaju pojma šta je cache i kako uopšte memorija iz RAM-a stiže do CPU-a. pa samim tim i skloniji su da kreiraju sporiji kod. Recimo neko u asembler nikada neće koristiti shared_ptr, iako nepotrebno, sasvim normalno videti u C++ kodu. To su 2-3 cache miss-a po korišćenju. 1 za count++, 2 za raw pointer, i 3 ako je u toku pristupa toj memoriji shared_ptr izbačen iz cache-a kada se radi count--. Uglavnom u sadašnje vreme osim par izuzetaka niko ne piše kod za igre u asembleru. I kada se piše piše se za specijalne procesore gde to ima smisla, u manjem obimu za CPU.