Stack Space & Ackermann

[H. S. Teoh via Digitalmars-d-learn]

On Thu, Jan 05, 2017 at 08:11:58AM +0000, Era Scarecrow via Digitalmars-d-learn wrote:
> On Thursday, 5 January 2017 at 07:30:02 UTC, H. S. Teoh wrote:
> > Nonetheless, even if you optimize said code paths, you still won't
> > be able to get any sane results for m>4 or anything beyond the first
> > few values for m=4. The Ackermann function is *supposed* to be
> > computationally intractible -- that's what it was designed for. :-P
> 
>  Yeah I know. The function as written is as it was shown on the video
>  and explained, and is badly formed. Memoize did give me real quick
>  results up to 4,1; But it's obvious getting anything better is
>  impossible as things stand.
> 
>  Still it did bring up how to handle needing larger stack spaces,
>  which I've wondered about with wanting to make large structures on
>  the stack so I wouldn't have to rely on actually allocating anything
>  and not having to clean it up afterwards. Simpler, cleaner & faster
>  memory management in my mind.

Actually, the runtime stack is really intended more for control flow
(e.g., to store function return addresses and arguments, local
variables, etc.) than for allocating large structures.  In the old days
Linux used to allocate only 4KB for the stack, though these days I'd
imagine it has been raised. (Well, in the *real* old days of Apple II,
the runtime stack was hardware-limited to 256 bytes. But those were
different times. :-P)  For large data structures you really should be
looking to heap allocation.

It is possible to have stack-like behaviour of heap-allocated data, such
as C++'s RAII idiom.  I haven't really tried that in D in a large scale
yet, but I'd imagine you should be able to do that in D quite easily as
well.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi