AR
после каких "компилируемых языков"?
Size: a a a
2020 May 25
AB
быстрее обычной рекурсии
AB
вот статья и обсуждение. вдруг будет интересно
https://elixirforum.com/t/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/880
https://pragtob.wordpress.com/2016/06/16/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/
https://elixirforum.com/t/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/880
https://pragtob.wordpress.com/2016/06/16/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/
ŹR
Помоему интуитивно обычная рекурсия гораздо быстрее, но там может закончится стэк
LL
в приведенной ссылке (https://erlang.org/pipermail/erlang-questions/2016-October/090663.html) Joe сравнивает термины Tail recustion с Last Call Optiomization. В чем отличие от общеупотребительного TCO я так и не понял, так что зачем он изобрел свою терминологию тоже не оч понятно )
Last call optimization - это когда после исполнения последней функции, goto происходит не в тело функции которая её вызывала, а в тело следующей функцииTail recursion optimization - это когда последняя инструкция функции - это вызов себя же и это оптимизируется в классический циклAB
Помоему интуитивно обычная рекурсия гораздо быстрее, но там может закончится стэк
не знаю. мне интуитивно быстрее, когда оптимизатор меняет call на jmp
ŹR
не знаю. мне интуитивно быстрее, когда оптимизатор меняет call на jmp
Интуитивно быстрее - когда нету аккумулятора. Что там в кишках меняется - это не про интуицию
ŹR
Last call optimization - это когда после исполнения последней функции, goto происходит не в тело функции которая её вызывала, а в тело следующей функцииTail recursion optimization - это когда последняя инструкция функции - это вызов себя же и это оптимизируется в классический циклСудя по всему ты не прав. Следует отличать tail call от tail recursion
AB
Ну буквоедство. Кому как. Субъективно, как выясняется.
LL
Судя по всему ты не прав. Следует отличать tail call от tail recursion
Да, опечатка)
ŹR
Тока фишка в том, что по английски всегда говорят TCO, а вот по русски - оптимизация хвостовой рекурсии
ŹR
И это просто ебучий парадокс.
Например в Википедии
https://en.wikipedia.org/wiki/Tail_call
Все четко - меняем call на jmp
Например в Википедии
https://en.wikipedia.org/wiki/Tail_call
Все четко - меняем call на jmp
ŹR
Нажимаем на русскиу версию - и куда попадаем? А хуй его знает
ŹR
ŹR
Судя по всему это просто специфика перевода
AR
вот статья и обсуждение. вдруг будет интересно
https://elixirforum.com/t/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/880
https://pragtob.wordpress.com/2016/06/16/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/
https://elixirforum.com/t/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/880
https://pragtob.wordpress.com/2016/06/16/tail-call-optimization-in-elixir-erlang-not-as-efficient-and-important-as-you-probably-think/
> edit11: It was pointed out in the comments that the performance characteristics might differ for larger lists. And it does, taking 1000 times as many elements (10_000_000) all tail-recursive versions are significantly faster than the body-recursive version (and even the stdlib version).
AR
ну т.е. когда размер становится приличным, таки быстрее )
AR
ну и там пример такой конечно взят, оч неудобный для TCO
AR
def map_body([], _func), do: []
def map_body([head | tail], func) do
[func.(head) | map_body(tail, func)]
end
AR
в кложе, например, такое пишется без TCO и при этом не жрется стэк — на ленивых коллекциях