1

Question is self-explanatory (I hope).

I am trying to avoid new/delete (malloc/free) as much as possible where object lifetime falls within the stack frame's lifetime. It seems to me the cache hits, paging, etc. would be the same (stack v/s heap), no?

Of course, the usual fine print applies: avoid recursion, set stack limit in OS, etc.

Benito Ciaro
  • 1,718
  • 12
  • 25
  • http://stackoverflow.com/questions/1825964/c-c-maximum-stack-size-of-program might be useful. – Thomas Apr 24 '14 at 13:23
  • Generally speaking, the usual fine print is why you shouldn't do this. So if we ignore that, then... go for it? (I would suggest that if you can get away with a static array, then you get the benefit of not being on the stack, and not being on the heap). – Bill Lynch Apr 24 '14 at 13:27
  • 1
    @sharth: At the cost of code that cannot run multiple threads... I would **not** do that. – David Rodríguez - dribeas Apr 24 '14 at 13:29
  • There are very few environments where the method used for a single 32KB allocation (or even 1 per thread) makes any difference. This is premature optimization. E.g. initializing the 32K will generate roughly 1000 times the memory traffic of a `malloc` call. You're counting angels on pinheads. – Gene Apr 24 '14 at 15:08
  • @BenitoCiaro Almost impossible. If `malloc` / `free` pairs occurring within the scope of a function call cause fragmentation, you have a terrible implementation that is not suitable for a server anyway. Ditto for _any_ `malloc` / `free` pairs of uniform-sized blocks. If the `malloc` implementation is any good at all, fragmentation will occur only with non-LIFO _and_ non-uniform size allocations and deallocations. – Gene Apr 24 '14 at 17:49

2 Answers2

2

The 64 bit address space is irrelevant. What matters is how much space is reserved for the stack. If your object fits inside the reserved size of the stack, then go ahead and allocate it on the stack.

On the other hand, if you have a 32KB object, then presumably you are going to operate on it. And for an object of that size, surely the cost of the operations will completely overwhelm the cost of a single heap allocation. So I'm not sure that the benefit of stack allocation will be measurable. So if you have any doubts about fitting the object on your stack, then you've nothing to lose by putting it on the heap.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
2

This really depends on the OS, the configuration and whether you are using threads and how they are created. For example, the main thread in linux has an unlimited stack (limited only by the configuration in ulimit), on the other end, a thread spawned with pthread_create on AIX defaults to 96Kb of stack.

You need to look into your target architecture and the APIs to create threads (if you are doing multithreading) to be able to answer this.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • Note that `ulimit` does not apply to **all** threads, but only the main one (from a comment in a different question it seems that you want something like 64 threads?). You might want to take a few other things into consideration. The main thread *grows* the stack as needed, pthreads get their stack allocated in construction (this might not be an issue as the the memory allocator will overcommit and this means that only as much memory as you need will really be *used*). By default linux pthreads are (I believe, double check this) about 1M (maybe 10M?) and that should be more than enough. – David Rodríguez - dribeas Apr 24 '14 at 14:33
  • ... if you need more than that, you probably want to dynamically allocate the memory as that might be more efficient. As an example, a function allocating an array of 1Mb, and calling a few other functions will always have that in the stack, and this might make the rest of the variables in the context of one function to be far away from the variables in the called function effectively reducing locality (would this matter? probably not)... – David Rodríguez - dribeas Apr 24 '14 at 14:35