Có thể bỏ qua chi phí của GC khi phân tích thời gian chạy của các cấu trúc dữ liệu trong trường hợp xấu nhất được chỉ định trong ngôn ngữ lập trình được thu gom rác không?


22

Tôi chỉ nhận ra rằng tôi đã giả sử câu trả lời cho câu hỏi của mình là "có" nhưng tôi không có lý do chính đáng. Tôi tưởng tượng rằng có thể có một người thu gom rác chỉ giới thiệu chậm lại trường hợp xấu nhất . Có một tài liệu tham khảo dứt khoát tôi có thể trích dẫn? Trong trường hợp của tôi, tôi đang làm việc trên một cấu trúc dữ liệu hoàn toàn chức năng và tôi sử dụng ML chuẩn, nếu những chi tiết này quan trọng.Ôi(1)

Và có lẽ câu hỏi này sẽ còn phù hợp hơn nữa khi được áp dụng cho các cấu trúc dữ liệu được chỉ định trong, giả sử, Java? Có lẽ có một số cuộc thảo luận có liên quan trong các sách giáo khoa thuật toán / cấu trúc dữ liệu sử dụng Java? (Tôi biết Sedgewick có phiên bản Java, nhưng tôi chỉ có quyền truy cập vào phiên bản C.)

Câu trả lời:


17

Có, gc được khấu hao thời gian không đổi. Giả sử bạn có một thuật toán chạy trong thời gian với một tập hợp kích thước cực đại k . Bây giờ, lưu ý rằng bạn có thể phân bổ tối đa các từ O ( n ) trong khi thực hiện chương trình và chi phí thời gian để chạy bộ thu gom rác sao chép là O ( k ) (nghĩa là chi phí của một gc tỷ lệ thuận với tổng lượng dữ liệu trực tiếp). Vì vậy, nếu bạn chạy gc nhiều nhất là O ( n / k ) , thì tổng chi phí thời gian chạy bị giới hạn bởi O ( n )nkÔi(n)Ôi(k)Ôi(n/k)Ôi(n), có nghĩa là chi phí khấu hao của gc là không đổi. Vì vậy, nếu bạn có bộ sưu tập kiểu Cheney, với mỗi bán kết có kích thước , thì bạn sẽ dễ dàng thấy rằng một bộ sưu tập đầy đủ không thể được gọi nhiều hơn một lần mỗi n / k , vì việc phân bổ k từ sẽ mất O ( k ) thời gian và bộ làm việc không bao giờ vượt quá kích thước k , điều này mang lại cho bạn ràng buộc mà bạn muốn. Điều này biện minh cho việc bỏ qua các vấn đề gc.2kn/kkÔi(k)k

Tuy nhiên, một trường hợp mà sự hiện diện hay vắng mặt của gc không thể bỏ qua là khi viết cấu trúc dữ liệu không khóa. Nhiều cấu trúc dữ liệu không khóa hiện đại cố tình rò rỉ bộ nhớ và dựa vào gc cho chính xác. Điều này là do ở cấp độ cao, cách họ làm việc là sao chép một số dữ liệu, thay đổi dữ liệu và cố gắng cập nhật nguyên tử bằng lệnh CAS và chạy vòng lặp này cho đến khi CAS thành công. Việc thêm sự phân bổ xác định vào các thuật toán này làm cho chúng phức tạp hơn nhiều và vì vậy mọi người thường không bận tâm (đặc biệt vì chúng thường được nhắm mục tiêu vào các môi trường giống như Java).

EDIT: Nếu bạn muốn giới hạn không được khấu hao, nhà sưu tập Cheney sẽ không làm điều đó - nó sẽ quét toàn bộ thiết lập trực tiếp mỗi khi nó được gọi. Từ khóa để google cho là "bộ sưu tập rác thời gian thực" và Djikstra et al. và Steele đã cho các nhà sưu tập đánh dấu và quét thời gian thực đầu tiên, và Baker đã cho gc nén thời gian thực đầu tiên.

@article {dijkstra1978fly,
  title = {{Bộ sưu tập rác trên đường bay: Một bài tập hợp tác}},
  tác giả = {Dijkstra, EW và Lamport, L. và Martin, AJ và Scholten, CS và Steffens, EFM},
  tạp chí = {Truyền thông của ACM},
  khối lượng = {21},
  số = {11},
  trang = {966--975},
  hiệnn = {0001-0782},
  năm = {1978},
  nhà xuất bản = {ACM}
}

@article {Steele1975multiprocessing,
  title = {{Đa xử lý thu gom rác}},
  tác giả = {Steele Jr, GL},
  tạp chí = {Truyền thông của ACM},
  khối lượng = {18},
  số = {9},
  trang = {495--508},
  hiệnn = {0001-0782},
  năm = {1975},
  nhà xuất bản = {ACM}
}

@article {baker1978list,
  title = {{Xử lý danh sách theo thời gian thực trên máy tính nối tiếp}},
  tác giả = {Baker Jr, HG},
  tạp chí = {Truyền thông của ACM},
  khối lượng = {21},
  số = {4},
  trang = {280--294},
  hiệnn = {0001-0782},
  năm = {1978},
  nhà xuất bản = {ACM}
}

mộtbmộtb

1
"Có, gc được khấu hao theo thời gian không đổi". Điều này không đúng nói chung. Bạn có thể lập luận rằng GC thể nhưng chúng không nhất thiết và thực tế thì không. Ví dụ, sự ngây thơ List.maptrong OCaml thực sự là phức tạp bậc hai vì độ sâu của ngăn xếp là tuyến tính và ngăn xếp được dịch chuyển mỗi khi vườn ươm được sơ tán. Tương tự như vậy đối với các lát cắt lớn gặp phải các mảng lớn của con trỏ.
Jon Harrop

12

Ôi(n)

Ôi(1)

Tham chiếu bộ sưu tập rác dứt khoát là:

  • Bộ sưu tập rác của Richard Jones và Rafael Lin

Ben Zorn đã thực hiện một số công việc đo lường chi phí thực tế của các thuật toán thu gom rác khác nhau, mặc dù sau đây là bài báo gần đây trình bày một so sánh toàn diện hơn nhiều:

Để xem thêm:

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.