This is merely out of interest and I personally use C++Builder 2009
Suppose I allocate: wchar_t Buffer[32] or I allocate wchar_t Buffer[512]
The second call allocates more memory, so you could argue that the second call is more expensive in terms of memory usage.
However, is anything else also possibly affected by allocating more memory this way ? Are there more instructions involved ? More CPU usage ?
Just wondering ?
However, is anything else also possibly affected by allocating more memory this way ?
There can be one related side effect: when you allocate more memory for your buffer, you increase the chance that the stack pages the program needs to access will be split across more cache lines, which may ultimately mean the CPU has to wait for a cache miss that otherwise wouldn't have happened. Note that there's no particular reason here to think you're using more of the buffer: the "problem" is that the CPU's likely to be asked to get data before and after the buffer, and all of that may be split across more cache lines. These stack pages around the buffer are likely to be accessed often enough to keep them in cache, but in doing so some cache content that hasn't been used for a while may be ejected, and if that's later needed then you have a cache miss. The granularity of the cache lines (how many bytes per "page") can also affect how this pans out.
This is usually totally insignificant, but you asked... ;-).
Are there more instructions involved ?
No more instructions are involved.
More CPU usage ?
In as much as time waiting for a cache is "usage".
This is ''allocating'' stack memory. All this requires is adjusting the stack pointer. If you write a function like:
void foo()
{
char c[32];
...
}
The resulting assembly looks like (on a 64-bit machine):
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $48, %rsp // This is the actual "allocation" on the stack
If you change this to char c[512], the only thing that changes is:
subq $528, %rsp // Allocation of 512 bytes on stack
There is no difference in CPU instructions or the time this takes. The only difference is the second uses up more of the limited amount of stack memory.
There won't be any difference in the instructions by allocating more size. Also the stack memory is known at compile time and compiler generates the required instructions.
For Example ::
int main()
{
char Buffer[1024] ;
char Buffer2[ 512] ;
return 0 ;
}
00981530 push ebp
00981531 mov ebp,esp
00981533 sub esp,6DCh //6dch = 1756 just the esp is adjusted to allocate more memory
00981539 push ebx
int main()
{
char Buffer[32] ;
char Buffer2[ 512] ;
return 0 ;
}
00D51530 push ebp
00D51531 mov ebp,esp
00D51533 sub esp,2FCh //2fch = 764 now the esp is adjusted to 764 without any instruction change.
00D51539 push ebx
Are there more instructions involved ? No, you can see the above example :)
More CPU usage ? No, because same number of instructions got executed
More Memory usage ? Yes, because more stack memory allocated.
In operating systems a memory management implementation called dynamic loading only loads routines as it is called instead of loading all routines in your program into the main memory. When the routine is loaded all its elements' addresses have to be loaded into the page table for address translations. The content corresponding to a particular address is loaded in unit called page.
Page sizes are of usually in smaller orders of 2kb or 4kb. If the content exceeds the page size then it is split up and occupies more than one page. When page fault occurs a new content is loaded overwriting the older content based on page replacement policies to a swap space. When the replaced content is again needed MMU will again load the content from the swap space to the page. This
Let's think what could happen if larger content is involved for loading and swapping, it's a performance issue and involves some cpu cycles.
As per your questions it's not an impact with arrays of wchar_t of size 32 or 512. But a different data structure having a size in Megabytes and an array of this structure in few thousands will make some impact on memory and CPU. I suggest you to have look here.
I think if you are calling the first one to the same extent, meaning the same amount of bits, then it would be better to use wchar_t Buffer[512] simply because it would take longer and, I believe, use more resources to start a call exit and then start another, and keep going. But with the second you have one start and then it is tied to that task, which is fine as long as you don't want to do anything else for a while. Hope that helped.
