Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Plivanje u OpenCL/u

Molim vas da mi oprostite na nejasnoj poruci, jer još uvek nemam ništa konkretno što bih želeo da podelim. Međutim, ono što bih želeo da uradim ovde jeste da vam skrenem pažnju na moj novi omiljeni deo Mac OS X 10.6 Snow Leopard - OpenCL.

Radim na nekoj neverovatnoj tehnologiji za Capo u poslednje vreme, ali su to poprilično teške stvari. Ja radim obradu audio podataka da bih proizveo fensi vizuelizaciju pripadajućeg spektralnog sadržaja (ne koristeći FFT). Nažalost, vođenje ove operacije je prilično sporo, pa sam pokušavao da je paralelizujem i optimizujem najbolje što mogu.

U praksi, ja nemam nameru da vodim procesiranje na celim audio fajlovima, ali to koristim kao najgori mogući slučaj da bi testirao protok nekoliko pristupa na kojima sam radio. Ulazni fajl za testove ispod je 45-sekundi wave fajl, a alat koji sam izgradio proizvodi detaljne slike fajla koje sadrže ‘vreme-nasuprot-frekvencija’ pregled celog fajla.

Svi rezultati prikupljeni su na mom 8-core (jezgra) MacPro. Shvatam da ovo nije reprezentativna korisnička mašina, ali mi omogućava da verifikujem da li se svi resursi računarskih sistema koriste, jer nije trivijalno da se spaja 8 jezgri. I, videći kako je to nešto čemu kompjuteri streme u bliskoj budućnosti, ovo izgleda kao pametna stvar da bi se na nju fokusiralo...

Inicijalni pristup

Implementirao sam pomenuti algoritam koristeći MATLAB izvorni fajl za referencu. Koristio sam svoje optimizovane matematičke rutine (koje su ubrzane korištenjem vecLib / vDSP stvari), ali je ipak potrajalo - 492 sekundi da obradimo fajl!

U potpunosti sam očekivao da ovo bude sporo, tako da nisam bio iznenađen rezultatom. Ovo je radilo na samo jednom jezgru, i koristilo je skromnu količinu memorije. Barem sam imao uspostavljene osnove i izlazne podatke da bih unakrsno proverio optimizovane rutine.

(Napomena: ovaj je test rađen na nižoj rezoluciji od onih ispod, pošto je bio nepodnošljivo spor, kao što stoji. Mislim da bi pravi tajming za ovaj algoritam, sa istim parametrima analize za fajlove, bio u redu hiljada sekundi. Pokretanje testa sa istom rezolucijom koja se koristi u ostalim testovima, pomoću unosa fajla dugog 0.91 sekundi, rezultiralo je sa 10 minuta rada - brutalno!)

NSOperationQueue (operativni red)

Znam ovaj put veoma dobro. NSOperationQueue se primenjuje da ubrza kalkulacije vodopada u FuzzMeasure, i to je vrlo laka API za rad. Posle nekog intenzivnog rada po pitanju optimizacije koji je trajao više od dana, uspeo sam u tome da se proces odvija u 115 sekundi.

Ovo je ogroman napredak, čak sam uspeo da integrišem ovaj algoritam u Capo sa preliminarnom UI omotanim oko njega. Nažalost, morao sam da stvarno smanjim rezoluciju da bih dobio razuman broj performansi.

Tu je još jedan interesantan sporedni efekat, a to je da će Capo audio mašina zaglibiti dok se fajl obrađuje u pozadini. Kao što vidite, NSOperationQueue izgleda da radi po normalnom prioritetu, tako da može da spreči bilo šta drugo što se dešava u vašoj aplikaciji. Možete da ublažite problem smanjivanja broja istovremenih uzastopnih operacija u redu, ali nemate mnogo prostora da se smanji to opterećenje na 2-CPU mašini.

Takođe, obzirom na način na koji je moja matematička biblioteka struktuisana, odlučio sam da menjam memoriju za vreme izračunavanja, pa sam morao da uradim gomilu posla da bih izbalansirao opterećenje memorije (npr. koliko audio fajla biva ubačeno odjednom pre mrešćenja mnogo kopija svojih podataka kako bi se mogli pročitati paralelno po svim ovim nizovima) tokom izvršavanja. Do kraja, moj kod uopšte nije bio lep.

Konačno, obzirom na način na koji je sav ovaj kod napisan, nije bilo lako da se na zahtev ažuriraju parametri koji se koriste za generisanje spektralnih slika. Tako da ne bi mogao da ima korisnički definisan parametar frekvencijskog opsega koji se manipuliše u realnom vremenu, jer bi ažuriranje parametara dovelo do toga da se stvari ponovo obračunavaju. To su pitanja dizajna mog dela (to je kompromis za ukupnu brzinu algoritma), ali sam svesno doneo ove odluke.

OpenCL Pokušaj 1-Skalarni Kod

OpenCL uzbuđuje mnogo ljudi, i izgleda da oni načisto polude radi činjenice što možete da zakažete da vaš posao uradi GPU. Međutim, to je takođe neverovatno ekspresivan način da se napiše paralelizovani kod za multi-core procesore.

