[C] Maximaal toegewezen geheugengebruik instellen

[bibawa]

Ik ben bezig met het maken van een programma dat de gebruiker toelaat een .bmp afbeelding te comprimeren naar een .pac bestand, wat later dan terug kan gedecomprimeerd worden etc..

Nu lukt het comprimeren zeer goed bij kleinere afbeeldingen (<5mb), vanaf het moment ik begin met foto's die genomen zijn met een digitale camera op grote resoluties en dus ook de eigenllijke bestandsgrootte groter wordt (17.4 MB) dan loopt na een tijd het programma vast en zegt hij iets dat het geheugen vol zit.

Nu heb ik de windows taakmanager ernaast opengezet en eens gekeken of hij wel degellijk volliep en dat gebeurd naar m'n verbazing niet, hij loopt vast op zo'n 420 MB, en in het systeem zit 512 MB.

dus hij zit belange nog niet vol, nu begin ik dus te denken dat een programma maar m aximaal x mb van het geheugen mag gebruiken of iets dergellijks.

Is deze redenering correct? en hoe zou ik het eventueel kunnen oplossen? Moet dit ingesteld worden in windows, of moet dat mee gecompileerd worden in de .exe zelf?

[scorpie]

Windows reserveert ook geheugen voor zichzelf, ik denk dat ie daarom aan miepen is..
Maar gebruik je bijvoorbeeld wel realloc ipv steeds maar calloc / malloc in C?

[Ivo]

Nog belangrijker, maak je ook weer geheugen vrij als je het niet meer nodig hebt?

[bibawa]

Ivo schreef op woensdag 22 februari 2006 @ 19:34:
Nog belangrijker, maak je ook weer geheugen vrij als je het niet meer nodig hebt?

Ik maak gebruik van malloc, maar het zit zo:

We lezen steeds 1 pixel in, en vergelijken die met een naastliggende pixel, als die ongeveer gelijk zijn (rekening houdend met variabele tolerantie) dan wordt er in een stucture een flag verhoogt met 1.

Dit gebeurt dus tot na x pixels gelezen te hebben de pixel te hard afwijkt van de eerst gelezen pixel, dan wordt er dynamisch ruimte gealloceerd, in een tabel en worden de nieuwe gegevens in een linked list gezet.

Het geheugen loopt al vol tijdens het aanmaken van de linked list, zolang er dus niet kan worden weggeschreven naar bestanden (na het aanmaken van de list) kan er niets worden gefreed.

De opdracht schrijft me jammer genoeg voor dat ik steeds met linked listen moet werken (wat de uitvoerbaarheid van het programma drastisch vertraagd dus..)

Maar er is dus nergens een manier om die geheugenruimte te vergroten van het programma zelf, of die van windows verkleinen, want als windows 100 MB geheugen reserveert dan is dat wmeer dan genoeg vind ik

[MSalters]

Eh, zo werkt geheugenbeheer onder Windows niet. Je krijgt ruwweg 1.7 Gb geheugenruimte toegewezen (in Win32). Hoeveel daarvan HD is, en hoeveel RAM, dat varieert dynamisch.

Afgezien daarvan is dit een opdracht met een onzinnige beperking, als je inderdaad alleen maar linked lists mag gebruiken. Een image is bijna altijd per definitie een 2 dimensionale array (en altijd bij .bmp, geen uitzonderingen). Linked list =/= Array.

[matthijsln]

Er is een verschil tussen "Mem Usage" en "VM Size".

Daarnaast duidt een geheugengebruik van minimaal 420 MB om een 17.4 MB bitmap te comprimeren op een verschrikkelijk geheugeninefficient algoritme. Je zou kunnen proberen om dit te kunnen verbeteren. Het geheugengebruik van een doorsnee compressiealgoritme wordt doorgaans eerder in KB dan MB gemeten. Probeer bijvoorbeeld eens met blokken van x bij x pixels te werken.

Je hebt het over een opdracht die gebruik van linked lists verplicht stelt. Voor een huiswerkopdracht is dat misschien logisch maar in combinatie met een eis voor een geheugenefficient algoritme niet, of wel? Voldoet je huidige oplossing met een maximale grootte van een bitmap niet aan de opdracht dan?

[ Voor 12% gewijzigd door matthijsln op 22-02-2006 20:57 ]

[bibawa]

het is inderdaad een huiswerk, meer een opdracht met 2 personen..

Dat linked lists iets is wat vertragend werkt moet je me al niet langer vertellen.

Erger nog het pompt samen met het geheugen ook de cpu load nog eens naar 100 % ook, hij handelt het programma echter wel vrij snel af en n een vrij korte tijd (als de bmp niet te groot is <5 MB), dus het ligt niet aan ons algoritme, maar ik denk meer dat wij met onze oude schoolse borland nog met een 16 bit compilertje zitten te klooien...

[Gonadan]

Om 100% CPU gebruik moet je je geen zorgen maken, dat krijg je ook met een while(true) loopje ook zo voor elkaar

Maar zoals Matthijsln al zei, kan je het niet opdelen? Bijvoorbeeld per rij of kolom?

[The End]

@MSalters. Hoe kom je aan 1.7 Gb, ik dacht dat het maximum 2 Gb was? Het maximum wat je kan gebruiken is compleet afhankelijk van de grootte van de pagefile (en of ie mag groeien), de hoeveelheid RAM geheugen en de hoeveelheid die al in gebruik is.

Het kan heel goed zijn dat als je programma 420 MB 'mem usage' heeft, dat ie ook 500 MB aan virtueel geheugen gebruikt (VM size in de taskmanager).

