Aleksandar Donev wrote:
>
> Dick Hendrickson wrote:
>
> >I wouldn't say it that way.
> >
> What a nice way of telling me I am wrong :)
>
> Peter S. also said:
>
> There is no cost to allocation on the stack if the stack is big
> enough. Unlike typicall malloc/ALLOCATE strategies, the process
> doesn't have to call the kernel to grow the virtual address space...
>
> None of us is quite right. These things do depend on the OS+hardware,
> for example. It is definitely not true that stack space is by some
> miracle "unbounded" and can grow and never shrink, though the kernel
> needs not keep the same kind of bookkeeping for it as for heap space, so
> you are both more correct then I was in my first post.
>
> If I were a compiler (!?!), I would use heap space for automatic arrays
> which I cannot find the size of. If these arrays are big (as they often
> will), allocating them on a stack is silly if not impossible.
>
You reminded me of something I was going to add. Many compilers do
some sort of conditional preamble code for automatic arrays. If the
array is big, it gets "allocated" on the heap. If it's small the
add it onto the stack.
Maybe Van should try different size arrays and see if that affects his
relative timings.
Also, I was apparently confused by Van's first post. From his comments
I thought the allocate routine he timed was one of his, but from a
later comment it looks like it is the compiler's run-time allocate
routine. Obviously, none of my earlier suggestions apply to what he
can do to/with/for the system routine, sorry.
Dick Hendrickson
|