C# Win32 API

Uf... Runtime compajliranje ima više informacija i može postići bolji kod od statičkog. Naravno, ako želiš kompajlirati za svaki hardver posebnu verziju, i onda isporučivati 32 verzije exe fajlova uz svoj program, be my guest :)

Teorija o tome je epskih proporcija, ali za početak http://www.javaperformancetuning.com/news/qotm042.shtml

Preporučam "Diary of x264 developer" pa vidi iz prve ruke kako compiler (statički) zna bolje od čovjeka optimizirati za brzo izvođenje, pogotovo držati kod dovoljno malen za izvršavanje u L1 cacheu :)

Nisam ni mislio na runtime kompajliranje vs staticko samo po sebi. Nego na optimizacije koje mozes unjeti statickim kompajliranjem pomocu assemblyja, a koje ne mozes koristiti kada je JIT u pitanju.

Ako uzmemo u obzir da je assembly napisan savrseno, niti jedan compiler (bilo JIT, bilo staticki) to ne moze nadmasiti.

I ne mora biti 32 verzije izvrsnih datoteka. Dovoljno je unjeti razlicite code pathove unutar samog programa za odredene arhitekture. Ono osnovno vec imas, jos se pobrines za pravilan alignment odredenih varijabli (to se moze i pri runtimeu), a dijelove koda koji su najzahtjevniji napises tako da stanu u L1 cache, te oni opsirniji u L2 cache. Velicinu cachea si uzimas po sistemu najnizeg zajednickog nazivnika.

Da se osvrnem samo na neke argumente linkanog teksta:

In general Java today is C++ equivalent in speed. There are some micro tasks that C will always do better. These involve random access into large byte array fields. Decoding MPEG streams is the classic example. Thats why we ship a JNI based codec with JMF. (Even in this extreme case though it only buys us about 15% speed improvement.)

Evo, lik je sam priznao da se ekstremnije optimizacije mogu izvrsiti sa low level jezicima.

There are some tasks Java will almost always beat C at. Java allocation and deallocation is lightning fast compared to C. Our better optimization of loops and recursion also seem to, for some reason, result in a FFT that always ends up beating the best C counterpart.

Osim ako ne napises vlastiti alokator, tada Java vise nije brza. Standardni C alokator je univerzalni, a program koji pokusava zadovoljiti sve ne moze biti najbolji u necemu. Postoji cijela znanost o alokaciji memorije, linux raspolaze sa n razlicith alokatora (svaki optimiziran za svoju namjenu).

Takoder kriticne petlje mogu biti pisane u assemblyju (uzmimo u svrhu argumenta da osoba koja pise taj assembly zna sto radi), te ce opet ispasti brze od klasicnog kompajliranog koda (bilo JIT ili staticki).

Dakle da zakljucimo. Jep, JIT kompajler u odnosu na staticki kompajler ima potencijala za proizvodnju brzeg kôda, ali isto tako moze biti i losiji od obicnog statickog kompajlera. Lijepo sve te optimizacije izgledaju na papiru, ali ako ih kompajler ne izvrsava (recimo ne prepoznaje da bi se neki dio dobro optimizirao SIMD instrukcijama) sve pada u vodu, i staticki kompajler koji mozda taj dio radi pravilno ga i dalje moze poraziti. Gledam na phoronixu benchmarke razlicitih kompajlera i dobro znam koliko drasticne razlike mogu biti ako kompajler ucini samo jednu krivu stvar (a cine ih). Takoder tu je jos uvijek pitanje rucno napisanih optimizacija...

To je bilo u svrhu argumenta, u biti i sâm to znas. Ali zasto si namjerno tu izjavu docekao na noz, i pogresno protumacio je tvoja stvar. Dakle govorio sam o nekakvom hipotetskom assembly kôdu, optimiziranom do krajnjih, granica za jednu platformu, u usporedbi sa JIT kôdom za tu istu platformu.

Kada kompajleri postanu savrseni, bez da fulaju odredene optimizacije, ili kada igre masovno pocnu biti pisane u JIT kompajliranim programskim jezicima (flash ne racunam, da se razumijemo), onda ce za mene JIT imati nekakvu tezinu.

