Thông báo của Steering Council về dự án JIT

 (discuss.python.org)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trình biên dịch JIT thử nghiệm của CPython đã được phát triển trong nhánh main suốt nhiều năm và gần đây cho thấy cải thiện hiệu năng thực tế, nhưng để tiếp tục là một tính năng được hỗ trợ thì vẫn cần quy trình xem xét PEP chính thức
  • PEP 744 đề cập đến thiết kế ban đầu và các tiêu chí để chuyển thành tính năng lâu dài, nhưng vẫn chưa đạt được đồng thuận về người bảo trì dài hạn, rà soát bảo mật, hỗ trợ gỡ lỗi và công cụ xử lý bên ngoài, bảo đảm thời gian chạy, cũng như nghĩa vụ của các đơn vị tái phân phối và nhà đóng gói downstream
  • Python Steering Council đã chính thức yêu cầu soạn một Standards Track PEP để đưa JIT trở thành tính năng không còn mang tính thử nghiệm nhưng được hỗ trợ của CPython, đồng thời yêu cầu tạm dừng đưa các tính năng mới, tối ưu hóa và công việc hiệu năng vào nhánh main cho đến khi PEP được chấp nhận
  • PEP mới phải đề cập đến việc bảo trì dài hạn, khả năng tương thích với các tính năng và công cụ CPython hiện có, các chỉ số thành công có thể đo lường cùng lịch trình, mối quan hệ với các JIT bên thứ ba như CinderX·Numba·PyTorch, và mức độ ổn định của kiến trúc hiện tại
  • Nếu PEP không được nộp, giải quyết hoặc chấp nhận trong vòng 6 tháng thì mã JIT sẽ bị gỡ khỏi nhánh main và việc phát triển phải tiếp tục bên ngoài kho mã Python main

Bối cảnh và yêu cầu chính thức

  • Trình biên dịch Just-In-Time thử nghiệm của CPython là nỗ lực đã được nhiều core developer và cộng tác viên phát triển trong nhánh main suốt vài năm qua, và các cải thiện hiệu năng gần đây là kết quả thực tế và đáng khích lệ
  • Động thái này không phải là chỉ trích đối với công việc JIT hay những người tham gia, mà là nhận định rằng đã đến lúc đánh giá lại vị thế không chính thức của JIT trong dự án CPython vì dự án đã kéo dài lâu và trải qua nhiều lần thiết kế lại
  • JIT được đưa vào main ban đầu dưới dạng thử nghiệm, và PEP liên quan là PEP 744 thuộc loại Informational PEP
  • PEP 744 đề cập đến thiết kế ban đầu và phác thảo các tiêu chí để JIT có thể trở thành tính năng lâu dài, nhưng vẫn để ngỏ các câu hỏi như người bảo trì dài hạn, rà soát bảo mật, hỗ trợ gỡ lỗi và công cụ xử lý bên ngoài, bảo đảm thời gian chạy, cùng nghĩa vụ của các đơn vị tái phân phối và nhà đóng gói downstream
  • Python Steering Council cho rằng một thay đổi có mức độ phức tạp và phạm vi như vậy lẽ ra cần quy trình chặt chẽ hơn, và các câu hỏi chưa được giải quyết đó là những cam kết mà cộng đồng cần xem xét và đi đến đồng thuận thông qua quy trình PEP
  • Để biến JIT thành tính năng không còn thử nghiệm nhưng được hỗ trợ của CPython, cần có một Standards Track PEP bao quát cả các bảo đảm, cam kết bảo trì và tác động đến các đơn vị tái phân phối, cùng với quy trình chấp nhận hoặc bác bỏ chính thức của Steering Council sau khi cộng đồng thảo luận
  • Cho đến khi PEP đó được chấp nhận, không nên đưa hoạt động phát triển JIT mới vào nhánh main; các tính năng mới, tối ưu hóa và công việc hiệu năng đều thuộc diện tạm dừng
  • Các bản sửa lỗi và vá bảo mật vẫn có thể tiếp tục; phạm vi của yêu cầu tạm dừng chỉ giới hạn ở việc đưa thêm tính năng JIT vào trước khi PEP được chấp nhận

