Yet another strike against the current AA implementation

[Andrei Alexandrescu]

Georg Wrede wrote:
> Andrei Alexandrescu wrote:
>> Georg Wrede wrote:
>>>>> I can't believe you brought it up as anything else but jesting 
>>>>> (maybe you are and I'm not getting it).
>>>
>>> Having looked into things, it turns out I'm the one that now suspects 
>>> you of jesting.
> 
> Could it be that you're looking at this too much through the eyes of a 
> compiler developer? With souce code that can include templates, it 
> should be no surprise that a programmer can write a file which results 
> in preposterous stack needs. This is certainly the case with C++, for 
> example.

I am sorry, I need to fix a few mistakes in this post and then I'll have 
to leave this conversation as it becomes ungainful for us both.

The above is wrong, or at least contains a claim that you'd need to 
support better. Stack size requirements grow with the prevalence of 
short functions. Those are a style of programming not particularly 
correlated with templates. I don't have lots of small functions that 
call one another in templated code, any more than in regular code.

>> What I referred to was inferring a thread's actual stack requirements 
>> from one trace of its run. 
> 
> Of course you'd give different input data, a little like you give 
> different input data to your unit tests.
> 
>> That's just untenable.
> 
> Agreed, IF there's a possibility of recursion happening, the variation 
> in input data is not guaranteed, etc. But for practical purposes (read: 
> most of my programs, and presumably those of the other programmers'), 
> the situation is different.

This is utter nonsense. Practical vs. theoretical has absolutely nothing 
to do with this all. Forget recursion. I'm talking about straight "if"s 
that create different program traces that in turn require different 
stack sizes. Collecting one and saying it's fine "for practical 
purposes" is just nonsense. What's so complicated about this?

> For a particular application, we expect some explicit or implicit 
> constarints on the input data. We also know (er, expect) whether (and to 
> what extent) there will be recursion. Additionally (as with any 
> real-life application), we accept that if the input data goes wild, the 
> application /doesn't/ have to cope with it. (Making nuke proof apps 
> where reasonably good is sufficient, is just gratuituous work.)

Again, just to drive the point home - recursion has nothing to do with. 
Your inferences are starting from a faulty premise.

> For example, a robust application, instead of accepting and coping with 
> *anything*, instead has *documented limitations*. IMHO, that is the 
> right way to "fix infinity problems". Not demanding limitless stack for 
> all kinds of programs.
> 
>>>> Maybe I'll have to dig up prior art, or something. Clearly I'm not 
>>>> qualified to properly defend the validity of this idea.
>>>
>>> There is prior art, by the truckload. A /very/ short slide show here: 
>>> http://zope.stackless.com/StacklessEuroPy.ppt
>>>
>>> I'd kill to get that in D.
>>
>> Interesting, just you can't claim you were talking about that all 
>> along. I mean, come on! You say one thing that was untenable, and now 
>> you come up with a different one that is. And you were right all along?
> 
> I was actually talking about *two* things. If you remember, I was 
> talking about measuring actually used stack depth. Then I got the idea 
> of having separate stacks for threads. Two separate things in a post.

Threads already have separate stacks. (You might have said more.)

> (Now that I think more about it, I must have heard about stackless 
> Python somewhere. But as I've seen others do, this time I, too, believed 
> I invented something that I've actually seen somewhere.)

Fortran was stackless for... for a long time :o). An activation record 
in Fotran is in static memory. To call a Fortran function, you deposit 
arguments in that static storage, issue the CALL, and wait.

>>> And about your comments on stack size, seems regular Python has an 
>>> in-built limit on recursion, at 1000 deep. That should be 
>>> diametrically opposite your stance on stack size.
>>
>> Python has apparently set a maximum to have a guarantee it won't crash 
>> when given a certain minimum stack size. That's nice, but I'm not 
>> quite seeing how that's opposite to what I said in this discussion.
> 
> Nope. It's because
> 
>  - They don't want the entire computer thrashing each time some idiot 
> has a typo in his recursive algorithm.
> 
>  - They genuinely don't think you usually need preposterous levels of 
> recursion. And if you do, then just change the limit.
> 
> Python is for Real Computers (as opposed to Windows). There it's polite 
> to make your apps (here, the Python interpreter) have some decency as to 
> how much resources they take. The idea is that there are hundreds of 
> other users, and dozens of daemons running critical apps, round the clock.
> 
> If developers didn't know (by measurement or analysis) the reasonable 
> stack size needed, there would be no mobile phones, no set-top boxes 
> with hard disks, no GPS receivers, no digital PBX appliances, no solid 
> state firewalls, no ADSL boxes, no programmable calculators......
> 
> Dammit, any pocket calculator that has parenthesis buttons needs a 
> stack. And that stack space is predermined by the manufacturer.
> 
> I'm still maintaining that the stack space needs of regular applications 
> are much less than people tend to think. Last time I checked, you ran 
> out of stack on a name brand calculator with just ten levels of 
> parentheses. That's not much. On the other hand, in real life, not too 
> many people in the world have ever seen a calculator run out of stack 
> space.

Sure, I'm not contending that. But that's a rather different claim than 
some others you made.


Andrei