Ovdje sada govorimo o nekakvom super brzom JIT kodu, a programi koji bi actually i imali koristi od te "brzine i optimiziranosti" su i dalje pisani u Assembleru, C-u i C++-u. Paradoks? Mislim da to dovoljno govori o danasnjim dosezima JIT compilera. Tvoja logika, koja pretpostavlja da je JIT kompajler (i staticki kompajler sto se toga tice) bez greske i da na nekim dijelovima svojim "optimizacijama" nece ponekad cak i pogorsati perfomanse, ima manu.

Kada x264 ili Vray ili Brazil ili Lux render, ili cak hebeni Crysis, dakle kada oni budu koristili JIT compilere kao backend onda cemo pricati o superiornosti danasnjih JIT compilera.

Pa neces bankovne aplikacije raditi u assembleru, ili sta ja znam, novi tekst procesor :P

Kada govorim o pisanju assembly kôda zna se tocno na kakve primjene ciljam.

A sto volis izvlaciti stvari iz konteksta...

Itekako se svodi na "ukljuci par...". Procitaj tocno sto sam mu odgovarao. Covjek lijepo kaze da nema ideju kako poceti sa 3D grafikom - sto ukljucuje i cinjenicu da doslovce ne zna sto treba raditi (includeati headere koje?, linkati sa odredenim bibliotekama, kojim? sto je linkanje?).

Napraviti kocku koja se rotira oko Y osi u OpenGL-u je takoder 3D programiranje, je li komplicirano? Nije. Treba li mu neko osnovno znanje iz trigonometrije i po mogucnosti linearne algebre i matrica? Treba. Je li ta kocka nesto super mastovito? Nije. Hoce li mu ta kocka postaviti neke temelje? Hoce.

Sto sam mu trebao reci, uci spherical harmonicse, deferred rendering, radiosity, inverznu kinematiku, octree podjelu prostora, perlin noise algoritme? Kakve koristi bi imao od toga? Zar ce se odmah bacati na pisanje novog Crysisa? Jesam li mu trebao reci uf to ti je tesko, trebas znati ovo, ovo, ovo? Bi li te to zadovoljilo? Jesi li ikada cuo za nesto sto se zove podizanje morala?

Isto ti je sa odlaskom u teretanu, pocnes s jednim jedinim podizanjem utega, to nije ni priblizno sve sto ces morati raditi da bi podigao misicnu masu, niti ce te to pretvoriti u bodybuildera, ali je pocetak.

Ja sam sa 2D grafikom poceo raditi tako sto sam iscrtao 1 (jedan), pixel na ekranu prije 10-ak godina. Jesam li tada znao sve sto moram znati za rad sa 2D grafikom? Ne. Je li taj pixel bio prekretnica i moj uvod u rad sa 2D grafikom? Itekako.

Ali ja mislim da ta brzina izvođenja koda nece u buducnosti igrati neku veliku ulogu jer hardver sve brzi i jaci postaje.

Moj problem je to što očekujem precizne tvrdnje. Priznajem, kriv sam :)

S obzirom da taj hipotetski kod zna napisati šaćica ljudi, čini ga poprilično irelevantnim. To što 90% ljudi koji počmu pistati ASM će zapravo napraviti još goru stvar, što ne govori u prilog tvrdnji da je ručno napisan kod uvijek bolji i brži. Ako još uzmeš u obzir održavanje koda... uh, sudbina Titanika je vidljiva s Marsa.

Ali mislim da ne shvaćaš što želim reći. Ne kažem da ručno do boli optimiziran ASM kod nije najbrža stvar na svijetu. Ne kažem da su kompajleri bez greške. Kažem da su bolji od većine would-be-ASM programera. Kažem da je to najbrža stvar na svijetu za točno određeni hardver. Ako radiš blokove tako da taman stanu u L1 na X2 procesoru, u velikom si problemu kad se program pokrene na i3 procesoru. To je jedan od primjera, ali nuspojava optimizacije je primjenjiva na sve aspekte. Onda se odmakneš korak iznad i uz određene penale (brzina, memorija) imaš kod koji je dovoljno dobro optimiziran za širi spektar hardvera i ulaznih podataka. U određenim slučajevima može biti i brži od poludobrog ASMa/Ca.

