Mennyi a reális memóriafogyasztás?

 ( emberk | 2009. december 7., hétfő - 15:56 )

Sziasztok!

Írtam egy képfeldolgozó programot (ill még félkész természetesen), ami 2048*2048-tól 8192*8192-ig 2^x pixelszámú komplex képeket dolgoz fel, double pontossággal. Lényegében fft, opencv segítségével. Az a gondom a dologgal, hogy bődületes mennyiségű memóriát eszik meg a szoftver. Ami logikus is lenne a maximum közelében. De már 2048*2048-esetén is 700-Mb- fogy, ami folyamatosan növekszik, 1,2,3 rekonstrukció után. Van egy gyanúm, hogy én vagyok a hunyó, mert hiába szabadítom fel a pointereket, ami a memóriablokkokra mutat, akkor is eszi a memóriát masszívan. 3. rekonstrukció után már több mint 2Gb fogy el.
Írok részleteket:
IplImage *im;
IplImage *im2;
IplImage *realInput;
IplImage *imaginaryInput;
IplImage *complexInput;
IplImage *realInput2;
IplImage *imaginaryInput2;
IplImage *complexInput2;
int dft_M, dft_N;
CvMat *dft_A, *dft_B, tmp, tmp2;
IplImage *image_Re;
IplImage *image_Im;
//Adatelereshez
int step = dft_A->step/sizeof(float);
float *data = dft_A->data.fl;

matek rész, ami csak az adatokat manipulálja. Lényegében egy Fresnel lencse hatását szimulálja a tömbön. Valamint megtölt újabb adatokkal egy globálisan dekralált statikus tömböt, mert utána még az adatokkal nagyon sok dolgot kell tenni

Majd memóriafelszabadítás:
cvFree_ (im);
cvFree_ (im2);
cvFree_ (realInput);
cvFree_ (imaginaryInput);
cvFree_ (complexInput);
cvFree_ (realInput2);
cvFree_ (imaginaryInput2);
cvFree_ (complexInput2);
//int dft_M, dft_N;
cvFree_ (dft_A);
cvFree_ (dft_B);
cvFree_ (image_Re);
cvFree_ (image_Im);

Van valami ami miatt ez marhaság? HA sima free-vel szabadítom fel a tömböket akkor lefagy a szoftver.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

UP. Hátha valaki.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

a statikus tomb nem nohet meg annyira?

Kétlem de megnézem. Mindíg felűlírom az adatokat, és nem helyet foglalok.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

probald meg felszabaditani a tombot, majd ismet lefoglalni a memoriat...idoigenyes futas szempontjabol,de egy probat meger

nem kotozkodesbol , de mintha ellentmondasban lenne a ket fogalom : statikus - nohet
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

Szerintem nem egyszeru tombot hasznal hanem vectort...az meg ha statikus akkor is nohet , de fixme :)

Még cask simán egy statikus double tömb, amiből szeriintem float lesz mert az utómunkálatoknál (amint látom) nem kritikus az számábrázolás pontossága. Az is egy kis megtakarítás.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

A memóriafolyás (memory leak) megtalálásához használhatók pl. ezek az eszközök is: Valgrind, glibc Memory Allocation Debugging.

a Valgind első ránézésre nagyon jónak tűnik. Kipróbálom. Bár amint látom pilótavizsgás, de a programozás márcsak ilyen. Köszönöm.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Nem, nem pilotavizsgas. Kifejezetten baratsagos, nezegesd csak meg.

----------------------
while (!sleep) sheep++;

Aha és tényleg, tényleg egyszerű használni. Valóban korrekt cucc. Na alakul ez. Köszi. Nagyon bejön. De ma már alvás inkább, és holnap frissebben. Nagyon köszi, az ötletet. Nagyon profi program.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Egy 2k x 2k-s, double complex tomb az 64 mega memoriat fogyaszt, szoval tenyleg ele'g egy par kosza kifelejtett felszabaditas, es elszall az egesz. ha fekete dobozt (kulso konyvtarat) hasznalsz, akkor szerintem lepesrol lepesre nezd vegig:
- kep beolvasasa
- beolvasott ke'p dft-je'nek kiszamitasa uj tombbe (ekkor me'g csak 2x64mega kell hogy lefoglalva legyen)
- kepek felszabaditasa
- stb...
Es csak utana a bonyolultabb dolgok (tobb iteracio, tobb kep konvolucioja, stb, amiket csinalsz). A dft/fft mint operacio nem igenyel jarulekos memoriat (ordo(1), ha ugy tetszik), ha a bemeneti adatsort felulirja annak a fourier-transzformaltja, es ez igaz 2d-s (tetszoleges dimenzioju) kepekre is. Tehat az, hogy sokszor dft/fft-zel, az onmagaban nem ok arra, hogy elszalljon a memoria. Nem tudom, hogy ez a konyvtar hogy implementalja a gyakorlatban, de ez nem lehet szuk keresztmetszet.

Köszönöm. Én is 64-Mb-nak számoltam. Azért lepődtem meg azon, hogy első körben 700Mb. A valgrind amit fentebb ajánlottak ignecsak ügyesnek tűnik, holnap vadászok tovább. Köszönöm a segítséget.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

valgrind amit fentebb ajánlottak ignecsak ügyesnek tűnik
igen, az +1, hatarozottan. annyira egyszeru az alap-uzemmodja mint a sza'zasszo"g (be kell irni a program neve ele' azt hogy `valgrind` es kiir minden leak-informaciot amiutan lefutott a program). persze tud az tobbet is, de elso kozelitesben erdemes megnezni igy egyszeruen is.

ha meg nem nagyon ismero"s a konyvtar belso lelkivilaga, akkor meg erdemesebb egyszerubb problemak felol indulni (lasd feljebb). az teny, hogy az fft nem egy memoriaigenyes valami alapbol, szoval ekkora adatmennyisegekkel mennie illene (pl sajat implementacioval 4k-s kepek teljesitmenyspekturma, autokorrelacioja siman szamolhato egy 512mega ramos gepen, tapasztalat).

ordo(1), ha ugy tetszik
o"o", ez meg sem igaz teljesen. 1d-ben a jarulekos memoriaigeny ordo(n) altalanos primbazisu dft eseten, primitiv implementacioval. ha minden igaz, trukkosen le lehet vinni ordo(p_max)-ra, ahol p_max n primfelbontasaban szereplo maximalis prim, de ez mar a sebesseg rovasara megy. illetve van egy alap-permutacios lepes is, ott is lehet trukkozni.

2d-ben ill. magasabb dimenzioban viszont ordo(legnagyobb_kiterjedes) lesz a memoriaigeny, azaz negyzet/kocka alaku kepekre tenyleg elhanyagolhato.

A.