[MSalters]

Praktijk. Probeer maar, als je me niet gelooft. Oorzaken zijn o.a. DLLs en een lage reservering. De grootste continue allocatie is nog kleiner, die heb ik wel eens op 1.3 Gb gezien.

[masaman]

Die 1,7 of 1,3 GB barriere is er volgens mij helemaal niet. Voor een klant van ons heb ik ooit een stuk software geschreven die 2 GB alloceerde voor de tijdelijke opslag van gegegevens waaraan gerekend werd en dat ging zonder problemen. Het systeem was uitgerust met 4 GB. We draaiden Windows XP Professional als ik me goed herinner. Was wel een multiprocessor systeem maar ik betwijfel sterk of dit er iets mee te maken kan hebben. Die 2GB allocatie van geheugen was continue, was in feite een groot tweedimensionaal array. Met pointerberekeningen indexeerden we waar we in dat stuk geheugen iets wilden schrijven of lezen

[ Voor 20% gewijzigd door masaman op 23-02-2006 21:10 ]

[Soultaker]

Als ik hiermee test:

C:

#include <stdio.h>
#include <stdlib.h>
int main()
{
    for(int n = 1000; n < 2000; ++n)
    {
        void *ptr = malloc(n*1024*1024);
        if(!ptr)
            break;
        printf("%d MB\n", n);
        free(ptr);
    }
}

kom ik zowel met GCC als met MSVC++ tot 1915 MB. Klinkt mij wel redelijk in de oren; het is geen 2048 (kan ook niet; Windows reserveert een stukje aan het begin en het einde) maar het komt wel in de buurt, zeker als je meeneemt dat er bij het laden van de executable allerlei ruimte gereserveerd wordt voor de stack, de programmacode, DLL's enzovoorts.

[NMe]

masaman schreef op donderdag 23 februari 2006 @ 21:08:
Die 1,7 of 1,3 GB barriere is er volgens mij helemaal niet. Voor een klant van ons heb ik ooit een stuk software geschreven die 2 GB alloceerde voor de tijdelijke opslag van gegegevens waaraan gerekend werd en dat ging zonder problemen. Het systeem was uitgerust met 4 GB.

Windows heeft een maximaal 4GB aan geheugen te verdelen. De helft van het beschikbare geheugen neemt Windows zelf in beslag, en de rest kun je gebruiken voor andere applicaties. Je zal dan ook nooit boven die 2GB uit komen, en in de praktijk zul je zoals MSalters al zegt meestal minder dan dat kunnen gebruiken.

MS heeft er zelf ook wat over te zeggen:

quote: http://support.microsoft....aspx?scid=kb;en-us;555223

Processes and Address Spaces

All processes (e.g. application executables) running under 32 bit Windows gets virtual memory addresses (a Virtual Address Space) going from 0 to 4,294,967,295 (2*32-1 = 4 GB), no matter how much RAM is actually installed on the computer.

In the default Windows OS configuration, 2 GB of this virtual address space are designated for each process’ private use and the other 2 GB are shared between all processes and the operating system. Normally, applications (e.g. Notepad, Word, Excel, Acrobat Reader) use only a small fraction of the 2GB of private address space. The operating system only assigns RAM page frames to virtual memory pages that are in use.

[..]

Here's a list of how much RAM the various Windows versions and editions support (as of Nov 2004):

Windows NT 4.0: 4 GB
Windows 2000 Professional: 4 GB
Windows 2000 Standard Server: 4 GB
Windows 2000 Advanced Server: 8GB
Windows 2000 Datacenter Server: 32GB
Windows XP Professional: 4 GB
Windows Server 2003 Web Edition: 2 GB
Windows Server 2003 Standard Edition: 4 GB
Windows Server 2003 Enterprise Edition: 32 GB
Windows Server 2003 Datacenter Edition: 64 GB

Tenzij je dus met een duur server-OS werkt kun je nooit meer dan 2GB aan je proces toekennen, simpelweg omdat Windows dat geheugen niet kan adresseren.

[Voutloos]

bibawa schreef op woensdag 22 februari 2006 @ 19:53:
We lezen steeds 1 pixel in, en vergelijken die met een naastliggende pixel, als die ongeveer gelijk zijn (rekening houdend met variabele tolerantie) dan wordt er in een stucture een flag verhoogt met 1.

Alleen horizontaal, of alle aangrenzde pixels? Anders kan je wel elke complete rij efficiënter opslaan en die rijen vervolgens linken, doe je nog steeds wel 'iets met linked lists'.

De geheugen discussie is voor deze opdracht niet relevant, voor een huiswerk opdracht kunnen ze niet zomaar ervan uitgaan dat je een hip server OS hebt.

[ Voor 15% gewijzigd door Voutloos op 23-02-2006 21:56 ]

[Matthiasje]

Dit klinkt als Run-Length Encoding (RLE), zoals dat in veel grafische bestandsformaten gebruikt wordt.

Het is wel degelijk mogelijk om daar dingen weg te schrijven terwijl je aan het inlezen bent. Namelijk zodra je na een reeks (min of meer) identieke pixels een pixeltje tegenkomt dat een afwijkende kleur heeft.

Dan kan je de vorige reeks direct wegschrijven en opnieuw beginnen met tellen hoeveel dezelfde pixels je tegenkomt.

[ Voor 8% gewijzigd door Matthiasje op 23-02-2006 22:18 ]

[4VAlien]

Ik probeerde wat informatie over het format te vinden maar dat is lastig. Heb je een link naar de specificatie van dit formaat ? Dit is interessant