Trình biên dịch có thể và chuyển đổi logic đệ quy thành logic không đệ quy tương đương không?

Tôi đã học F # và nó bắt đầu ảnh hưởng đến suy nghĩ của tôi khi tôi lập trình C #. Cuối cùng, tôi đã sử dụng đệ quy khi tôi cảm thấy kết quả cải thiện khả năng đọc và tôi không thể hình dung được nó đang cuộn ra thành một chồng tràn.

Điều này dẫn tôi đến việc liệu trình biên dịch có thể tự động chuyển đổi các hàm đệ quy thành một dạng không đệ quy tương đương hay không?

Có, một số ngôn ngữ và trình biên dịch sẽ chuyển đổi logic đệ quy thành logic không đệ quy. Điều này được gọi là tối ưu hóa cuộc gọi đuôi - lưu ý rằng không phải tất cả các cuộc gọi đệ quy đều được tối ưu hóa cuộc gọi đuôi. Trong tình huống này, trình biên dịch nhận ra một hàm có dạng:

int foo(n) {
  ...
  return bar(n);
}

Ở đây, ngôn ngữ có thể nhận ra rằng kết quả được trả về là kết quả từ một hàm khác và thay đổi một lệnh gọi hàm với khung ngăn xếp mới thành một bước nhảy.

Nhận ra rằng phương pháp giai thừa cổ điển:

int factorial(n) {
  if(n == 0) return 1;
  if(n == 1) return 1;
  return n * factorial(n - 1);
}

không phải là cuộc gọi đuôi tối ưu vì kiểm tra cần thiết trên trở lại.

Để thực hiện cuộc gọi đuôi này tối ưu hóa,

int _fact(int n, int acc) {
    if(n == 1) return acc;
    return _fact(n - 1, acc * n);
}

int factorial(int n) {
    if(n == 0) return 1;
    return _fact(n, 1);
}

Biên dịch mã này với gcc -O2 -S fact.c(-O2 là cần thiết để cho phép tối ưu hóa trong trình biên dịch, nhưng với tối ưu hóa nhiều hơn -O3, con người khó đọc được ...)

_fact:
.LFB0:
        .cfi_startproc
        cmpl    $1, %edi
        movl    %esi, %eax
        je      .L2
        .p2align 4,,10
        .p2align 3
.L4:
        imull   %edi, %eax
        subl    $1, %edi
        cmpl    $1, %edi
        jne     .L4
.L2:
        rep
        ret
        .cfi_endproc

Người ta có thể thấy trong phân đoạn .L4, jnethay vì một call(gọi một chương trình con với khung ngăn xếp mới).

Xin lưu ý rằng điều này đã được thực hiện với C. Tối ưu hóa cuộc gọi đuôi trong java rất khó và phụ thuộc vào việc triển khai JVM - đệ quy đuôi + java và đệ quy đuôi + tối ưu hóa là các bộ thẻ tốt để duyệt. Bạn có thể thấy các ngôn ngữ JVM khác có thể tối ưu hóa đệ quy đuôi tốt hơn (thử clojure (yêu cầu recur để tối ưu hóa cuộc gọi đuôi) hoặc scala).

Bước đi cẩn thận.

Câu trả lời là có, nhưng không phải lúc nào cũng vậy, và không phải tất cả chúng. Đây là một kỹ thuật có một vài tên khác nhau, nhưng bạn có thể tìm thấy một số thông tin khá dứt khoát ở đây và tại wikipedia .

Tôi thích cái tên "Tối ưu hóa cuộc gọi đuôi" nhưng có những người khác và một số người sẽ nhầm lẫn giữa thuật ngữ này.

Điều đó nói rằng có một vài điều quan trọng để nhận ra:

• Để tối ưu hóa cuộc gọi đuôi, cuộc gọi đuôi yêu cầu các tham số được biết tại thời điểm cuộc gọi được thực hiện. Điều đó có nghĩa là nếu một trong các tham số là một lệnh gọi đến hàm, thì nó không thể được chuyển đổi thành một vòng lặp, bởi vì điều này sẽ yêu cầu lồng tùy ý của vòng lặp đã nói mà không thể mở rộng tại thời gian biên dịch.

• C # không đáng tin cậy tối ưu hóa các cuộc gọi đuôi. IL có hướng dẫn để làm như vậy trình biên dịch F # sẽ phát ra, nhưng trình biên dịch C # sẽ phát ra nó không nhất quán và tùy thuộc vào tình huống JIT, JIT có thể hoặc không thể làm điều đó. Tất cả các dấu hiệu cho thấy bạn không nên dựa vào các cuộc gọi đuôi của mình được tối ưu hóa trong C #, nguy cơ tràn vào khi làm như vậy là rất quan trọng và có thật