Tail-call optimization/elimination was brought up in several threads like this one in discourse and this one in GitHub . The main interest seems to be purely based on the nice-to-have performance benefit and the core devs seem to be open to the change while assigning very low priority because writing…

[image] tkf: Does such optimization make sense? Would it be useful? Is it implementable in more general cases that the compiler has to handle? I think you bring up a very important issue. I find that avoiding or minimizing calculations on types is the key to writing performant and idiomatic J…

[image] Tamas_Papp: all that this pattern requires is that type changes always break out into another function, regardless of their position The observation I wanted to emphasize was that this does not work (i.e., overflows the stack) if you apply this to the function that has to break out in…

[image] tkf: this does not work (i.e., overflows the stack) if you apply this to the function that has to break out in the middle of the loop and the way that the loop body changes the type is non-monotonic Ideally the number of times you have to do this is limited, and 0 for type stable code…

I get that the example using Val was contrived. I wanted to give a very simple demonstration. Here is less contrived example that still throws a StackOverflowError badthreshold(::Any, x) = if x > 1 missing elseif x > 0 x else 0 end xs = [-1, 0.5, 2][mod1.(1…

[image] tkf: I don’t think it is crazy to assume that acc may change type every few steps with some non type stable functions provided by users. I don’t think it is crazy either. But neither I am convinced that Julia should strive to support programming styles like this, given the cost (in te…

[image] Tamas_Papp: the right solution is to just bail to dynamic dispatch and emit “suboptimal” code Usually, you have to opt-out suboptimal code with many Anys to make your code faster. The problem here is unique because you have to opt-in suboptimal code. I think automatically degrading …

I just find that Guy Steele is discussing something very similar in the first half of this talk: [Keynote with Guy Steele]

Just want to chime in that, though I can’t contribute much to this thread, I have enjoyed reading it very much. TCO is relevant to my interests. Very interesting conversation!

Just also chiming in that if TCO is enabled, in a language with macros you will immediately start seeing abstractions that rely on translating to CPS and making use of it (not necessarily a bad thing and the fact that we have green threads in the language already makes it less likely to be “abused” …

[image] Olof_Salberger: a trampoline macro That’s actually the next thing I wanted to look at. When combined with Union splitting, I was thinking that it may compile to the code as good as function-barrier (or something that is good enough). But this probably still is sub-optimal compared t…

Tail-call optimization and function-barrier -based accumulation in loops

Internals & Design

anon92994695 January 15, 2021, 11:57pm 12

Has there been any lift in this area? I mean, it maybe is a lot of work, but - lots of algorithms are so easy to express recursively.

Topic		Replies	Views
Tail-call recursion Performance	41	4547	December 15, 2022
[RFC/ANN] FLoops.jl: fast generic for loops (foldl for humans™) Package Announcements	42	8767	April 29, 2020
Recursive call vs while loop Performance recursion	21	12461	April 12, 2022
Performance comparison, Julia is a slower than Mojo, am I doing something wrong? Performance question , mojo	44	8479	September 28, 2023
Yet another TCO thread Performance recursion	5	2454	May 25, 2022

Tail-call optimization and function-barrier -based accumulation in loops

Related topics