lab501: Buna Tamas, hai sa incepem cu cateva detalii despre tine. Cum te-ai apucat de programare? Cum este sa lucrezi in aceeasi bransa dupa atatia ani?

Tamas Miklos: Nu pot sa spun ca am fost interesat de calculatoare pana in jurul varstei de 10 ani. In gimnaziu, am inceput sa avem cursuri de informatica. Prima intalnire am avut-o cu Commodore 16 si Commodore +4, si am fost pur si simplu dat pe spate atunci cand am descoperit BASIC. Pur si simplu nu ma puteam opri din realizarea de mici pograme care ajutau utilizatorul sa deseneze sau sa realizeze grafice. Am invatat repede sa programez in BASIC, asa ca am trecut la assembler pentru a putea intelege mai bine cum functioneaza calculatoarele Commodore. Cred ca acesta a fost momentul cand s-a nascut ideea unui software de diagnoza, insa au trecut inca 6 ani pana cand m-am apucat de primul program de acest gen, numit ASMDemo. A trecut mult timp de atunci, si uneori imi vine si mie greu sa realizez ca inca am aceleasi preocupari dupa 15 ani, si inca imi face o mare placere sa dezvolt software de diagnoza.

lab501: De la ASMDemo in 1995 si pana la AIDA64 in 2010, ai avut parte de 15 ani plin de munca si software interesant. Care este principala diferenta atunci cand vine vorba de benchmark-uri intre piata de acum si anii de inceput ai domeniului?

Tamas Miklos: Era atat de simplu pe vremuri… Principala diferenta este data de sistemul de operare: acum 15 ani Windows nu era atat de popular, sau cel putin majoritatea utilizatorilor foloseau DOS, deoarece majoritatea jocurilor si aplicatiilor erau 100% compatibile cu DOS. Fara Windows si fara multitasking, puteam masura performanta sistemelor foarte usor, deoarece programul avea control total asupra resurselor sistemului. In zilele noastre multi-tasking-ul este ceva banal, si masurarea cu acuratete a performantelor sistemului reprezinta o provocare dificila, mai ales in cazul procesoarelor moderne, cu mai multe nuclee. In 1995 fiecare utilizator casnic avea un procesor, iar acesta la randul sau avea un singur nucleu, fara HyperThreading. Dezvoltarea unui benchmark care utilizeaza un singur procesor si un singur nucleu era foarte simpla. Dezvoltarea unui benchmark care sa poata utiliza 4, sau 8 nuclee este mult mai dificila, mai ales daca vrei sa utilizezi la maxim toate nucleele in orice sistem, inclusiv in servere, si sa le incarci la 100%. Din fericire, modul in care sunt organizate nucleele intr-un procesor nu se va schimba in viitorul apropiat, asa ca avand deja un software capabil de benchmark-uri multi-threaded (AIDA64), nu ne ramane decat sa ne asiguram ca acesta va scala cu din ce in ce mai multe nuclee, in conditiile in care atat Intel cat si AMD vor lansa in curand din ce in ce mai multe procesoare care se vor baza masiv pe procesare multi-core.

lab501: Colaborezi cu Lavalys din 2003. Ce te-a determinat sa alegi o cale separata dupa 7 ani de colaborare?

Tamas Miklos: A fost o placere sa lucrez cu Lavalys in toti acesti ani. Am trecut prin multe, si cel mai important – am invatat sa dezvolt software care nu este gratuit, ci comercial. Este mult mai usor sa dezvolti freeware: poti spune ca un anumit bug sau o anumita incompatibilitate nu pot fi rezolvate, iar utilizatorii vor intelege. Pe de alta parte, cand utilizatorii sunt clienti platitori, o asemenea comunicare poate declansa reactii diferite, si uneorii o asemenea reactie va supara pur si simplu clientul. A fost foarte util faptul ca am invatat cum sa ma descurc cu asemenea dificultati, si in acelasi timp mi-a facut placere. Cu toate acestea, incepand cu 2007, bucuria de a lucra impreuna cu Lavalys a disparut treptat, si m-am trezit angrenat intr-un efort continuu de schimbare si imbunatatire a organizarii interne a companiei. Atat jumatatea canadiana a companiei, cat si jumatatea maghiara (eu si colegii mei din Budapesta) aveam idei foarte diferite legate de viitorul Lavalys si viitorul produselor software pe care le dezvoltam impreuna. In Septembrie 2010, datorita neintelegerilor intre cele doua parti, compania s-a impartit in doua. Colectivul maghiar a pus bazele unei noi companii, pentru a continua dezvoltarea unui software de diagnoza si benchmarking, pe care l-am numit AIDA64.

