3 ms·
This sounds like a bad idea. TCO is not just a perf difference. Once you add it to a language, you've changed the semantics. The same piece of code will throw
by mikedouglas 17y ago
This sounds like a bad idea.
TCO is not just a perf difference. Once you add it to a language, you've changed the semantics. The same piece of code will throw a StackOverflowException in DEBUG mode, yet functional perfectly in RELEASE. Scheme's spec requires TCO for this very reason.
- bad_user 17y agoSounds like a bad idea to me too ... but apparently X64 TCO on CLR 2 was considered an optimization, not something that changes the semantics ... so the DEBUG/RELEASE split has always been in there, and now it's a matter of backwards compatibility ... since it can change the stack-trace and in DEBUG-mode you expect the full trace.
- scott_s 17y agoYou and I have a different definition of "semantics" when it comes to programming languages. Your code still achieves the same result, just in a different way. That requirement - equivalent outcome - is how compilers decide what optimizations it can and can't perform. This is often stated as "optimizations can't change program semantics."
- bad_user 17y agoIf an optimization means that an algorithm reaches the desired result or not, that's not an optimization anymore. def fact(n, r=1): if n == 1: return r return fact(n-1, r * n) Regardless of any available stack-space you may have, for the above method (which can be tail-call optimized) try calculating fact(1000000). If that's the requirement, then without TCO this implementation is incorrect.
- eru 17y agoIndeed. Though you have to exclude preservation of timing (and memory usage) effects from your definition of semantics to make any optimization possible.
- CWuestefeld 17y agoI don't think that they're talking about adding this at the language level. Nothing is changing in the C# spec for this, for example. This is just talking about the kinds of code that the optimizer and JITter are allowed to generate on the back end.
- Gobiner 17y agoIf you think a feature that could potentially behave differently in RELEASE and DEBUG modes is problematic, you'll want to avoid floats and doubles in .NET. Runtime optimizations that do calculations in the processor's 80-bit FPU can alter the results of float/double calculations. My personal example: http://stackoverflow.com/questions/2225503/clr-jit-optimizations-violates-causality http://stackoverflow.com/questions/2225503/clr-jit-optimizat...
- pcarmichael 17y agoIf you want identical results regardless of optimization level or machine characteristics, you should really be using fixed-point instead.