Nisam probao OpenCL put dok nisam postao dovoljno frustriran primenom mog NSOperationQueue. Ja sam ga optimizovao onoliko koliko sam mogao (bez ozbiljnog pomućivanja gomile koda, i čineći celokupnu primena vrlo krhkom), a ja zaista nisam želeo da počnem da razmišljam o pravljenju budućih izdanja Capo 10.6 - ne tako brzo.

Imavši to na umu, zaista sam želeo da znam za sigurno da će to ponuditi neku vrstu koristi zbog onoga što sam radio do sada. Dođavola, možda sam mogao koristiti GPU za svoje licitiranje...

Pa, smućkao sam Cocoa omot za OpenCL (za koji se nadam da ću da ga podelim kada dodam još neke funkcije na njega), i napisao sam svoj prvi kernel (jezgro) za OpenCL za nekoliko sati (sa priručnom OpenCL specifikacijom). Onda kada sam čitavu svoju glavu uključio u celi proces, odmaknuo sam se i shvatio da je moj kod bio mnogo čistiji i čitljiviji, nego pre toga.

Ipak, ovo je bila veoma naivna implementacija, tako da nisam očekivao neku magiju iz toga. Posle popravke grešaka, izmerio sam 30,87 sekundi! Za Boga miloga - to je ogroman dobitak!

U ovom trenutku, mogao sam se zaustaviti. U suštini sam skinuo >60% vremena od moje NSOperationQueue implementacije, ali sam hteo da ga guram još malo dalje, jer još uvek nije radio baš najsjajnije na mojoj dual-core 13 "MacBook Pro mašini.

Još uvek nisam integrisao ovo u Capo, pošto sam tek završio pisanje testnog koda (nije teško da se pomeri), ali ono što jesam primetio je to da OpenCL zakazuje ove radne jedinice pomoću Grand Central dispečerskog reda niskog prioriteta. To znači da ću se moći vrlo lepo igrati sa ostatkom sistema dok se ove monstruozne operacije odvijaju - još jedna pobeda za OpenCL!

OpenCL Pokušaj 2-Vektorizovani Kod

Intel procesori su danas sa pristojnim vektorskim jedinicama, i OpenCL vam dozvoljava da vrlo lako napišete vektorizovani kod. Možete preseći petlju operacije na četvrtine, i možete da radite na 4 elementa odjednom, jednostavnim prebacivanjem na float4 tip podataka, i igranjem sa indeksima u vašim nizovima podataka.

Ovo je bilo nezgodno da se učini funkcionalnim - možda 3 do 4 sata poigravanje i otklanjanja grešaka u kodu pre nego što sam shvatio da sam imao matematičku grešku (kombinovao sam rezultat nelinearnog operatera - ups!) što doprinosi izobličenom izlaznom podatku. Nakon što sam popravio greške, dobio sam rezultat od 14,1sekundi.

Apsolutno neverovatno - ja sam u suštini udvostručio svoju dužinu trajanja radeći sa vektorima.

OpenCL Ne-Pokušaj-Rad na GPU

Nisam planirao da isporučujem kod koji radi na GPU za ovaj posebni algoritam. GPU je stvar za izbegavanje prilikom rada, a ja sam se bavio algoritmom koji radi mnogo duže nego što želite da ga vežete za GPU. Na primer, ja sam zapravo uspeo da u potpunosti zatvorim moj sistem za čitav minut dok algoritam radi.

Oh, to je tačno, traje ceo minut da se izvrši na GeForce 8800GT. Tip algoritma sa kojim radim je daleko bolji za memorijski raspored računara opšte namene, njihove strategije keširanja, itd.

Osim toga, ovde postoji problem opštih troškova.

OpenCL Opšti troškovi

Kada radite sa CPU, izbegavate sve te troškove pomeranja podataka do / od GPU. Uz neke navedene dodatne zastave, možete da kažete OpenCL-u da snabdevate sopstveni host pokazivač memorije, i da želite da izbegnete korak kopiranja.

Po mom iskustvu testiranja, gotovo da vam uopšte ne treba vremena da pokrenete neki OpenCL kontekst, kompajlirate OpenCL program i podesite memoriju / parametre kada koristite procesor. Na GPU, gubio sam negde između 1-3 sekunde na zaobilaznicu.

Zaključak

Sve u svemu, ja sam veoma impresioniran onim što OpenCL donosi na sto. To stvarno nije toliko teška API za korišćenje (pogotovo sada kada imam Cocoa omotač), i ako radite na tome, možete dobiti neka ogromna ubrzanja u "tradicionalnijem" multi-core programerskom pristupu, kao što to možete dobiti korišćenjem NSOperationQueue.

Nije za svakoga, to je sigurno, ali će napraviti mnoge, inače složene stvari, lakšim za obavljanje.





Published (Last edited): 15-04-2013 , source: http://supermegaultragroovy.com/2009/11/12/swimming-in-opencl/