lab501: Care a fost motivul principal care a dus la rebranding-ul complet al produsului? Are acest lucru legatura cu drepturile asupra numelui Everest, sau pur si simplu v-ati dorit un inceput proaspat?

Tamas Miklos: Chiar si in perioada Lavalys utilizatorii isi aminteau de AIDA16 si AIDA32, si chiar si in zilele noastre ei fac legatura intre aceste nume si “acele programe foarte utile din trecut”. Intotdeuna am considerat AIDA16 si AIDA32 ca fiind proiectele mele personale, in timp ce Everest a fost un proiect realizat in colaborare cu Lavalys. Mi s-a parut logic sa ne intoarcem la brand-ul AIDA, acum cand a devenit din nou un proiect personal – chiar daca acum exista o echipa intreaga de dezvoltare si suport tehnic, condusa de mine. Nu vreau sa mai folosesc niciodata numele Everest

lab501: Da-ne cateva detalii despre FinalWire. Primul program, cu diferitele lui versiuni, este AIDA 64. Aveti in plan sa dezvoltati in viitor si alte produse software FinalWire?

Tamas Miklos: Chiar daca FinalWire este o companie noua, este alcatuita dintr-un grup de programatori maghiari foarte priceputi, fiecare fiind un expert in domeniul in care activeaza. Lucram impreuna de peste 10 ani, si am placerea sa ii consider cei mai buni prieteni ai mei. Am vrut sa incepem cu AIDA64, si avem sperante ca acest program va fi un succes comercial, si vom avea in curand o baza foarte solida de clienti. In momentul in care ne vom simti confortabil in postura de publisheri, vom angaja mai multi dezvoltatori, si vom incepe sa lucram si la alte proiecte. Un posibil proiect pe care il luam in calcul este o solutie de management complet automatizat al retelelor, adica un software care va putea sa urmareasca schimbarile software si hardware din reteaua unei companii, si va oferi functii unice, care in acest moment nu sunt incluse in nici un produs de acest gen. Toate acestea folosind aceasi interfata intuitiva, curata si usor de folosit de care dispune AIDA64.

lab501: Similar predecesorului sau, AIDA64 este un software foarte complex de analiza si testare. Care sunt principalele noutati fata de ultima versiune de Everest?

Tamas Miklos: Cea mai importanta schimbare este implementarea testelor pe 64 de biti. Odata cu lansarea lui Windows 7, un numar destul de mare de utilizatori au decis ca a venit momentul sa migreze catre un sistem de operare pe 64 de biti, asa ca am considerat ca acesta este momentul ideal pentru a relansa benchmark-ul nostru, de data aceasta in versiunea x64. Datorita acestui lucru, clientii nostrii pot compara performanta sistemelor proprii folosind cele mai avansate benchmark-uri pentru memorie si procesor. Desigur, am pastrat si benchmark-urile pe 32 de biti, deci si utilizatorii care folosesc un sistem de operare pe 32 de biti pot folosi fara probleme AIDA64.

De asemenea, am introdus suportul pentru SSD-uri, AIDA64 dispunand de functii unice, cum ar fi indentificarea controller-ului, a marimii memoriei cache si a parametrilor S.M.A.R.T. specifici fiecarui controller in parte.