Các vấn đề PEP phải xử lý và mốc thời gian 6 tháng

  • Mục đích không phải là yêu cầu các đề xuất cạnh tranh, nhưng hiện tại cũng là thời điểm phù hợp để thảo luận các phương án thay thế, và điều này cũng phù hợp với quan điểm trước đây rằng không nên tiến hành thử nghiệm trong nhánh main của CPython nếu không có PEP
  • Thay vì đề xuất một triển khai JIT đơn lẻ, có thể một PEP mô tả hạ tầng JIT có khả năng hỗ trợ nhiều chiến lược triển khai sẽ phù hợp hơn
  • Vì nhiều cách tiếp cận JIT tracing đầy hứa hẹn vẫn đang tiếp tục được đề xuất, hạ tầng này không nên bị gắn chặt vào một chiến lược duy nhất mà cần cho phép việc thử nghiệm và đánh giá các cách tiếp cận như vậy trong CPython một cách dễ dàng
  • PEP phải đưa ra kế hoạch rõ ràng về cách duy trì và bảo trì lâu dài một hệ thống con có quy mô và độ phức tạp như vậy, cũng như tác động của nó đối với các maintainer và cộng tác viên không trực tiếp đóng góp cho JIT
  • PEP phải đề cập đến khả năng tương thích với các tính năng và công cụ CPython hiện có, đồng thời xử lý rộng và chi tiết các tương tác cũng như bảo đảm giữa JIT với những tính năng như free-threading, profiler và debugger
  • PEP phải bao gồm các chỉ số thành công rõ ràng, có thể đo lường và một lịch trình cụ thể, đề cập đến các mục tiêu và mốc thời gian như mục tiêu hiệu năng, phạm vi hỗ trợ nền tảng và chi phí bộ nhớ phát sinh
  • PEP phải đề cập đến mối quan hệ với các trình biên dịch JIT khác, làm rõ liệu đây có phải là thiết kế cung cấp hạ tầng chung để các nỗ lực khác có thể dựa vào hay không, và liệu có dự kiến tương thích hay không tương thích với các JIT bên thứ ba như CinderX, Numba, PyTorch hay không
  • PEP phải đề cập đến việc liệu kiến trúc JIT hiện tại có được xem là ổn định hay vẫn còn nhiều khả năng tiếp tục thay đổi
  • Danh sách này không phải là đầy đủ, và có thể sẽ có thêm các vấn đề khác khi thảo luận trong cộng đồng tiếp tục diễn ra
  • Mốc thời gian 6 tháng được đặt ra cho việc nộp và giải quyết PEP; nếu PEP đó không được chấp nhận trong thời hạn này thì mã JIT sẽ bị gỡ khỏi nhánh main và việc phát triển phải tiếp tục bên ngoài kho mã Python main
  • Yêu cầu này không phải là chấm dứt dự án, mà là một quy trình nhằm tạo ra sự rõ ràng cần thiết và cam kết minh thị từ cộng đồng đối với một thay đổi lớn của runtime CPython

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Lobste.rs

  • Có vẻ không quá căng thẳng, nhưng hơi gượng gạo một chút. Nếu JIT vẫn là tính năng thử nghiệm thì bản thân việc tiếp tục hợp nhất có vẻ không phải vấn đề
    Nếu những người như Shannon nói rằng “chúng tôi sẽ mang PEP tới, nhưng xin hãy tránh những va chạm khó xử”, thì tôi cảm thấy có thể tin tưởng họ đến mức không cần phải áp dụng một khóa cứng để ngăn tiến triển thêm. Có thể tuyên bố công khai này được đưa ra sau các cuộc trao đổi riêng, nhưng tôi hy vọng mọi chuyện sẽ diễn ra suôn sẻ mà không gây tổn thương không cần thiết

  • Đề xuất một giao diện cho phép các triển khai JIT khác nhau dường như đã hiểu sai khá nhiều về những gì một JIT hiệu năng cao cần có. Hẳn là nhóm làm JIT đã có nhiều vấn đề, nhưng một trong những vấn đề lớn có vẻ là họ đã không thể hoặc không muốn thay đổi mạnh các cấu trúc dữ liệu runtime cốt lõi
    Tất nhiên Python cũng có vấn đề là trên thực tế đã phơi bày gần như toàn bộ triển khai như thể đó là API. Dù vậy, nếu ai đó làm điều không ổn thì vẫn có thể buộc họ viết lại các kiểu, nhưng để làm vậy thì cần một cộng đồng thực sự coi trọng hiệu năng. Trong lịch sử, Python đã tồn tại bằng cách không viết các thư viện cần hiệu năng bằng Python, và điều đó đã ảnh hưởng đến mức độ ưu tiên. Tôi còn nhớ trước đây trong các so sánh hiệu năng ngôn ngữ, người ta đem các cài đặt thuật toán cơ bản ra so với các cài đặt Python mà thực chất chỉ bọc quanh những cài đặt hiệu năng cao, được tinh chỉnh kỹ trong thư viện C

    • Đề xuất giao diện JIT có vẻ lấy cảm hứng từ Ruby, và trong Ruby thì nó có vẻ hoạt động khá tốt. Vì thế có thể Ruby không có JIT siêu hiệu năng, nhưng như vậy cũng có thể là đủ tốt. Nếu JIT của Python chỉ cần hoạt động ngang mức JIT của Ruby thì có lẽ nhiều người cũng sẽ hài lòng

    • Tôi không rõ vì sao câu “đề xuất một giao diện cho phép các triển khai JIT khác nhau đã hiểu sai khá nhiều về những gì cần cho một JIT hiệu năng cao” lại đúng
      Như bạn nói, Python đúng là đang phơi bày triển khai như API, nhưng vì lý do đó mà JIT cũng đang gọi các API đó. Trên thực tế, một số hàm còn được JIT cần đến nên đã được lộ ra thành symbol công khai cho linker. Cá nhân tôi đang làm method JIT chứ không phải tracing JIT, và từ trước đến nay vẫn công khai ủng hộ ý tưởng JIT dạng cắm thêm

  • Tôi tự hỏi vì sao việc này lại được đăng thành tuyên bố công khai thay vì gửi dưới dạng yêu cầu riêng cho các nhà phát triển JIT cốt lõi

    • Vì Python là một dự án mã nguồn mở do cộng đồng dẫn dắt. Ngay cả ở các dự án độc quyền, những thông báo tương tự cũng từng bị rò rỉ

  • Có lẽ một nhà nhân học nào đó nên viết một cuốn sách về bộ máy quan liêu trong các dự án phần mềm mã nguồn mở, và Python cùng Debian nên là đối tượng nghiên cứu trọng tâm
    Đây không phải lời chỉ trích. Kiểu quan liêu này rốt cuộc là quá trình ra quyết định phân tán và hình thành đồng thuận, và để nó vận hành tốt ở quy mô như thế này là điều khó khăn

    • Gabriella Coleman là một nhà nhân học đã nghiên cứu thực địa về Debian. Cuốn sách ra đời từ đó là “Coding Freedom” và tôi rất khuyến nghị

  • Thành thật mà nói, nó trông giống hội chứng từng dẫn đến Python 3, nhưng cho ra hiệu ứng ngược lại. CPython dường như chủ yếu tồn tại vì niềm vui của những người triển khai, và thay đổi này có vẻ sẽ gây khá nhiều bất tiện cho những người đã quen hack theo cách hiện tại
    Có lẽ hướng đi đúng là tài trợ cho phiên bản JIT như một triển khai riêng biệt, cho phép thay đổi, còn khả năng tương thích với CPython gốc thì theo đuổi trên cơ sở cố gắng hết sức

    • Tôi không thực sự hiểu chính xác ý “giống hội chứng từng dẫn đến Python 3, nhưng cho ra hiệu ứng ngược lại” là gì
      Về phần “CPython chủ yếu tồn tại vì niềm vui của những người triển khai”, thì từ những tương tác hạn chế của tôi với SC và các core developer, ấn tượng của tôi lại là điều ngược lại. Nhìn chung họ có vẻ cam kết khá sâu sắc trong việc cân bằng một cách hợp lý giữa tiếp tục hỗ trợ cộng đồng hiện tại và vẫn tiến về phía trước