Makarius wrote:
It might be possible to chain together stacks to increase the maximum stack size but there are a couple of problems that would need to be addressed. Maybe it's something to think about for version 5.2.
Using reasonably large stacks and multiple threads already works quite well in the forthcoming 5.1 version (i.e. the current CVS of Poly/ML). My impression is that for present day commodity hardware the total CPU utilization is as high as 75-85% (4 cores) or 60-70% (8 cores). So maybe you only need to worry after 1-2 more years :-)
How would increased memory bandwidth work in the poly runtime system? Stacks are already local to each thread, and chaining them in smaller pieces might give a small improvement. On the other hand, I'd guess that there is more potential for tuning heap access, maybe by giving each thread a local view on the mutable area?
I don't really understand what you're getting at. With the current fixed upper limit on a stack size if a function recurses deeply enough it will eventually hit the limit and raise an exception. Indeed that may be more likely to happen with newer versions of Poly/ML where the maximum heap is larger. It is easier to create very large lists and so deeper recursion is more likely.
David