lab501: Care sunt principalele motive pentru care nu putem compara rezultatele obtinute cu versiuni diferite ale acestui tip de benchmark? Se datoreaza acest lucru faptului ca atunci cand adaugati suport pentru procesoare sau chipset-uri noi performanta se schimba?

Tamas Miklos: Principalul motiv este faptul ca AIDA64, spre deosebire de majoritatea benchmark-urilor, nu foloseste acelasi tip de benchmark pentru toate procesoarele. Noi dezvoltam o serie intreaga de metode de test, foarte diferite intre ele. Unele dintre metodele noastre includ optimizari ca SSE, MMX, si in curand AVX, in timp ce altele nu sunt optimizate pentru aceste functii, pentru a putea fi folosite impreuna cu procesoare mai vechi, care nu suporta SSE sau MMX. Fiecare metoda este testata pe fiecare varianta de procesor disponibila, si in final alocam fiecarui tip de procesor metoda care obtine cele mai bune rezultate. De exemplu, pentru un procesor Intel Core 2 vom utiliza un benchmark optimizat pentru SSE3, in timp ce pentru echivalentul de la AMD vom folosi varianta optimizata pentru SSE2. In conditiile in care adaugam constant noi metode optimizate de calcul, performanta unui anumit tip de procesor se poate schimba (imbunatati) in momentul in care treceti de la o versiune de AIDA64 mai veche la o versiune mai noua.

Un alt factor decisiv este dat de faptul ca arhitectura procesoarelor se imbunatateste continuu. Momentan avem benchmark-uri care sunt optimizate pentru 3DNow!, MMX, SSE, SSE2, SSE3, SSSE3 si SSE4 si care suporta chiar si procesoare care nu au aparut inca, cum ar fi Intel Sandy Bridge. Sandy Bridge va introduce functiile AVX, si chiar si cu metodele pe care le avem puse la punct acum va obtine scoruri foarte bune in teste. Pe de alta parte, in momentul in care o sa punem la punct o metoda optimizata pentru AVX, rezultatul obtinut de Sandy Bridge in FPU Julia se va imbunatati considerabil, deoarece timpul necesa calcularii fractalului Julia va fi mult mai mic folosind instructiunile AVX, decat daca am folosi doar instructiunile MMX sau SSE. Nu ar fi corect sa comparam cele doua scoruri, deci prin urmare, este foarte important sa comparam numai scoruri obtinute cu aceeasi versiune de AIDA64.

lab501: Cat de des veti lansa update-uri pentru AIDA64?

Tamas Miklos: Din punctul meu de vedere, atunci cand lucram impreuna cu Lavalys nu lansam suficiente update-uri pentru Everest, deobicei numai 2 sau 3 pe an. Pentru AIDA64 avem in plan un ritm mai accelerat de dezvoltare, care sa ne permita sa lansam cel putin 5 sau 6 versiuni stabile pe an. De asemenea, vom lansa saptamanal update-uri beta, deci utilizatorii care vor prefera sa fie tot timpul in prima linie vor putea sa iti metina versiunea de AIDA64 la zi.

lab501: Aveti in plan introducerea unui modul pentru benchmark-uri 3D, pentru analiza performantiei placilor grafice? Dar un stress tester pentru placile grafice?

Tamas Miklos: Nu avem nici un plan pentru a lansa un produs care sa concureze ceea ce fac deja cei de la Futuremark. In schimb, vrem sa introducem un benchmark OpenCL bazat pe tehnologia GPGPU, precum si un stress-tester OpenCL bazat pe tehnologia GPGPU. In acest fel, putem utiliza toate placile grafice disponibile si le putem incarca 100%, pentru a ne asigura ca sistemul este cu adevarat stabil. Planuim sa introducem acest modul in momentul in care AMD vor introduce oficial suportul pentru OpenCL in viitoarele versiuni de Catalyst.

lab501: Multumim pentru timpul acordat!

Tamas Miklos: Si noi va multumim!