6 ms·
No program beyond the most trivial will meet these requirements. The moment you call any function indirectly you lose.
by pcwalton 10y ago
No program beyond the most trivial will meet these requirements. The moment you call any function indirectly you lose.
- mindslight 10y agoYes, but indirectly means "&Fn", but not "&F where F: Fn". And a whole program doesn't need to conform, only individual threads. Presumably the ones you want to make a lot of. (And if a little dynamicism was required, its expense could be paid for at the use, by creating a fresh necessary-sized stack at that point. But I'm probably opening up old split-stack wounds, sorry)
- jroesch 10y agoThe problem with an optimization like this is that the current approach always gives you a guarantee on runtime cost. Heuristic based optimizations make performance harder to ensure, not to mention recovering performance when you fall outside the valid subset much more difficult. You can obviously provide another static analysis to warn you about violations, but this seems is more complex, and less flexible then the current approach.
- mindslight 10y agoActually the "current approach" gives you no bound on the stack size. You guess, hope, and test (or do this analysis manually). While your general objection is good to always keep in mind, it is a tradeoff. There is no perfect solution when you're up against the halting problem (unless you're proposing to change the language to only bounded recursion). What I'm arguing for here is for more than the single problem the OP is solving, so it's not a case of choosing one or the other and calling it a day.