Potrebno je naći dobar omjer između brzine izvođenja i brzine pisanja/održavanja koda. Tako da ne pišeš sve u ASMu, nego samo kritične djelove koda. Ostatak pišeš u Cu. Pa onda to možeš sve pozivati i iz C#. Sinergija u kojoj pravi alat koristiš za pravi zadatak. Jednom ćemo sve moći pisati u nekom JIT jeziku, ali do tada moramo se snaći.

Evo, Dungeons igra mi se par puta srušila uz poznatu IL error poruku. Tko zna, možda je i pisana u C# :)

Kad već inzistiraš na ručnom pisanju ASM koda - tko ti brani da to činiš i u C#u, ako ti to uljepšava dan? Ne radi od kad je uveden NX bit, ali ionako je ovo akademske prirode.

http://www.atrevido.net/blog/PermaLink.aspx?guid=ac03f447-d487-45a6-8119-dc4fa1e932e1

Summa summarum, za točno određene svrhe, da, koristiti ću ASM. Za sve ostalo koristiti ću JIT jezik....

 -napokon!

Ne određuje alat cilj, nego obrnuto. Ovisno što se želi napraviti (glavni kriterij), tad se gleda čime, pa performanse (ili cijena, jednostavnost, platforma...).

Kompileri su danas već 99% optimizirani za neke algoritme, ipak ljudski faktor je važan, jer nema tog alata koji nadoknađuje neznanje korisnika (kao automobil).

Banalni primjer, Doom i Quake imaju iste korjene, tad se prelazilo s 386 na 486 (glavna razlika coprocessor 487 je dio CPUa) i počinje se prebacivati dio posla na njega. Recimo koristio se int za glasnoću, volume 0-15, zamjenjen floatom 0.00001 što ga u compileru (sa switchem za coproc) automatski prevodi i izvršava se paralelno dok CPU radi drugi dio posla. 586-Pentium generacija je to još više podigla zbog RISCa za coproc, pa dodatci MMX, SSE itd. To je usporedivo s 1->2 core.

Kompiler je kao kalikulator, kad ga se jednom dobro isprogramira on daje uvijek točan rezultat. Kao primjer ljudskog dijela su recimo ATI driveri, koji nakon nekog vremena izađu optimiziraniji-brži. Kompiler može samo automatski ili uz pomoć switcha recimo kod optimizirati za određeni CPU recimo s 3MB L3 i SSSE4.1 to nije 'kvaliteta' kao što nećemo reći da je kalikulator koji izračuna 2+2=4 reči da je kvalitetan ili vrhunski, nego samo ispravan.

Pošto je znanje to koje uvijek ostaje kao bitan kriterij, nevažno dali se radi u ASMu, Cu ... za taj nivo znanja su potrebne godine iskustva (da bi se prepoznale moguće optimizacije ili otklonio bug), kao i potreba kad izađe nova tehnologija (CPU) s više cachea, jezgri.. ipak to naprave ljudi.

Početnici, koji god jezik odabrali, neče pogriješiti. Jer u programerskim timovima gdje je to potrebno kad se zaposle proči će poneka godina dok uđu i A-tim. Tad će naučiti sve potrebno. NBA liga je primjer, godina na klupi, pa malo parketa...

Oni koji pak misle napraviti neki 3Dengine... -sretno. Nije nemoguće ali je teško, teže/rjeđe nego zgoditak na lotu.

-poanta je u 'štrikanju' koda. U vrijeme kad se WinAmp pojavio nov načina rada, mislim 9-18 threadova, jedan za play, jedan za efekte, za iscrtavanje efekata... upravo zato može sve raditi istovremeneo. (to je zapravo provid zbog brzine CPUa).

Za primjer pokušaj čuvati 9 ili više ovaca, ako uspiješ nazovi Jacu... ali ćeš primjetiti da nije lako.

-edit, noćni tipfeler u čitanju.. winapi..WinAPI ! ne WinAmp.

Samo da se ubacim, mislim da su cak i radeonovi driveri dijelo u  .net tehnologiji. LOL

 Ali, JIT kompajlirani kod moze biti brzi od 'obicnog'.

Zna netko u kojem jeziku je pisan softver za GPS uređaje (Garmin recimo) ?