Author Topic: Memory management from a performance standpoint  (Read 11481 times)

Greenhorn

  • Member
  • **
  • Posts: 93
Re: Memory management from a performance standpoint
« Reply #15 on: July 25, 2012, 04:12:01 AM »
Yes, very interesting approach, Jochen.  :t


Greenhorn

AKRichard

  • Guest
Re: Memory management from a performance standpoint
« Reply #16 on: July 26, 2012, 08:41:25 PM »
You need to find a balance between speed and complexity. The circular buffer works just fine for many small allocations, and is a lot faster than HeapAlloc.

Try to distinguish
- parts of your code that need many small allocations ---> circular buffer
- parts of your code that need a few big allocations ---> HeapAlloc or VirtualAlloc

Your OS allows to allocate a 400MB circular buffer, and you can specify 20,000 slots if that is needed. The speed advantage will stay.

  I do have the slot manager working, though the return values are still being handled with malloc, I am finally getting comparable speeds.  I have just a few more questions then Ill let this thread drop.

1.  VirtualAlloc assigns a range of virtual memory then maps physical memory to it? if that is correct, wouldnt that be slower then malloc?
2. whats the difference between malloc and heapalloc?

  Sorry if some of the questions seem pretty basic, but I really havent messed with the native side of c++ a whole lot

npnw

  • Member
  • **
  • Posts: 151
Re: Memory management from a performance standpoint
« Reply #17 on: July 27, 2012, 03:06:09 PM »
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx

malloc
http://msdn.microsoft.com/en-us/library/aa246461(v=vs.60).aspx

malloc returns a void pointer to the allocated space, or NULL if there is insufficient memory available. To return a pointer to a type other than void, use a type cast on the return value. The storage space pointed to by the return value is guaranteed to be suitably aligned for storage of any type of object. If size is 0, malloc allocates a zero-length item in the heap and returns a valid pointer to that item. Always check the return from malloc, even if the amount of memory requested is small.

heap alloc

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366597(v=vs.85).aspx

Now there may be some differences depending on the target platform for development, and or environment Windows xp, vista, 7, or 8, not sure. These were specific to their environment. 
It doesn't look like they have changed for a long time from memory. 

Hope this helps.

MichaelW

  • Global Moderator
  • Member
  • *****
  • Posts: 1209
Re: Memory management from a performance standpoint
« Reply #18 on: July 27, 2012, 03:21:27 PM »
The "storage space pointed to by the return value is guaranteed to be suitably aligned for storage of any type of object" statement is far out of date.
Well Microsoft, here’s another nice mess you’ve gotten us into.

npnw

  • Member
  • **
  • Posts: 151
Re: Memory management from a performance standpoint
« Reply #19 on: July 27, 2012, 05:05:18 PM »
Quote
The "storage space pointed to by the return value is guaranteed to be suitably aligned for storage of any type of object" statement is far out of date.

I didn't catch the last part of that when I posted it. My fault.  It does remind me of early Windows programming.
Have to find a more recent explanation of this in MSDN.


npnw

  • Member
  • **
  • Posts: 151
Re: Memory management from a performance standpoint
« Reply #20 on: July 27, 2012, 06:01:52 PM »
Here is the 2012 Visual Studio RC version of malloc.
http://msdn.microsoft.com/en-us/library/6ewkz86d(v=vs.110).aspx

jj2007

  • Member
  • *****
  • Posts: 7765
  • Assembler is fun ;-)
    • MasmBasic
Re: Memory management from a performance standpoint
« Reply #21 on: July 27, 2012, 06:10:03 PM »
VS 2012: "The storage space pointed to by the return value is guaranteed to be suitably aligned for storage of any type of object."

Since M$ won't tell you, you'll probably have to launch the debugger to find out that it's VirtualAlloc under the hood, i.e. "align 4096" - simple but a bit slow for small allocations.

npnw

  • Member
  • **
  • Posts: 151
Re: Memory management from a performance standpoint
« Reply #22 on: July 28, 2012, 02:57:42 AM »
jj,

