AB
Есть «оптимизация хвостовой рекурсии», когда она превращается в цикл
это и есть tco
Size: a a a
2020 August 27
ŹR
это и есть tco
Нет
ŹR
Это разные вещи
Е
tco либо есть, либо её нет, нет никакой оптимальности
нет никакой "оптимизации обычной рекурсии", только tco
нет никакой "оптимизации обычной рекурсии", только tco
незнаю как в BEAM, а компилируемые языки могут и нехвостовую рекурсию в некоторых случаях в цикл оптимизировать.
AB
тогда что же такое tco, если не tail call optimization?
ŹR
тогда что же такое tco, если не tail call optimization?
TCO это rail call optimisation, НО НЕ tail recursion optimisation
Е
А tco это про jmp вместо call
ну так оно взаимосвязано. beam гарантирует, что для хвостовой рекурсии TCO будет обязательно выполнено, не вижу смысла разделять в данном контексте эти понятия.
AB
TCO это rail call optimisation, НО НЕ tail recursion optimisation
так tail recursion это и есть рекурсия, попадающая под tco
ŹR
ну так оно взаимосвязано. beam гарантирует, что для хвостовой рекурсии TCO будет обязательно выполнено, не вижу смысла разделять в данном контексте эти понятия.
Так в бим нету оптимизации рекурсии
ŹR
Бим оптимизирует last call
Е
Бим оптимизирует last call
он же tail call
ŹR
Е
Ну так я не понимаю о чем ты говоришь? Tail Call Recursion - это и есть хвостовая рекурсия, котора в BEAM гарантировано будет оптимизирована.
ŹR
Естественно будет. Только с чего ты решил, что она будет быстрее обычной?
PG
дык было же обсуждение, что Tail Call Optimization и Tail Recursion Optimization это разные вещи, и TCO более общая
Е
Естественно будет. Только с чего ты решил, что она будет быстрее обычной?
хотя бы потому что обычно безусловный переход быстрее вызова процедуры
Е
Мы тыт обсуждаем TCO исключительно по отношению к оптимиации хвостовой рекурсии
ŹR
хотя бы потому что обычно безусловный переход быстрее вызова процедуры
Тока вызов процедуры добавляет тебе «аккумулятор» на уровне ВМ, а переписывание функции в хвостовую рекурсию заставляет тебя добавлять аккумулятор на высоком уровне самого языка
Е
Тока вызов процедуры добавляет тебе «аккумулятор» на уровне ВМ, а переписывание функции в хвостовую рекурсию заставляет тебя добавлять аккумулятор на высоком уровне самого языка
Компиляторы такие вещи запросто оптимизируют, видимо в BEAM не так, или не всегда так
ŹR
Поэтому то и не оптимизируют, что нету tro, а есть tco