Fotografie mobila

N-ai doar doua necunoscute in offsetul asta, ci 3, avand in vedere ca miscarea poate presupune si rotatia ei.
Daca stau si ma gandesc nu e chiar atat de complicat, insa nu cred ca realiniaza toata imaginea. Pot sa fie si 5 linii de cod, nu mi-e clar cum se face si cat e de paralelizabila partea asta de realiniere.
Insa la urma urmei nici nu conteaza intrucat nu esti obligat sa calculezi offsetul pentru toata matricea, ci doar pentru cativa pixeli si apoi il aplici intregii matrici. Iar restul operatiilor sunt paralelizabile 100%.
Iar daca asta e figura, nici nu conteaza de fapt prea tare care e rezolutia pozei. Tu calculezi matricea de transformare (3x3 in 2D, insa doar cu 3 necunoscute) plecand intotdeauna la acelasi numar de pixeli indiferent de rezolutia pozei, doar restul operatiilor (alea 100% paralelizabile) trebuie aplicate la intreaga matrice.


Treaba asta e valabila cand faci poza la un obiect la o oarecare distanta, facand presupunerea ca nu schimbi perspectiva odata cu miscarea camerei.

This post has been edited by James Kilowatt: Aug 27 2013, 09:07 AM

Nimeni nu a negat faptul ca primul produs comercial de succes cu touchscreen a fost iphone-ul, si ca prima tableta care a cunoscut succes comercial a fost ipad-ul. Dar succesul comercial nu este un argument tehnic. 100 de miliarde de muste mananca rahat, mancati rahat, 100 de miliarde de muste nu au cum sa se insele ! In plus, nu stiu cati dintre utilizatorii de 4s (parca pe asta au introdus hdr-ul) stiu ca au hdr, sau au luat in considerare acest fapt cand au cumparat telefonul. Pe principiul asta poti sa spui ca aplicatia de bursa care vine preinstalata pe iphone e un succes comercial imens, desi nu stiu cati oameni au folosit chestia aia (desi era prezenta de la primul iphone parca).



Urmatorul iphone vor fi doua adica Iphone 5s care va fi un iphone 5 upgradat (ah daaaa... si finger print scanner... woah, alta tehnologie de la inceputul anilor 2000, care va avea succes comercial odata cu iphone 5s-ul, care ar fi avut succes comercial si fara fingerprint scanner) si phone 5c care va fi un iphone 4s cu carcasa de plastic. Daca tot as vrea iphone eu as lua varianta asta pentru ca nu va fi la fel de fragil ca iphone 4s-ul.

