Dự án gỡ bỏ GIL và CPython nhanh hơn
(lwn.net)- Khi Python Steering Council bày tỏ ý định chấp nhận PEP 703, việc gỡ bỏ GIL khỏi CPython bước vào một quy trình theo từng giai đoạn kéo dài, từ bản build thử nghiệm đến chuyển sang chế độ mặc định
- Việc gỡ bỏ GIL có thể mở ra hiệu năng đa luồng, nhưng cũng có thể tạo ra chi phí đối với hiệu năng đơn luồng — vốn chiếm phần lớn hệ sinh thái hiện có — và khả năng tương thích với các phần mở rộng C
- Nhóm Faster CPython cho rằng trình thông dịch thích ứng chuyên biệt hóa dựa trên PEP 659 đang dựa vào GIL, nên trong môi trường no-GIL cần tính toán lại chiến lược tối ưu hóa và gánh nặng bảo trì
- Meta cho biết nếu PEP 703 được chấp nhận, họ sẽ đầu tư 3 engineer-years đến cuối năm 2025, còn Anaconda cam kết hỗ trợ công việc đóng gói như pip, cibuildwheel, conda-forge
- Quá trình chuyển đổi sẽ tránh kiểu đứt gãy như Python 2→3, và nếu sự hỗn loạn do no-GIL gây ra được đánh giá là lớn hơn lợi ích, nó có thể bị rút lại trước khi được tuyên bố là chế độ mặc định
Thảo luận gỡ bỏ GIL của Python lại trở nên sôi nổi
- Global Interpreter Lock (GIL) của Python tuần tự hóa quyền truy cập vào máy ảo trình thông dịch để mỗi lần chỉ một luồng được thực thi mã Python
- GIL, vốn ngăn cản cải thiện hiệu năng bằng cách tận dụng nhiều luồng, từ lâu thường được nhắc đến như một điểm yếu của Python
- Tháng 10/2021, Sam Gross công bố phiên bản chứng minh khái niệm Python no-GIL, nhưng sau sự quan tâm ban đầu, tiến triển trong hơn một năm khá hạn chế
- Sau đó, Python Steering Council công bố ý định chấp nhận tính năng no-GIL
- Sẽ mất thời gian trước khi nó có mặt trong bản phát hành thực tế
- Vẫn còn khả năng công việc này bị đảo ngược vào một thời điểm nào đó trong tương lai
- Sự hỗ trợ từ nhiều công ty làm tăng khả năng thành công
Căng thẳng giữa Faster CPython và hiệu năng đơn luồng
- Tại Python Language Summit 2022, Gross trình bày no-GIL fork và cố gắng đạt được sự đồng thuận ngầm cho việc tiếp tục công việc, nhưng do các tác động chi tiết chưa được biết đủ rõ nên không đạt được đồng thuận
- Cùng thời điểm đó, dự án Faster CPython đang tập trung cải thiện hiệu năng đơn luồng của trình thông dịch
- Mark Shannon viết PEP 659 “Specialized Adaptive Interpreter”, và một phần các thay đổi này đã được đưa vào Python 3.10 và 3.11
- Tại PyCon, Brandt Bucher của nhóm Faster CPython trình bày về các lệnh thích ứng, còn Shannon trình bày về cải tiến bố cục bộ nhớ và các kỹ thuật tối ưu hóa khác
- Do các chương trình Python hiện có hầu hết được viết theo kiểu đơn luồng vì GIL, cải thiện hiệu năng đơn luồng tác động trực tiếp đến hiệu năng cảm nhận được của toàn bộ hệ sinh thái Python
Đề xuất PEP 703 và những lo ngại ban đầu
- Tháng 1/2023, Łukasz Langa đăng phiên bản đầu tiên của PEP 703 “Making the Global Interpreter Lock Optional in CPython” do Gross viết
- Cùng với kỳ vọng dành cho no-GIL, các mô-đun mở rộng Python viết bằng C nổi lên như mối lo ngại chính
- GIL lâu nay đóng vai trò ngăn chặn nhiều vấn đề đồng thời trong mã mở rộng C
- Việc gỡ bỏ GIL có thể tạo ra lỗi mới trong phần mã đó
- Có sự đồng thuận rằng cần tránh một chuyển đổi kiểu flag day giống như khi chuyển từ Python 2 sang 3
- Quá trình chuyển đổi gỡ bỏ GIL phải hoạt động trơn tru cả với mã chưa sẵn sàng
- Shannon hỏi mức suy giảm hiệu năng có thể chấp nhận được với mã đơn luồng là bao nhiêu; ước tính trực tiếp của ông nằm trong khoảng 15~20%, và ông cho rằng con số này có thể lớn hơn tùy tác động đến PEP 659
- Eric Snow, với tư cách là người viết PEP 684 “Per-Interpreter GIL” và PEP 683 “Immortal Objects”, đăng một phân tích dài và cho rằng no-GIL và cách tiếp cận subinterpreter không nhất thiết xung đột
Chi phí và lợi ích đối với phần mở rộng C
- Gross trả lời rằng tác động đối với phần mở rộng C không hoàn toàn chỉ là tiêu cực
- PEP có đưa vào các trích dẫn về sự phức tạp mà những người bảo trì các phần mở rộng C API được dùng rộng rãi gặp phải khi làm việc để né GIL
- Zachary DeVito, core developer của PyTorch, cho biết trong vài tháng gần đây đã có ba lần ông dành nhiều hơn một bậc độ lớn thời gian để tìm cách né giới hạn của GIL so với thời gian giải quyết vấn đề thực tế
- no-GIL có thể tạo ra các vấn đề đồng thời mới cho người bảo trì mô-đun mở rộng, nhưng đồng thời cũng có thể giảm sự phức tạp cần thiết để tránh GIL
PEP được cập nhật và tranh luận về hiệu năng
- Đầu tháng 5/2023, Gross đăng bản triển khai PEP 703 dựa trên phiên bản phát triển Python 3.12 cùng PEP đã cập nhật
- Ngày 12/5, ông yêu cầu Steering Council đưa ra quyết định về PEP, nhưng trước khi có quyết định vẫn còn nhiều thảo luận hơn
- Ngày 2/6, Shannon đánh giá tác động hiệu năng của PEP và đưa ra phạm vi 11~30%, con số này đã gây tranh luận
- Shannon cho rằng trình thông dịch chuyên biệt hóa thích ứng phụ thuộc vào GIL, nên nếu no-GIL được chấp nhận thì cần thiết kế lại chiến lược tối ưu hóa
- Công sức dành cho thiết kế lại và triển khai sẽ không thể được dùng cho công việc tối ưu hóa thực tế
- Langa đăng các số liệu benchmark cho thấy tác động nhỏ hơn nhiều so với ước tính của Shannon, và các kết quả bổ sung gần với những gì Gross đã báo cáo trong PEP
Bài học từ chuyển đổi Python 2→3
- Guido van Rossum cho rằng nếu mã Python 2 và 3 có thể cùng tồn tại trong cùng một trình thông dịch thì điều đó đã giúp ích cho quá trình chuyển đổi
- Ông nhấn mạnh rằng nếu tiến hành no-GIL, các mô-đun mở rộng yêu cầu GIL cũng phải import được trong trình thông dịch no-GIL mà không cần công việc bổ sung
- Mã ứng dụng cũng không cần phải sửa đổi
- Mô-đun mở rộng cũng không cần phải sửa đổi
- Gregory P. Smith của Steering Council cho biết phạm vi tác động của PEP 703 rất lớn nên chưa sẵn sàng quyết định ngay
- Smith thừa nhận có nhu cầu, nhưng cho rằng cần xem xét toàn bộ hệ sinh thái và tìm cách chuyển đổi không phá vỡ thế giới
- Gross phản hồi rằng nếu trì hoãn quyết định mà không có tiêu chí chấp nhận và lịch trình rõ ràng thì trên thực tế nó hoạt động như một câu trả lời “không”
Ba lựa chọn theo góc nhìn của nhóm Faster CPython
- Trong thảo luận “A fast, free threading Python”, Shannon tóm tắt ba lựa chọn cho tương lai
- Theo đuổi trình thông dịch đơn luồng nhanh như kế hoạch hiện tại
- Theo đuổi trình thông dịch free-threading no-GIL có tác động không rõ nhưng không bằng 0 lên hiệu năng đơn luồng
- Theo đuổi cả hai cùng lúc
- Shannon cho rằng cần chọn sẽ hạn chế yếu tố nào trong hiệu năng, tính song song và tính khả biến
- Ông diễn đạt rằng điều này gần với “pick one to restrict” hơn là “Performance, parallelism, mutability: pick two”
- Ông cảnh báo rằng để làm Python nhanh trong môi trường free-threading cần nghiên cứu sáng tạo, với chi phí và rủi ro lớn hơn
- Phương án được ưa thích là lựa chọn thứ ba, nhưng ông cho rằng không nên chọn chỉ no-GIL rồi kỳ vọng “ai đó sẽ giải quyết vấn đề hiệu năng”
- van Rossum cũng cho rằng đạt được cả free threading và hiệu năng per-thread nhanh là điều tốt nhất, nhưng nhấn mạnh cần thêm tài nguyên
Hỗ trợ từ doanh nghiệp và ý kiến của core developer
- van Rossum cho biết Microsoft sẽ tiếp tục hỗ trợ nhóm Faster CPython, và vai trò của nhóm này không chỉ giới hạn ở công việc hiệu năng đơn luồng
- Ông nêu mục tiêu điều chỉnh công việc chuyên biệt hóa và tối ưu hóa cho phù hợp với thế giới no-GIL, cuối cùng biến no-GIL thành chế độ build duy nhất mà không làm giảm hiệu năng đơn luồng
- Carl Meyer của Meta cho biết nếu PEP 703 được chấp nhận, Meta sẽ đầu tư 3 engineer-years đến cuối năm 2025
- Các kỹ sư có kinh nghiệm với nội bộ CPython sẽ hợp tác với nhóm core dev
- Phản ánh bản triển khai PEP 703 vào CPython một cách trơn tru
- Tiếp tục cải thiện khả năng tương thích và hiệu năng của CPython no-GIL
- Stan Seibert của Anaconda cho biết sẽ hỗ trợ các vấn đề đóng gói phát sinh từ việc áp dụng PEP 703
- Bao gồm công việc liên quan đến pip, cibuildwheel, conda-forge
- Bao gồm các công việc cần thiết để chuyển các gói tương thích no-GIL đến cộng đồng Python
- Trong khảo sát core developer, 87% trong 46 người trả lời rằng nên tích cực thúc đẩy free-threaded Python, và 63% trong 38 người trả lời rằng họ sẵn sàng đóng góp vào việc hỗ trợ và bảo trì Python no-GIL dựa trên PEP 703
Quyết định của Steering Council và chuyển đổi theo giai đoạn
- Ngày 28/7, Thomas Wouters thông báo Steering Council đã quyết định chấp nhận PEP 703, nhưng chi tiết chấp nhận vẫn đang được làm rõ
- Cách tiếp cận là trước tiên đưa vào trình thông dịch no-GIL để xác định các phần còn thiếu, rồi lấp đầy công việc cần thiết trước khi no-GIL trở thành mặc định và cuối cùng là phiên bản duy nhất
- Thời gian chuyển đổi được ước tính khoảng 5 năm
- Council không muốn lặp lại tình huống như Python 3, và cho rằng các thay đổi mã bên thứ ba cần thiết để phù hợp với bản build no-GIL cũng phải hoạt động nguyên vẹn trên bản build with-GIL
- Trong ngắn hạn, có thể sẽ có bản build no-GIL thử nghiệm vào thời điểm Python 3.13
- Python 3.13 dự kiến vào tháng 10/2024
- Đây là bản build để core developer và những người khác có thể thử nghiệm
- Trong trung hạn, no-GIL sẽ trở thành một tùy chọn được hỗ trợ nhưng không phải mặc định
- Thời điểm phụ thuộc rất lớn vào việc cộng đồng chấp nhận và hỗ trợ bản build no-GIL nhanh đến đâu
- Về dài hạn, no-GIL sẽ trở thành bản build mặc định và GIL sẽ bị gỡ bỏ hoàn toàn
- Việc này phải theo cách không phá vỡ tương thích ngược một cách không cần thiết
Công việc vẫn chưa kết thúc
- Wouters cho rằng việc gỡ bỏ GIL là công việc lớn hơn rất nhiều so với chỉ chấp nhận một PEP
- Các core developer cần tích lũy kinh nghiệm với Python no-GIL và dựa vào đó dẫn dắt phần còn lại của cộng đồng
- Trong quá trình làm rõ tính an toàn luồng của mã hiện có, có thể cần các C API và Python API mới
- Trong suốt quá trình, cần định kỳ đánh giá lại tiến độ và lịch trình
- Không được để nó biến thành một cuộc chiến tương thích ngược kéo dài thêm 10 năm
- Nếu PEP 703 có vẻ sẽ trở thành vấn đề, cần có khả năng dừng lại và tìm giải pháp khác
- Vẫn còn rất nhiều nghiên cứu, viết mã, kiểm thử, thử nghiệm và tài liệu hóa trước khi đạt đến Python chỉ no-GIL; tháng 10/2028, thời điểm có thể xuất hiện Python 3.17, được nêu như một ví dụ
1 bình luận
Ý kiến trên Hacker News
Bài viết được viết tốt và tóm lược toàn bộ quá trình khá rõ, nhưng có vẻ nghiêng nhiều hơn về phía phản đối việc loại bỏ GIL và khả năng thất bại
Cũng cần nhấn mạnh đầy đủ phía ngược lại. Chất lượng công việc của Sam Gross rất cao, và ông cũng đưa vào cả những cải thiện hiệu năng không liên quan trực tiếp đến no-GIL để giảm tổn thất hiệu năng. Ông cũng vận hành rất tốt theo cách của mã nguồn mở, và đã thể hiện sự kiên nhẫn dù phản hồi chậm đến mức nếu không có áp lực từ cộng đồng thì có lẽ ban điều hành đã tiếp tục để nó nằm im. Sub-interpreter gần như chưa từng chứng minh được tính hữu dụng trong Python, đặc biệt là bằng các chỉ số nghiêm túc, và lần này gần như là nỗ lực đầu tiên được định nghĩa rõ và đo lường cẩn thận. Phản ứng của cộng đồng cũng cho thấy sự quan tâm lớn đến dự án này, và ban điều hành cũng kết luận rằng “có ý định chấp nhận PEP 703 và đang điều phối các điều kiện chấp nhận chi tiết”. Tôi không phải người ủng hộ cuồng nhiệt no-GIL, cũng không sao nếu cuối cùng GIL không bị loại bỏ, và tôi cho rằng nên thử sub-interpreter trước, nhưng cần nhìn nhận công bằng
Kết quả cũng khá ấn tượng: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Có vẻ tốt đúng như mức có thể kỳ vọng. Công việc về sub-interpreter có lẽ sẽ diễn ra song song với free-threading, và hai hướng này phục vụ các use case khác nhau
Theo tôi biết thì PDM vẫn hỗ trợ nó. Tôi không thích dùng virtualenv cho build và phân phối, và mong Python cũng có thể hoạt động như JavaScript. Việc này khả thi đã được chứng minh. Luồng thảo luận nằm ở https://discuss.python.org/t/pep-582-python-local-packages-d.... Việc “chỉ có đúng một cách đúng đắn” được dùng như lý do để từ chối cũng thật bực bội, vì tôi chưa từng cảm thấy câu đó đúng trong Python
Đây là một bài viết xuất sắc của LWN và rất đáng đọc. Khi NoGIL của Sam Gross mới xuất hiện tôi đã kỳ vọng, nhưng sau khi đọc bài và nhìn lại kinh nghiệm cá nhân, suy nghĩ của tôi bắt đầu thay đổi
Tôi đã xây dựng hệ thống backend bằng nhiều ngôn ngữ, và nhìn chung chỉ có hai loại. Một loại là hệ thống mở endpoint mạng, nhận request, thực hiện tính toán và các request mạng khác rồi trả response; loại còn lại là hệ thống đọc message từ queue, database, polling API khác, v.v., rồi tính toán và gọi mạng trước khi gửi sang queue khác. Loại đầu tiên quan trọng độ trễ, loại thứ hai quan trọng thông lượng. Với loại đầu tiên, NoGIL hữu ích vì muốn tạo thread theo request, để endpoint tính toán nặng không chặn các request khác, và chia sẻ pool kết nối database. Với loại thứ hai, ngay cả trong các ngôn ngữ không có GIL, tôi hầu như không nhớ đã dùng song song hay đồng thời trong cùng một process với tài nguyên chia sẻ, vì nó trở nên quá khó hiểu. Tối ưu hóa thường là batch processing thông minh, còn song song hóa thì là chạy nhiều process độc lập trên nhiều máy. Nếu chất lượng của loại hệ thống thứ hai bị thỏa hiệp vì NoGIL thì sẽ khá thất vọng, và thực tế hiện nay phần lớn năng lượng tinh thần của tôi đang dùng để cải thiện loại thứ hai
Hiện tôi triển khai JournalParser bằng QThread; parser này liên tục đọc các sự kiện game từ file journal của người chơi do Elite: Dangerous và Odyssey tạo ra, rồi phát QSignal tùy chỉnh theo từng sự kiện để các slot đang lắng nghe signal đó xử lý. Ở các phần khác của ứng dụng, nếu không có GIL thì cũng có thể khá hữu ích. https://captainslog.scarygliders.net/captains-log-2/
Khi đó code của mọi người đều có thể tốt hơn
Tất nhiên cũng có thể nói ngay từ đầu không nên viết chương trình thiên về CPU bằng Python, nhưng đó lại là câu chuyện khác
Nếu tài nguyên chia sẻ là read-only thì tôi không rõ vì sao nó lại gây rối đến vậy
Tôi nghi ngờ liệu câu trong thread được liên kết rằng “việc loại bỏ GIL rất khó có khả năng làm hỏng codebase chỉ viết bằng Python” có thực sự đúng hay không
Một số mã Python đa luồng có thể đang kỳ vọng rằng một số thao tác nhất định là thread-safe một cách ngầm định nhờ GIL. Ví dụ, việc hai luồng thêm phần tử vào cùng một list mà list không bị hỏng là vì GIL khiến hai luồng không thực thi thao tác đó song song. Nếu loại bỏ GIL, những đoạn mã như vậy có thể đột nhiên bị “phạt”, giống như khi thay đổi đồng thời
std::vectortrong C++. Tôi không chắc, nhưng câu này hơi đáng ngờ. https://discuss.python.org/t/pep-703-making-the-global-inter...Phần an toàn luồng của container trong PEP 703 xử lý vấn đề này. PEP đề xuất đặt một khóa nhẹ theo từng đối tượng cho mỗi list, dictionary, set; mọi thao tác sửa đổi đối tượng phải lấy khóa đó, và phần lớn thao tác đọc cũng lấy khóa. Chi tiết có tại https://peps.python.org/pep-0703/#container-thread-safety
Tuy nhiên, nếu làm vậy thì vẫn còn câu hỏi phải làm gì khi cần
[]không đồng bộ hóaappendcủa list có lẽ sẽ được bảo vệ bằng khóa theo từng instance. Ít nhất trong một số mã ý tưởng nogil thì đã làm như vậyKhó hình dung một phép thử nào trong open source còn khó hơn thế này
Bản thân quyết định là hợp lý. Tiến lên ở chế độ thử nghiệm, coi đa interpreter là một thử nghiệm trung gian, nhưng mục tiêu là Python có thể chạy đồng thời. Tuy nhiên ràng buộc chạy mã cũ và mã mới trên cùng một máy ảo là rất lớn. Thật ngạc nhiên là phần tóm tắt của LWN gần như không đề cập đến testing; testing vẫn còn khá chưa được giải quyết và có thể dẫn tới các bản phát hành chứa lỗi nghiêm trọng nhưng chưa biết. Microsoft, Facebook/Meta, Conda đang cung cấp tài nguyên và đa số áp đảo các contributor cốt lõi muốn tiến lên, nhưng chưa rõ điều gì sẽ xảy ra khi công việc trở nên khó hơn và cần thêm nhiều người. Đồng thời, từ website đến big data và AI, rất nhiều dự án khổng lồ trong học thuật và công nghiệp phụ thuộc vào Python, và chi phí chuyển sang nhà phát triển Python có thể được đo bằng tỷ lệ GDP. Có vẻ các vấn đề thậm chí còn chưa được nhận diện đầy đủ, nên trong hơn 3 năm tới nên tập trung vào cách tiếp cận Faster CPython để tạo cải thiện có thể dự đoán được, còn những người ủng hộ Python chạy đồng thời cần vượt ra ngoài prototype đơn giản để phân tích những vấn đề nào có thể phát sinh, cách phát hiện chúng và có thể làm gì. Sẽ công bằng hơn nếu những người có nền tảng chứng minh đảm bảo concurrency xem xét, các ẩn số ít nhất được nhận diện, rồi mới đưa câu hỏi lên ban điều hành. Open source không có nhiều quyết định ở quy mô quản lý chương trình; thường là các quyết định tương đối đơn giản định hướng thị trường như Apache, Eclipse, Linux, nhưng lần này có những ẩn số kỹ thuật thực sự. Đồng thời, tôi cũng cảm thấy cần xử lý ABI giữa các ngôn ngữ. Vấn đề lớn là khớp với mô hình thực thi mà C kỳ vọng; giao diện hàm ngoài và bộ nhớ của Java đã ươm mầm nhiều năm, Swift cũng đang cải thiện việc wrap C và C++, nhưng FFI nổi tiếng là khó và có lẽ còn khó một cách không cần thiết
Cá nhân tôi nghĩ loại bỏ GIL là một sai lầm. Không có nhiều ứng dụng sẽ hưởng lợi mạnh, còn đa số sẽ chịu penalty về hiệu năng
Công việc này sẽ ngốn nhiều năm quan tâm và nỗ lực, mà lẽ ra có thể dùng khôn ngoan hơn. Python trông như có sự bất an hay mặc cảm về GIL. Tôi nghĩ tốt hơn là chấp nhận hoàn toàn mô hình đơn luồng như JavaScript. Một số ứng dụng sẽ tiếp tục khó hoặc bất khả thi, nhưng tôi không nghĩ Python là lựa chọn tốt cho các app cần hiệu năng cao hoặc khả năng mở rộng cao. Việc có mức độ chuyên biệt nhất định và không hỗ trợ mọi use case không nhất thiết là xấu
Mọi người cần hiệu năng cho những việc họ đang làm bằng Python ngay bây giờ. Không thể quay lại thời kỳ điều đó không đúng. Giờ đây đó là một trong những use case phổ biến nhất của Python, và mọi người đang đặt sự nghiệp vào đó
Mọi người đã cố làm tác vụ song song bằng Python rồi. Ép họ dùng ngôn ngữ khác không giúp ích nhiều
Khá nhiều tác vụ nặng dữ liệu có thể dễ dàng chạy bằng các process song song trong Python, nên tôi không rõ việc loại bỏ GIL có đem lại lợi ích lớn đến vậy không
Hiệu năng đơn luồng khó cải thiện hơn nhiều bằng cách đổ thêm tiền vào, nên cần được ưu tiên hơn
Hiệu năng đa luồng có thể bù đắp overhead của song song hóa dựa trên process bằng cách thêm một core nữa. Tôi cho rằng bản thân cách chia đôi GIL và no-GIL là sai. Vấn đề lớn nhất của
multiprocessinglà không thể chia sẻ bộ nhớ. Vì vậy chỉ cần thêm các process ảo có cơ chế chia sẻ bộ nhớ tường minh. Khi đó object vẫn ở trong một thread, nên có thể giữ các tối ưu đơn luồng như reference counting không cần barrier.Vẫn có thể có hiệu năng đơn luồng tốt mà không cần GIL. Rust có khái niệm abstraction không tốn chi phí và cũng xử lý thread tốt. Java cũng làm tốt các tác vụ đơn luồng. Còn nhiều ngôn ngữ khác nữa, và đây không phải chuyện khoa học viễn tưởng. Lock có thể biến mất nhờ tối ưu hóa, cũng có thể chọn code hoàn toàn không dùng lock, và concurrency dạng mịn hoặc có cấu trúc cũng khả thi. Cái gì thread-safe về cơ bản là một hợp đồng API. Optimistic locking cũng tồn tại. Không có lý do chính đáng nào khiến Python không làm được điều tương tự, nhưng trước hết phải loại bỏ GIL. Phần lớn suy giảm hiệu năng của Python không GIL giống như nợ kỹ thuật chưa được xử lý, và có thể sửa dần theo thời gian. Nhét nhiều lock vào là giải pháp tạm nên sẽ chậm, nhưng lời giải đúng nhiều khả năng là suy nghĩ lại cách hoạt động bên trong hoặc có hợp đồng API ghi rõ thứ gì thread-safe. Một runtime và compiler Python nhanh hơn cũng có thể cho phép viết lại bằng Python nhiều thứ hiện đang phải dựa vào thư viện native. Chính việc tương tác với native code mới là nơi thường cần lock, và nếu không thay đổi cách đó thì vấn đề sẽ còn tiếp diễn. Trọng tâm của việc loại bỏ GIL là tìm và sửa những thứ này một cách có hệ thống, và theo thời gian sẽ tốt hơn.
multiprocessingrồi, nên đa luồng no-GIL không hữu ích lắmVấn đề duy nhất của Python/
multiprocessinglà đôi khi cần shared mutable state chứ không phải queue. Cách hiện nay đặt object Python vào shared memory rất phức tạp, hạn chế và kém hiệu quả. Đó mới là mục tiêu cần sửa, và Python cần hỗ trợ tốt hơn để đặt các instance native vào shared memory.Với câu hỏi “mức suy giảm hiệu năng nào của code đơn luồng là chấp nhận được”, Shannon ước tính khoảng 15–20%, nhưng câu hỏi đó nhìn chung vẫn chưa có lời đáp
Vậy tức là một số người trong dự án đang làm “CPython nhanh hơn” cho rằng có thể chấp nhận làm phần lớn code Python hiện có chậm đi 15–20% chỉ sau một đêm sao? Tôi nghĩ giới hạn tối đa chỉ khoảng 5%. Mà điều đó cũng chỉ chấp nhận được nếu việc loại bỏ GIL giúp các tối ưu khác trong tương lai. Nhưng nghe nói thay đổi đó ngược lại còn làm các tối ưu khác phức tạp hơn và bị trì hoãn. Trong khi đó, năm 2020 Shannon từng tự đề xuất gây quỹ để làm CPython nhanh hơn 5 lần, còn giờ cả một đội được doanh nghiệp tài trợ lớn hơn nhiều đang làm CPython nhanh hơn nhưng mục tiêu lại có vẻ nhỏ hơn rất nhiều.
Khi hiệu năng thật sự quan trọng, nếu có thể đạt tăng tốc khoảng 20 lần mà không phải viết lại bằng ngôn ngữ khác thì điều đó rất có ý nghĩa.
Nếu các tối ưu khác không bị dừng lại mà chỉ mất thêm chút thời gian, thì có thể chấp nhận được.
Nếu so sánh code thực tế có phép toán số và chuỗi, không truy cập mạng hay đĩa, thì bản beta 3.12 chỉ tốn ít thời gian hơn 3.8 khoảng 20–25%. Đó là mức của 2.7. Có vẻ các nhân vật cốt lõi lâu năm đang tuyệt vọng tìm các tính năng dạng bullet point để trình cho nhà tài trợ doanh nghiệp ở bản phát hành tiếp theo. Vì vậy họ dùng công trình của Sam Gross, nhưng theo thời gian công trạng có lẽ sẽ dần thuộc về họ.
Đúng chất LWN, đây là một bản tổng hợp rất tốt
Tôi thích cộng đồng Python. Đây là một ví dụ hàng đầu của phần mềm nguồn mở, và cho thấy minh bạch cùng quản trị tốt có thể đạt được những gì. Thời gian kỹ thuật mà Meta, Microsoft và các bên khác bỏ vào là đáng trân trọng, nhưng so với giá trị mà toàn ngành công nghệ và cả các lĩnh vực rộng hơn, bao gồm khoa học dữ liệu, nhận được từ Python và phần mềm nguồn mở thì vẫn còn quá khiêm tốn.
8 năm trước ở JPMorgan, tôi đã thuyết phục nhóm lãnh đạo kỹ thuật tài trợ PyCon UK, mở gian tuyển dụng và hỗ trợ các lập trình viên junior của JPMorgan trên khắp Vương quốc Anh tham dự. Tôi rời JPM 5 năm trước, nhưng họ vẫn là nhà tài trợ chính của PyCon UK. So với lợi ích khổng lồ mà họ nhận được từ Python và hệ sinh thái nguồn mở, chi phí đó gần như không đáng kể.
Mailing list bị kiểm duyệt, còn nhóm nội bộ thì không thể bị phê bình. Những người đóng góp thật sự bị khai thác bởi những người thuộc đúng công ty, không làm được bao nhiêu nhưng lại nắm các vị trí quyền lực hành chính. Bài của LWN rất thiện chí và luôn nhắc đúng tên những người có quyền quyết định, nên đừng bị đánh lừa. Tôi thấy nó gần với kiểu đưa tin có chọn lọc.
Cách Sam Gross thúc đẩy việc này khá ấn tượng. Sau khi nhận được phản hồi tích cực nhưng không dứt khoát từ ban điều hành, anh ấy hoàn toàn có thể ngồi chờ tiến triển, nhưng việc phản đối và gây sức ép là rất đáng được đánh giá cao.
Rất thú vị. Việc Sam Gross nói rằng “không nhất thiết cần câu trả lời yes/no ngay bây giờ, nhưng cần biết việc chấp nhận sẽ trông như thế nào, và vấn đề này đã bị bỏ mặc quá lâu” là một động thái rất táo bạo: https://github.com/python/steering-council/issues/188#issuec...
Tương tác đó có thể đã đi theo nhiều hướng, nhưng có vẻ đó chính xác là cú hích mà ban điều hành cần. Con đường tới Python không GIL vẫn còn dài và quanh co, và có lẽ cần quy mô hàng chục engineer-year, nhưng ít nhất có vẻ đã có một lộ trình đúng đắn. Phần khó nhất là đảm bảo tính đúng đắn của codebase hiện có. Nói rằng không muốn lặp lại quá trình chuyển từ Python 2 sang 3 là một chuyện, còn việc người dùng thực sự tránh nâng cấp vì sợ bug, dù khẳng định là không có thay đổi gây phá vỡ, lại là chuyện hoàn toàn khác. Chỉ để GIL/no-GIL dưới dạng công tắc compile-time thôi chắc chắn cũng làm tăng chi phí bảo trì. Dù vậy, về dài hạn tôi nghĩ nỗ lực này sẽ đáng giá. GIL giống như cột thu lôi cho những chỉ trích nhắm vào Python, cứ nhìn các thread trên HN về Python và tính song song là thấy. Có lẽ vì đó là thứ người ta có thể chỉ thẳng vào và nói “đây là lý do Python không thể nhanh hơn” mà không cần hiểu bối cảnh kéo dài hàng thập kỷ. Theo nghĩa đó, nó gần như là trùm cuối của hàng rào Chesterton
Ngay cả theo hướng dẫn mới, nỗ lực kéo dài nhiều năm để loại bỏ GIL vẫn có khả năng cuối cùng bị bác bỏ