Thư viện NativeJIT của Microsoft , ban đầu được phát triển bởi nhóm Bing cho việc biên dịch just-in-time hiệu năng cao, đã tạo ra cuộc thảo luận sôi nổi trong cộng đồng lập trình viên về tình trạng hiện tại và những hạn chế thực tế của nó. Trong khi thư viện mã nguồn mở này hứa hẹn biên dịch nhanh các biểu thức thành mã x64 được tối ưu hóa, phản hồi gần đây từ cộng đồng đã tiết lộ một số mối quan ngại về quỹ đạo phát triển và triển khai kỹ thuật của nó.
Các tính năng chính:
- Thư viện biên dịch JIT đa nền tảng
- Không phụ thuộc vào gì ngoài thời gian chạy C++ tiêu chuẩn
- Phân bổ thanh ghi được tối ưu hóa
- Hỗ trợ các phép toán số học/logic, điều kiện, truy cập trường cấu trúc
- Khả năng gọi hàm tới các hàm C
Khoảng Cách Giữa Phiên Bản Nội Bộ và Mã Nguồn Mở
Một mối quan ngại lớn được các lập trình viên nêu ra là sự ngắt kết nối rõ ràng giữa phiên bản nội bộ của Microsoft và mã nguồn công khai. Các thành viên cộng đồng đã phát hiện ra rằng Bing sử dụng một phiên bản nội bộ của NativeJIT được cải tiến đáng kể, nhưng những cải tiến này không được hợp nhất trở lại vào kho lưu trữ GitHub . Điều này tạo ra tình huống bực bội khi cộng đồng mã nguồn mở không thể hưởng lợi từ những cải tiến thực tế mà Microsoft đã phát triển cho việc sử dụng trong sản xuất.
Câu Hỏi Về Chất Lượng Sinh Mã
Khả năng sinh mã của thư viện đã bị xem xét kỹ lưỡng bởi các lập trình viên tập trung vào hiệu năng. Phân tích mã assembly được tạo ra cho thấy đầu ra không tối ưu, đặc biệt liên quan đến các thao tác thiết lập và dọn dẹp stack frame không cần thiết mà các trình biên dịch hiện đại thường sẽ tối ưu hóa bỏ đi. Điều này đặt ra câu hỏi về việc liệu NativeJIT có cung cấp lợi thế có ý nghĩa so với các phương pháp truyền thống như biên dịch mã và sử dụng tải động thông qua các hàm dlopen hoặc LoadLibrary .
Tranh Luận Về Thiết Kế API
Giao diện lập trình của thư viện đã tạo ra cuộc tranh luận về khả năng sử dụng và các thực hành C++ hiện đại. Trong khi NativeJIT yêu cầu các lập trình viên xây dựng biểu thức bằng cách sử dụng các lời gọi phương thức như expression.Mul(), một số thành viên cộng đồng lập luận cho việc hỗ trợ nạp chồng toán tử cho phép cú pháp tự nhiên hơn tương tự như các thư viện như Eigen hoặc z3 của Python . Điều này sẽ cho phép các lập trình viên viết biểu thức bằng ký hiệu toán học quen thuộc thay vì chuỗi phương thức dài dòng.
Đúng vậy, nhưng điều tôi nghi ngờ người bình luận đang nói là bạn cũng có thể xây dựng biểu thức bằng cách sử dụng nạp chồng toán tử, vì vậy bạn có thể gõ 'a + b', không phải 'a.Add(b)'
Tính Xác Định và Tiềm Năng Bộ Nhớ Đệm
Một cuộc thảo luận kỹ thuật thú vị đã nổi lên xung quanh bản chất xác định của việc sinh mã của NativeJIT . Các lập trình viên đang đặt câu hỏi về việc liệu việc cung cấp các cây biểu thức giống hệt nhau cho trình biên dịch có tạo ra đầu ra giống hệt nhau về byte qua nhiều lần chạy hay không. Nếu đầu ra là xác định, điều này có thể cho phép các chiến lược ghi nhớ mạnh mẽ nơi mã đã biên dịch có thể được lưu trong bộ nhớ đệm và tái sử dụng, cải thiện đáng kể hiệu năng cho các biểu thức lặp lại.
Giải Pháp Thay Thế và Cạnh Tranh
Cuộc thảo luận cộng đồng đã làm nổi bật một số phương pháp và công cụ cạnh tranh trong không gian biên dịch JIT . Các lập trình viên đã đề cập đến dự án ORC của LLVM , Clang-REPL , và libgccjit như những lựa chọn thay thế đáng xem xét. Một số thậm chí đã gợi ý rằng các ngôn ngữ với triển khai JIT trưởng thành, như HotSpot VM của Java , có thể phù hợp hơn cho các tình huống yêu cầu biên dịch và tối ưu hóa biểu thức thời gian chạy.
Trong khi NativeJIT đại diện cho một phương pháp thú vị đối với việc sinh mã thời gian chạy, phản hồi từ cộng đồng cho thấy rằng người dùng tiềm năng nên đánh giá cẩn thận xem liệu những hạn chế hiện tại của nó có vượt quá lợi ích hay không. Khoảng cách giữa các phiên bản nội bộ và công khai, kết hợp với mối quan ngại về chất lượng sinh mã, có thể đẩy các lập trình viên hướng tới những lựa chọn thay thế trưởng thành hơn cho đến khi những vấn đề này được giải quyết.
Tham khảo: NativeJIT