Wasn't 4096 the page size. That way if it was paged it wouldn't cause a fault?

jj2007

  • Member
  • *****
  • Posts: 7765
  • Assembler is fun ;-)
    • MasmBasic
Re: Memory management from a performance standpoint
« Reply #23 on: July 28, 2012, 03:26:29 AM »
Well, that arrogant phrase "guaranteed to be suitably aligned for storage of any type of object" suggests they are using a full page. Post an exe with an int 3 inserted before the "malloc", and we'll see if it's VirtualAlloc...

npnw

  • Member
  • **
  • Posts: 151
Re: Memory management from a performance standpoint
« Reply #24 on: July 28, 2012, 09:03:57 AM »
jj  Well, that arrogant phrase "guaranteed to be suitably aligned for storage of any type of object" suggests they are using a full page. Post an exe with an int 3 inserted before the "malloc", and we'll see if it's VirtualAlloc...

 LOL!

A man after my own heart. 

The INT 3 instruction is defined for use by debuggers to temporarily replace an instruction in a running program, in order to set a breakpoint. Other INT instructions are encoded using two bytes. This makes them unsuitable for use in patching instructions (which can be one byte long). (see SIGTRAP)
The opcode for INT 3 is 0xCC, as opposed to the opcode for INT immediate', which is 0xCD imm8. According to Intel documentation: "Intel and Microsoft assemblers will not generate the CD03 opcode from any mnemonic" and 0xCC has some special features, which are not shared by "the normal 2-byte opcode for INT 3 (CD03)" [IA-32 Arch. Software Developer’s Manual. Vol. 2A]

jj2007

  • Member
  • *****
  • Posts: 7765
  • Assembler is fun ;-)
    • MasmBasic
Re: Memory management from a performance standpoint
« Reply #25 on: July 28, 2012, 09:19:34 AM »
lol ;-)

I am not a C coder, but if I remember well, you can insert something like _asm int 3; in C code; which would trigger the Just In Time debugger, Olly in my case.

Cheers, Jochen

MichaelW

  • Global Moderator
  • Member
  • *****
  • Posts: 1209
Re: Memory management from a performance standpoint
« Reply #26 on: July 28, 2012, 11:28:56 AM »
Under Windows 2000 and XP the minimum alignment for VirtualAlloc appears to be 65536, or 16 pages.
Well Microsoft, here’s another nice mess you’ve gotten us into.

AKRichard

  • Guest
Re: Memory management from a performance standpoint
« Reply #27 on: August 06, 2012, 08:05:14 PM »
Lake Tahoe is great for taking your mind off things.  I hated to leave.

  Anyways, I have a modified version of the slot manager that can grow as needed, its not truely circular anymore, but works well even with the return values now .  Im not getting as fast of results with my code as you did yours, but it is running stably in single threaded mode(I have a glitch somewhere that only shows up in multithreaded apps that I may be posting about on another thread if I dont figure it out soon).

npnw, thanks for the links, I had read the one on malloc, but not virtualalloc or heapalloc.  Kind of off topic, but is virtualallocex how they inject code (for creating a hook into one of the windows apis)?

  Thanks everyone for the help.

merlin

  • Guest
Re: Memory management from a performance standpoint
« Reply #28 on: August 17, 2012, 01:57:10 AM »
Check this link.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx

"VirtualAlloc cannot reserve a reserved page. It can commit a page that is already committed. This means you can commit a range of pages, regardless of whether they have already been committed, and the function will not fail."

MEM_LARGE_PAGES
0x20000000

Allocates memory using large page support.
The size and alignment must be a multiple of the large-page minimum.
To obtain this value, use the GetLargePageMinimum function.

You could just use VirtualAlloc and use the GetLargePageMinimum. I don't know how efficient this would be.




kinjo

  • Regular Member
  • *
  • Posts: 2
Re: Memory management from a performance standpoint
« Reply #29 on: January 16, 2017, 07:15:43 PM »
I am having memory_management problem in my PC