P.S: Telefonul meu, Nexus4, a suferit saptamana trecuta un accident oribil... intr-un moment de neatentie (si pentru ca imi place sa traiesc viata la maxim si nu folosesc prezervativ, folie, sau alte mijloace de protejare a telefonului) am scapat telefonul pe niste scari de gresie, cu fata in jos, rezultatul a fost relativ minor estetic vorbind (o crapatura crapatura in coltul ecranului (acolo unde ecranul s-a intalnit cu coltul gresiei) insa a devenit inutilizabil (nu mai functioneaza touch-ul), drept urmare, pana imi sosesc piesele de schimb am fost fortat sa trec la Xperia L, telefon despre care vorbisem anterior si l-am laudat.

Eh... revin un pic asupra primelor impresii.
The bad:
1. Telefonul nu e "rau", in sensul ca isi face treaba, nu are lag cand navighez prin meniuri sau cand fac scrolling pe o pagina web... insa aplicatiile pornesc cu o ezitare minuscula dar totusi foarte clar observabila (mai mare decat la galaxy nexus si semnificativ mai mare decat la nexus4).
2. Daca in utilizarea zilnica normala (telefon, mail, facebook, browsing, jocuri simple) telefonul se misca bine, la primul semn de aplicatie cu consum intensiv de resurse (in afara de Diesel mai sunt si alti jucatori de Ingress pe forum ?) se simte clar submotorizat.
3. Ecranul de 4.3 e mic, cu tastatura lui e dureros sa tastezi, cu swiftkey cloud (care e cel mai bun lucru de la painea feliata incoace) e folosibil dar tot vreau sa trec inapoi la ecranul de 4.7 al nexusului.
The good:
1. Sony a invatat din greselile altora se pare, si nu s-a indepartat prea mult de androidul stock. Nu exista butoane (nici fizice nici capacitive) ci doar virtuale (ca la nexus), si sunt si in ordinea corecta si in numar corect (back, home, taskmanager) exact cum trebuie sa fie. Locurile unde difera de androdul stock sunt in majoritatea lor pozitive: ai procentul bateriei afisat in cifre (ca la CM), ai optiune de screenshot daca apesi pe butonul de power (ca la CM), nu m-a incantat launcherul si tastatura dar astea pot fi schimbate foarte usor (in prezent folosesc nova launcher si swiftkey)
2. Pentru un smartphone ieftin se misca foarte bine, nu suficient de bine ca sa merite luat in locul unui nexus4, dar suficient de bine cat sa nu iti para rau de banii dati pe el.

Halba, eu nu am laudat nici compania nici produsul odata cu observatia mea ci am prezentat o situatie: nimeni nu a bagat in seama HDR pana cand Apple a implementat tehnologia in telefoanele sale.
Inteleg ca ai o repulsie obsesiva fata de iP si, pentru ca nu ma afecteaza nici pozitiv nici negativ atitudinea aceasta a ta, prefer - de cele mai multe ori - sa o ignor; dar te rog sa nu-mi interpretezi cuvintele ca partizanat pentru vreuna dintre platformele mobile pentru care nu pot avea decat atata stima si atasament in valoare de cate beneficii imi ofera.
Restul observatiilor cred ca isi au locul pe topicul despre telefoane.

@JK: asa e ai 3 necunoscute dar sint absolut sigur ca exista procedee matematice si algoritmice standard si banale care sa faca asa ceva. Pe linga metoda de a identifica numai citiva pixeli mai imi vine una in cap: creezi o matrice/imagine mare dar simpla, adica cu multe zone constante sau si mai bine, 0. Genul asta de matrici se pot manevra foarte usor si se folosesc o multime in genul asta de probleme. Practic e cam acelasi lucru cu ideea cu citiva pixeli ca complexitate.
Cum se face o imagine/matrice simpla dintr-una complicata? pai cam cum e in programele alea care transforma o poza in "penitza", adica numai contururile schitate cu negru si restul cu alb ca un desen... contururile se gasesc cu o derivata rudimentara, adica diferenta intre elementul curent si cel dinaintea lui, si dupa aia ce e sub un prag se face negru si ce e peste se face alb. Astfel numai zonele de tranzitie, de "muchii" ramin ca o linie de "creion".

Toate operatiile astea sint foarte usor paralelizabile pentru ca nu au dependetze. Toate operatiile in elementul a(ij) din rezultatul HDR se pot calcula separat de cele din elemntul a(mn) si nu interactioneaza. Toate elementele din rezultat se pot calcula simultan, nici un element nu are nevoie de rezultatul de la alt element.

@KLM: HDR exista de cind exista fotografia digitala probabil, si e si folosit tot de atunci dar de obicei de oameni cu oarecare pasiuni fotografice. Sincer nu stiu de cind exista ca mod automat in aparate P&S. Nu stiu daca hdr e meritul lui SJ sau e doar ceva oferit de fabricantul de senzori pentru telefon pe care apple l-a bagat pentru imaginea premium.

SJ are meritul de a fi pus un procesor puternic, capabil de HDR. KLM asta e motivul, puterea de procesare, pe care SJ a mizat, lasand un pic in urma concurenta. Acum lucrurile stau invers. Apple e cam in gara.
Si ti-am mai spus de 4s ca e ragalie la conectivitate:ca sa poti vorbi trebuie tinut nu stiu cum, sa nu piarda semnalul, la wifi se deconecteaza subit si are nevoie de restart pentru a mai vedea vreo retea, etc. De design e ok.
Ozz - 1080p are ~2Mpx. (1920x1080).
Ozz&Jk -accelerarea video din SoC-urile telefoanelor e diferita fata de cea din PC-uri, in sensul ca operatiile respective sunt implementate la nivel hardware in GPU, si se apeleaza direct prin instructiuni, eliminand programarea software a algoritmilor respectivi. (cam cum a fost MMX-ul pe vremuri, in fapt un set de instructiuni in plus)

Exact aceasta abordare ne diferentiaza: eu explic de cateva mesaje ca mesajele mele si discutia nu au absolut nicio legatura cu Apple, cu produsele sale, cu faptul ca HDR sau alte tehnologii functioneaza bine sau prost pe iPhoane; la fel cum Android nu era bagat in seama pana cand nu s-a apucat sa copieze de la Apple - direct sau prin intermediul producatorilor de telefoane - forma dispozitivelor precum si parte din interfata, eu - pifanul - nu am bagat de seama ca exista HDR decat odata cu aparitia lui pe iP; restul tine de evolutie.

Nu stiu ce telefoane ati folosit voi pentru ca eu nu am auzit de asa ceva decat aici; niciunul dintre posesorii pe care ii cunosc nu s-a plans de asa ceva, am folosit si eu vreo 2 zile un 4S si nu am intalnit absolut nicio problema nici cu semnalul, nici cu wifi, nici cu viteza de internet (aia gatuita pe care mi-o da operatorul); astept 5S doar pentru 4G si in speranta ca va avea aceleasi margini precum 4S; altfel, pentru ceva care nu va aparea pe scara larga decat peste 1-2 ani (4G) iar beneficiile aduse sunt indoielnice (10-20-30 Mbps pe mobil sunt cam acelasi drac) ramane sa vad daca din alte motive va merita vreo 200 de euro in plus.

Revenind la HDR, e simplu sa scrii un algoritm barbar de functionare - doua variabile care merg una de la de la 1 la 3k si ceva, alta pana la ~2.5k (un total de ~8 mil) si o functie care compara 3 pixeli intre ei, returnandu-l pe cel mai bun - insa ar fi consumator de resurse (inseamna 8x3 mil operatii + inca 8x3 mil operatii de scriere plus stergere).

Revin putin la discutia de mai devreme, legata de viteza cu care un smartphone chinezesc face hdr-ul.

M-am jucat putin cu Photomatix, la sugestia maestrului Halba. Merje frumos, insa e departe de a face prelucrarea "in timp real" chiar si la rezolutii comparabile cu ale chinezariei (8mpixeli), si asta si pe un I5 3320M (2.6Ghz) cu video integrat HD4000, si pe un desktop cu Phenom II X4 3.6Hzh + Ati HD 6870, ambele cu SSD-uri decente.

Cumva fie chinezii astia sunt niste genii ale softului, fie dracovenia are implementata figura asta cu HDR in hardware, ceea ce e si mai laudabil, altfel nu vad cum ar putea sa o faca atat de rapid.

Sau poate photomatix e prost scris? Adevarul e ca in niciun moment al prelucrarii/alinierii/conversiei/whatever nu foloseste nici procesorul prea tare, nici ramii.



This post has been edited by James Kilowatt: Sep 2 2013, 09:07 PM

Din cauza formatelor folosite de fiecare in parte?
Camera din telefon probabil trage 3 cadre in format jpg cu care lucreaza pe cand Photomatix-ului i-ai dat (?) raw.
O alta explicatie ar fi algoritmul folosit; normal ca un soft pentru PC va incerca sa foloseasca toata puterea de care dispune pentru a face cat mai multe operatii (abordarea barbara de care vorbeam mai sus) pe cand un soft de pe telefon ar trebui sa lucreze cu zone care cuprind cateva mii de pixeli, reducand operatiile la cateva zeci, sute sau, cu toleranta maxima, mii.
De altfel, eu cred ca i-ar fi imposibil unui procesor de telefon - chiar celui mai puternic care exista: octa-core de pe S4 sau 800 de pe G2 - sa ruleze in mod similar acelasi proces precum un procesor de 4-5 ori mai puternic precum i5-ul tau (chiar daca Halba, data fiind conduita lui in acest domeniu, va trebui sa spuna ca opt nuclee dau o putere mai mare decat un rahat cu doar doua).

Multe din functiile necesare calcularii HDR, codare-decodare, prelucrare foto-video sunt implementate hardware in SoC (in CPU sau in GPU) astfel incat viteza cu care un SoC (octa-core Exynos sau Snapdragon 800, sau ce vreti voi) - in mod normal sub un i5 sau i7 de generatie noua ca si MIPS - pe unele segmente (codare video, prelucrare etc) sunt la acelasi nivel (poate chiar peste - depinde de model). Daca un Krait dual-core codeaza-decodeaza lejer full HD in timp real, nu acelasi lucru se poate spune despre Core2Duo care "sughite", desi ca MIPS e net superior.
E aceeasi situatie ca atunci cand scrii o functie care calculeaza o impartire (de exemplu), chiar si in cod masina - rezultatul ca viteza va fi net inferior fata de folosirea instructiunii dedicate de impartire implementata direct in procesor.
Si, ca sa nu ne mai miram de chinezarii, care s-au ridicat puternic si (eu cred ca in viitorul nu prea indepartat) calitativ vor fi peste produsele firmelor cu traditie (dar care nu au productie in curtea proprie - productie externalizata), cititi aici.
Asiaticii (in special chinezii) au investit mult in tehnologie, si foarte mult in educatie. Ba chiar importa "creiere" (recent VP-ul de la Android s-a dus la Oppo parca).

This post has been edited by Mircea104901: Sep 3 2013, 01:23 PM

Banuiesc ca functiile de care vorbesti sunt implementate hard si in placa grafica din PC-uri. Poate insa photomatix nu stie sa le foloseasca, si se bazeaza exclusiv pe soft si pe CPU.... altfel nu vad cum poate sa fie atat de lent in comparatie cu o prastie de smartphone care nu e nici pe departe the cutting edge of pocket computing .
Desi cum spuneam photomatix nici macar CPU-ul nu il incarca la 100%, si ramii zac nefolositi.

@Klm
Am incercat si cu raw si cu jpg la aceeasi rezolutie, insa nu e sesizabila diferenta de viteza, tot atat de lent se misca pe PC. Adica nu e lent la modul absolut, nu trebuie sa stau ore in sir ca sa faca o prelucrare, insa nu e instantanee ca pe smartphone, dureaza secunde bune.

Revenind la HRD-ul pursange, eu am un Nikon D5000 care stie sa traga 3 cadre in rafala unul dupa altul cu expuneri diferite. Insa NU stie figura de care spunea halbasus, sa traga 3 cadre intr-o singura deschidere a diafragmei.

Am incercat si cu un Iphone (4 cred) al unui coleg si functioneaza la fel ca chinezaria. Adica tot trage mai multe cadre (cel putin 2) pe care le recombina ulterior, si la iphone apar fantomele alea cand imaginea e in miscare.

This post has been edited by James Kilowatt: Sep 3 2013, 01:41 PM

Setul de instructiuni este propriu fiecarui procesor. Instructiunile x86 difera fata de ARM. Ca sa nu zic de algoritmii din GPU-uri care sunt proprii (ex CUDA proprietate nVidia), dar a aparut alternativa OpenCL (care nu inseamna instructiuni proprii procesorului, ci un standard prin care se poate programa GPU-ul) care e implementat inclusiv in CPU-urile Intel de generatie noua. Deci, daca scrii un program in OpenCL va functiona si pe nVidia si pe AMD si pe Intel (cele care stiu), pe cand CUDA doar pe nVidia.
Mai mult ca sigur algoritmii din Mediatek-ul tau implementati hardware nu exista in setul de instructiuni x86. Si o emulare a lor nu va fi la fel de eficienta, mai mult ca sigur, decat cu resurse muult mai mari.

Iti mai dau un exemplu: in setul de instructiuni din Core2Duo nu exista instructiuni specifice de codare-decodare AES. i-urile au implementata aceasta functie (AES accelerat). In utilizare, i-urile spulbera Core2Duo la AES.

Acuma, diferentele de performanta intre programe depind de cat de apropiate sunt de codul masina. Cele mai indepartate si cele mai proaste ca performante sunt programele interpretate (gen VB din Excel). Cele compilate depind de compiler, dar oricum ai da-o nu vor functiona ca un program scris direct in cod-masina. Dar dezvoltarea de aplicatii multimedia in cod-masina ... e ca si cum ai incerca sa muti un munte cu lopata. Se poate, dar dureaza.
In general, aplicatiile noi sunt scrise in medii de programare, in care nu mai controlezi manual hardware-ul (gen alocare memorie, eliberare memorie, etc). Mediile astea sunt vizuale, in marea lor majoritate, pentru a usura munca programatorilor. Deci intre codul sursa si rezultatul compilarii mai exista o interfata generata de masina, tocmai pentru a putea gestiona resursele in mod automat (cum e la .NET CLR-ul). Ce mai conteaza ca aplicatia nu va rula optim, atata timp cat exista resurse hardware (putere procesor in crestere an de an, memorie la fel), iar executia ei satisface clientii?

Stai putin... ca ma pierzi
Photomatixul nu incearca sa emuleze aplicatia foto care face HDR de pe chinezaria mea mtk.

Tu vrei sa spui ca smartphoanele au implementate hard o serie de smecherii pentru prelucrare foto (inclusiv HDR) care nu au niciun echivalent (echivalent, nu aceeasi instructiune, normal) pe x86/openCL/etc? La urma urmei nu ar fi absurd avand in vedere ca smartphoanele au toate camera foto, in timp ce PC-urile n-au. De exemplu pentru redarea video hd banuiesc ca si GPU-urile o fac tot hard, chiar daca instructiunile sunt altele decat cele pt smartphone.

Oricum, chiar daca pe PC e nevoie de 1000 instructiuni (iteratii) ca sa faca o chestie implementata hard dintr-o singura instructiune pe smartphone, cum spuneam pe PC resursele existente tot sunt nefolosite... de asta suspectez o aplicatie scrisa prost.

Apropo, am vazut foarte multe cazuri de aplicatii scrise prost de programator, nu de compilator. Adica din motive de comoditate, scrie cu fundul fara sa isi bata capul sa o faca scalabila, optimizata, etc. De exemplu baga cu nesimtire doua bucle una in alta ambele depinzand de dimensiunea problemei (-> timp CPU ~ patratul dimensiunii), alocari de memorie depinzand de patratul dimensiuni (matrici in general), etc. De multe ori nu e necesar, insa e mai usor de scris.
Genul asta de aplicatii prost scrise incarca totusi resursele, ceea ce Photomatix n-o face.

This post has been edited by James Kilowatt: Sep 3 2013, 04:22 PM

Da. Sunt sigur ca pe partea de multimedia/grafica au multe functii implementate hardware. Pe langa GPU-uri puternice. Altfel ar fi foarte solicitante pentru procesoare, care cred ca ar trebui sa fie mult mai performante sa se miste cum se misca smartfoanele in prezent. Mai ales la rezolutii fullHD. Eu nici pe monitorul pe care lucrez curent nu am rezolutia de pe telefon, deci necesarul puterii de calcul e mai mic pentru a afisa aceeasi informatie.
E impresionant unde a ajuns tehnologia in zilele noastre. Cine stie ce ne asteapta in viitor

Poate niste baterii care sa tina stiu eu... aproape trei zile . Eventual niste mici fuel cells, sau generatoare cu radioizotopi, sau stiu eu, cu pedale, daca solutiile astea chimice bazate pe baterii nu mai fac fata

Iar ecranele de 5.5" vor deveni standard, insa nu ca sa nimerim mai usor tastatura sau sa citim scorul cand jucam freecell, ci sa sa aibe pe unde sa disipe caldura. Ecranele vor fi in acelasi timp si radiatoare si panouri solare.

This post has been edited by James Kilowatt: Sep 3 2013, 04:49 PM

Mediatek nu mai este firma de mina a doua.. adica fost dar se ridica. Am o multime de cunoscuti care au plecat la MDK de la firme de prima mina. Chiar MDK se lauda ca acum face cel mai tare procesor din parcare, 4 nuclee arm care pot functiona la viteze diferite.
Apopo de quadcoreurile astea. Nu prea exista soft care sa poata folosi un quad eficient... mai mult, nu s-a descoperit inca metoda de scris cod eficient si mai ales de compilat pentru sisteme multi procesor.
Pisica asta cu 8 inimi a lui Smasung e vrajeala de marketing. La viteza e sub cel putin un Quad (parca Krait). De fapt numele e rejectat de injineri, pentru ca nu e octacore adevarat, asta pe linga ca toata lumea zice ca e o prostie. E doua quadcoruri care nu functioneaza NICIODATA simultan. E bazat pe un design a lui ARM numit bigLITTLE, facea si NVidia ceva asemanator, in care se pune impreuna un procesor slab cu unul puternic, ala slab e optimizat pentru putere mica si functioneaza cind n-ai nevoie de putere, si trece pe ala puternic cind e nevoie. Ca un NOS. Din nefericre nu trece decit toate nuccleele simultan.
Apple nu e prost. Nu exista nici un motiv in afara de marketing sa treci de doua inimi la ora actuala.

@Mircea: SOCul de telefon are integrat nuclee de GPU (de obicei de la PowerVR), pe cind la PC de obicei e separat pe placa grafica, sau mai nou la laptop/utrabook e integrat cu procesorul ca in intel 2500/4000. Este insa posibil sa aiba optimizate alte functii, habar n-am.

@JK: ce dovada ai ca-ti face HDR-ul in full? Poate ia 2 secunde dar iti trinteste o varianta preliminara la rezoltie suficienta ca sa para ok.

Ei bine va povesteam ca am avut acum multi ani (sa fie 7 ani) Samsung cu touchscreen. Am urat telefonul ala. Cu sinceritate l-am urat. Si aveam un resentiment pentru orice viitoare scula cu ecran tactil. Ce s-a intamplat de fapt e faptul ca Apple a dus mai departe spre ideal (ca sa nu spun perfectiune) ceva ce mergea prost la altii. In momentul in care esti cel mai bun din domeniu atunci vinzi. Asta e de fapt, daca stai sa te gandesti, meritul Apple. Ceea ce altii fac prost, stangaci, nefinisat, neglijent, samd ei fac foarte bine. Pentru ca ecranul lor mergea brici.
Sau faceau.

This post has been edited by solmar: Sep 4 2013, 09:01 AM

Nu te contrazic, Mircea; sigur ca un procesor dedicat unei sarcini o va face mult mai bine decat un procesor care, printre multe alte functii, e pus sa faca si sarcina in cauza (la fel cum un telefon e mult mai bun decat un paletaphone la sarcini ce tin strict de comunicare); pe de alta parte eu nu sunt convins ca procesoarele mobile au implementate instructiuni hardware dedicate lucrului cu HDR... sunt convins, de altfel, ca singurul aspect care difera este algoritmul folosit (adica pe pc se prelucreaza toti pixeli - sau majoritatea lor - in timp ce telefonul lucreaza cu zone de intensitate a luminii); poate ca si softul de pe laptop are o setare care ii permite sa lucreze in acelasi mod (prelucrare HDR gasesti in Photoshop care are un nivel mai ridicat - daca nu cel mai ridicat - al nivelului de configurare deci poti compara).
Eu asa as gandi un soft pt telefon: impart imaginea intr-o suta (cred ca e suficient), o mie de zone (pentru o calitate mai buna) care trec printr-o functie de evaluare care returneaza o valoare; valoarea respectiva se compara cu valoarea rezultata din compararea cu zonele celorlate doua imagini si se pastreaza cea mai buna dintre ele; in felul acesta obtin calitate satisfacatoare, folosind maxim 3k de operatii (eventual faci in prima faza doar 300 iar restul in backgroundcat timp utilizatorul "admira" poza).
Pentru o statie grafica as gandi o posibilitate sa modific fiecare pixel in parte (ba chiar sa pot modifica inclusiv sub-pixelii) pentru ca am in spate puterea necesara sa o fac; deci alea 24 mil de operatii.
Partea tehnica - adica aia ce tine de implementare (limbaj masina, instructiuni nu stiu de care, mips etc) - ma depaseste.

JK, ti-ai dat singur raspunsul: softul nu este optimizat sa foloseasca puterea care ii este pusa la dispozitie; imi amintesc de perioada in care aparusera primele quad-uri, perioada in care un E8400 spulbera un Q6700 in absolut orice test... mai putin in lucrul cu programele scrise de Adobe - optimizate pentru quaduri (eu as spune ca e inca un exemplu care intareste punctul de vedere exprimat pe topicul despre telefoane cum ca Android este un sistem scris prost daca pe un quad cu frecventa apropiata de 2 GHz se misca mai prost decat un iOS pe un dual apropiat de 1 GHz).

Nu se pot compara procesoarele dupa numarul de inimi si frecvente. E ca si cum ai compara masinile dupa turatie, un motor de 6L are mai mult cuplu la 1500RPM decit unul de 2L la 3000rpm.
D-aia trebuie teste adevarate, si facute cit mai realsit.. apropo de teste, nu-s usor de facut, compilatorul are tendinta de a arunca codul redundant de genul buclelor care nu fac nimic si al caror rezultat nu e folosit mai departe etc.. dat fiind ca un test nu face nimic util, ideal un compilator bun ar trebui sa arunce tot programul la gunoi .

Nu cred ca un compilator poate detecta un algoritm prost, adica daca berbecul de programator a alocat o matrice NxN doar ca sa stocheze 3 elemente non-nule pe ficare linie de exemplu. In realitate el are nevoie sa zicem de 3N cuvinte si foloseste N^2. Cand N=2000 nu e grav, insa cand N=2 000 000 e cu totul altceva, n-o sa ai pe ce sa rulezi multi ani de acum inaine. Asta e valabil si pentru bucle, ar putea sa nu fie goale doar ca fac operatii inutile dpdv al rezultatului.
Baiatu' din comoditate scrie doar 3 linii ca sa lucreze cu matricea aia inutil de mare, in timp ce pentru a lucra cu ce spun eu intr-un spatiu mai mic are nevoie de mult mai multe linii si operatii intermediare (sa zicem, 100) (daca cele 3 elemente non-nule sunt asezate oarecum "aleator"). Si ca sa fie si mai rau, daca faci un test pe 200 elemente s-ar putea ca rezutlatul sa fie chiar mai prost pe programul "optim", algoritmul prost face 200x200=40 000 operatii in timp ce ala bun face 3 x 100 x 200 = 60 000 operatii. Da' ia incearca pe 2000 de exemplu.... sau pe 2 000 000

Si pe partea de paralelizare poti sa dai gherle daca nu esti atent la ce faci. De exemplu, degeaba paralelizezi un proces, daca procesele paralele trebuie sa comunice intre ele sau cu altcineva, iar comunicarea ia mai mult timp fizic decat calculul in sine. Si din nou treaba nu e intotdeauna foarte evidente si foarte scalabila.. daca procesele au nevoie de 10ms de comunicare intre ele, iar timpul de "calcul" total efectiv e de 1s, merita sa imparti pe 2 procesoare paralele. Insa nu mai merita sa il imparti pe 10 (presupunand ca fiecare are nevoie de 10ms de comunicare prin acelasi "canal")


@KLM
Daca ai diferente de "expunere" in zone vecine, rezultatul e uratel. 1000 zone inseamna o grila de ~35x35, daca 10% dintre vecini au alta expunere iese naspa. Tre' sa mai faci o trecere sa "netezesti" rezultatul...
Si tot ai nevoie ca functia de evaluare sa fie implementata hardware, altfel daca asta presupune cateva mii de operatii si citiri de memorie tot e porno si imposibil de facut "in timp real" chiar daca fiecare zona in sine ruleaza paralel in vre-un shadder al GPU-ului de ex...
Plus ca nu scapi de ce am discutat mai devreme, realiniere si d-astea.

This post has been edited by James Kilowatt: Sep 4 2013, 10:14 AM

Apropo, partea asta cu HRD-ul miroase a problema de optimizare, daca tii neaparat sa o interpretezi asa. Ceea ce ar face-o foarte simpla pentru un rezolvare (fie si aproximativa) cuantica, pe qbiti.

Mircea, cand vedem qbitii in smartphoane? Oricum, din ziua aia s-a cam zis cu protocoalele actuale de securitate si criptare a datelor care ar fi sparte al naibii de repede...