[ Blablabla @ 16.08.2011. 22:34 ] @
Koliko puta je brzi 3D engine napravljen u asembleru od onog napravljenog u C++-u?
[ Shadowed @ 16.08.2011. 23:08 ] @
Za 12,3%.
[ Aleksandar Ružičić @ 16.08.2011. 23:20 ] @
Zavisi ko pise kod, ta brojka moze da bude cak i 12,98%, ako je "asm guru" pisao engine..
[ Mikky @ 17.08.2011. 01:45 ] @
Hehe, damn right :)
[ Blablabla @ 17.08.2011. 23:02 ] @
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.)
[ Aleksandar Ružičić @ 17.08.2011. 23:51 ] @
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.
[ Blablabla @ 17.08.2011. 23:59 ] @
:) 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...
[ Shadowed @ 18.08.2011. 00:04 ] @
Citat:
Aleksandar Ružičić: 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

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.

Citat:
Aleksandar Ružičić: 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.

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.
[ 3way @ 18.08.2011. 00:06 ] @
@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 :)
[ Ivan Dimkovic @ 18.08.2011. 00:20 ] @
@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.
[ Blablabla @ 18.08.2011. 00:48 ] @
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.
[ mulaz @ 18.08.2011. 02:14 ] @
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) :)
[ sheiks @ 18.08.2011. 09:20 ] @
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
[ 3way @ 18.08.2011. 10:15 ] @
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.
[ Blablabla @ 18.08.2011. 21:51 ] @
Citat:
sheiks: 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


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.)

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


Da. Pitanje je bilo: Za koliko brzi?


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


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]
[ Blablabla @ 20.08.2011. 23:45 ] @
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?).
[ vujkev @ 20.08.2011. 23:49 ] @
Citat:
Blablabla: ... zamislimo da je neko po najboljim mogucim algoritmima napravio dva programa identicnih mogucnosti...

Rade istom brzinom :)
[ Blablabla @ 21.08.2011. 02:00 ] @
Tajodgovor je isti kao da si rekao da radi 1000 puta brze. :D
[ vujkev @ 21.08.2011. 07:03 ] @
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 :)
[ Blablabla @ 22.08.2011. 01:24 ] @
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?
[ bkaradzic @ 22.08.2011. 03:35 ] @
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.