GlobalAlloc || malloc

I don''t know about speed differences, but malloc is portable. You might also want to find out about the ''new'' operator if you''re using C++.

All your bases belong to us (I know. It''s irony.)

Okay boys and girls, gather round the camp fire and let me tell you a story that will scare you $hitless.

Once upon a time intel CPU's where segmented (in fact they still are). Each segment was 64kb in size. So to access memory you needed two registers the Segment register and an other who's name escapes me for now.

So if you wanted to traverse a 64K boundary you needed to increment the segment register 256. Why 256 well the bottom 8 bits of the segment register addressed the same pages as the top 8 bits of the addressing register. 86/186/286 memory addressing is 24 bits.

Now enter Windows 3 into the fray. It used memory banking (NT still does but it does so under wraps). So to allocated memory so that the CPU would force the memory to be swapped into real memory if it was currently banked onto disk, you used GLobalAlloc and GlobalFree. If you used alloc() the memory pointer would return a block in Local Memory block. This was a local heap of memory that was 64kb in size. In fact if you wanted to allocate anything greater than 64K you needed to allocate it in powers of 2, i.e 128K, 256K, etc... Did I also mention that memory allocated had to be divisable by 2, and any memory address access was the same, read 'No odd address access'.

The up side of this memory scheme was that if you used a ;wild' memory ptr and then tried to access the address a GPF (General Protection Fault) would ensue. Great for tracking memory errors.

The advent of 32 bit registers in the 386 increased segment sizes to about 4GB.

So today there is no 'Global Memory' it is all 'Local' i.e. the heap is around 1GB.


I make no apologies for any inaccuracies in this post. I have tried very hard to forget what I once had to go through.



D.V.

Edited by - DeltaVee on November 13, 2001 2:49:35 PM

quote:

---

Original post by DeltaVee
Okay boys and girls, gather round the camp fire and let me tell you a story that will scare you $hitless.

---

Didn''t scare me.

quote:

---

Once upon a time intel CPU''s where segmented (in fact they still are). Each segment was 64kb in size. So to access memory you needed two registers the Segment register and an other who''s name escapes me for now.

---

There were Index registers for the specific purpose of indexing memory, but you could also use the general purpose registers for the same.

quote:

---

The advent of 32 bit registers in the 386 increased segment sizes to about 4GB.

---

In actuality, it wasn''t just the registers that caused the increase in segment sizes. By default, even your top-of-the-line Pentium4 2Ghz monster starts up in 16-bit segmented mode. The major turning-point was the addition of ''protected-mode'', which was the mode the CPU had to be in in order for the flat memory model to be available.

All your bases belong to us (I know. It''s irony.)

quote:

---

I make no apologies for any inaccuracies in this post. I have tried very hard to forget what I once had to go through.

---

ok,
that was very informitive, thanks=)

but, im still wondering, what call should i use...
malloc, globalalloc, or virtualalloc?

ok, thanks alot=)
seems kinda counterproductive to have so many functions that "alias" other ones...strange lol

If anyone is really intereted in how NT handles memory, I would higly recommend checking this out.

ok, let me give you some more info on what im doing,
im allocating image data and 3d mesh vertices,

so it''s pretty sizable data, that is allocated once in the program,

so should i use virtual alloc?

i want to use a function that doesnt end up calling a bunch of other functions that i could have called myself.

If it is performance you are worried about you need to ask yourself ''How many times am I allocating memory and freeing it?''.

If you are only doing infrequently, it really doesn''t matter. But if you are diung it in every frame you a) need to rework your code so that this does not happen (it is very inefficient IMHO) or use virtualalloc (it appears to be the root function).

I use malloc/free (well new/delete in reality), I don''t call it alot so it makes no difference to me.

D.V.

I use VirtualAlloc for windows development for two reasons.

1. Its the lowest level memory allocation available in Windows, ie: all other memory allocations will eventually go throw this function.

2. I have control over the type of memory being allocated, ie: PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE... This is very useful for debugging and optimization.

I allocate all of my memory at the start of the program, in separate banks depending on how I will be using it. Then I have my own memory allocation function that does the dirty work. Most of these calculations are done at compile time. In some cases the overhead for memory allocation is only 1 cycle. It just wouldn't make sense to use malloc in the inner loop on say a linked list.

Portability is easy because I use abstraction.

quote:

---

Windows SDK

The following functions are equivalent: GlobalAlloc, LocalAlloc, and HeapAlloc with the handle returned by the GetProcessHeap function.

The VirtualAlloc function allows you to specify additional options for memory allocation. However, its allocations use a page granularity, so using VirtualAlloc can result in higher memory usage.

The malloc function has the disadvantage of being run-time dependent. The new operator has the disadvantage of being compiler dependent and language dependent.

---

Edited by - burp on November 14, 2001 11:32:38 AM

I had question like this a week before. I was wondering what
the mood was like on using extended memory management programs
like XMS and DPMI in DOS and Windows environment.

How do you rate these memory management programs? Your opinions
are greatly appreciated.

Thanks,
BM