-4

I want to write a C program whose memory will be constant. It can never allocate more memory than certain amount. 

int main(){
   int memory[512];
   int i = 5;
   i = i + 5;
   memory[50] = i;
};

Notice that on this example i = 5 and i = i+5 will allocate memory. I want to completely avoid the internal memory allocation procedure (which I believe is kind of slow).´Is there a way to tell C to allocate it directly on my memory array?

MaiaVictor
  • 51,090
  • 44
  • 144
  • 286
  • 6
    There's no heap allocation here. Just stack allocation. – Mysticial Dec 06 '13 at 07:14
  • Yeah, but you need to forego the calls to `malloc()` and write your own memory allocator. – user1095108 Dec 06 '13 at 07:15
  • If you don't want dynamic memory allocation, don't use it. `i = i + 5;` is not memory allocation. It's memory **assignment**. Everything in your sample is on the *stack*. – ciphermagi Dec 06 '13 at 07:15
  • @user1095108 that is the information I need - how can I write my own memory allocator in such a way only it will be used? (Also, fixed that, @Mysticial) – MaiaVictor Dec 06 '13 at 07:16
  • 5
    Heap allocations can be avoided by not calling `malloc()`. Stack allocations can be avoi... - errr... they *can't* be avoided. Even `int main(){}` has a stack allocation. – Mysticial Dec 06 '13 at 07:19
  • 1
    These will never affect your speed.So actually thereis no need.Even on your example most compilers will not allocate even , they will just use register , .You can add register keyword to tell it to use register if possible. And cpu registers is the fastest. – qwr Dec 06 '13 at 07:22
  • 2
    If you call any library functions, they may use `malloc()` internally. There's nothing you can do to prevent this. – Barmar Dec 06 '13 at 07:22
  • 2
    Also, why are you trying to do this? Is it for performance? Stack allocations are already the fastest it will get. It's the heap allocations that are potentially slow. – Mysticial Dec 06 '13 at 07:22
  • 6
    "which I believe is kind of slow" - You have absolutely **no right whatsoever** to assume this and that. If you deduced, **by properly benhmarking your code,** that heap allocations cause the main bottleneck, **only then** can you go ahead and try to rewrite it so that there are less (or potentially no) heap allocations. But again, that needs a fair amount of testing and measurement. ***Please do not engage in horrible premature optimization.*** –  Dec 06 '13 at 07:24
  • Unless you have automatic arrays with dynamic sizes, most C compilers will do a single allocation of all local memory for a function as soon as you enter the function. This is fast -- it's just part of the stack pointer adjustment that has to be done when entering the function anyway. – Barmar Dec 06 '13 at 07:26
  • The problem itself is that I'm writing a compiler from a language that has dynamic arrays to C, but I want to avoid the costs of passing through the memory allocation procedure which, as much as I didn't test, is **obviously** slow in comparison to what I need (and it is **never** premature optimization when you are optimizing a programming language). But I already figured out the answer from this thread, thanks! – MaiaVictor Dec 06 '13 at 07:38

5 Answers5

3
int memory[512];    int i = 5;

By doing this you have already allocated memory. Even if you do not fill elements after 100, there will be still total allocations of 512 ints for variable memory and 1 int for variable i.

If you need dynamic allowcation you can check malloc() or calloc().

Chinna
  • 3,930
  • 4
  • 25
  • 55
Digital_Reality
  • 4,488
  • 1
  • 29
  • 31
  • 14
    You avoid it by not declaring the variable. – Barmar Dec 06 '13 at 07:23
  • 3
    This way leads only to madness and pain. Plus, this smells of premature optimization. I can almost guarantee you that dynamic memory allocation is _not_ affecting your program's performance. – rossipedia Dec 06 '13 at 08:05
  • Allocation/deallocation of stack variables is little more than `ESP -= 2048` at the beginning of the function, so it's basically free. – CodesInChaos Jan 02 '14 at 23:30
2

You should change "which I believe is kind of slow" to "I am certain that it will not affect program speed"

qwr
  • 3,660
  • 17
  • 29
1

First, the "allocation" for local ("stack") variables is very very fast, and generally happens at compile-time when the function's stack frame is laid out. There is no overhead per variable at run-time, that's just not how it works.

Second, if you want to avoid having a variable such as int i; take up further stack space, then you must avoid having that declaration in the code.

You can use the "block" you allocated but it's going to be painful:

int space[512];

space[0] = 5;
space[0] += 5;
space[50] = space[0];

The above replicates your use of i but instead manually "allocates" space[0] in the array. Of course, the above very likely generates worse code than just having a plain i, all for the sake of saving one int's worth of stack space.

unwind
  • 391,730
  • 64
  • 469
  • 606
0

Use globally declared variables only.

This however is bad advise for other obvious reasons: https://stackoverflow.com/a/176166/694576

Community
  • 1
  • 1
alk
  • 69,737
  • 10
  • 105
  • 255
0

The likely allocation cost of int i = 5; and i = i + 5; is zero. Single int variables inside methods just don't have any appreciable allocation cost. The compiler has several options here:

  1. It will strive where possible to do the arithmetic at compile time and eliminate the variable entirely (memory[50] = 10;), meaning that at run time both the allocation and the arithmetic have no cost.

  2. It will strive where possible to put the variable in a CPU register (zero allocation cost but still takes time for the arithmetic).

  3. Failing that, it will reserve space for the variable on the stack, which consists of decrementing the stack pointer by 513*sizeof(int) bytes instead of 512*sizeof(int) bytes. It still won't take extra time. The OS might be obliged to fetch an extra page of memory for the thread's stack but this is more-or-less a one-time cost.

Boann
  • 48,794
  • 16
  • 117
  • 146