[ Just a few rushed little comments ]

Thanks!

we don't know the range.

would require lock-stepping the threading-

with the minimal effort required for each step

I reached the same conclusions.

it requires that it has multiple, independant, recursive calls at each level.

That's why I used fib at first and called Ackermann a whole other ball game.

The interesting thing now is: how many recursive algorithms fit that pattern?

Any divide and conquer algorithm, for starters. That's where the dependency graph came in. I wanted to see if there was a split in it that could be exploited.

wonder why you do a loop initialisation rather than

I didn't know what I was going to end up with when I started. The code got refactored multiple times. I didn't micro-optimise.

(Upd: Put differently, the snippet is a theoretical implementation, not a practical one. Work still needs to be done to make it practical. Well, as practical as Ackermann can be. )

why for(;;) not while( 1 )?

It's what the code I learned from used. I've never used while (1). I like for (;;) cause I read it as "for ever". Trivia: Since the entire bound check of while (CONSTANT) gets optimised away, and since "while" and C-style "for" use the same opcodes, while (1) and for (;;) are practically identical internally.