2012-10-23 41 views
37

Tôi thấy rằng khi tôi hỏi điều gì đó với Python, python không sử dụng tài nguyên máy của tôi ở 100% và nó không thực sự nhanh, nó nhanh nếu so sánh với nhiều ngôn ngữ thông dịch khác, nhưng khi so sánh với các ngôn ngữ biên dịch, tôi nghĩ rằng sự khác biệt thực sự đáng chú ý.Trình thông dịch Python 3 có tính năng JIT không?

Có thể tăng tốc mọi thứ bằng trình biên dịch Just In Time (JIT) trong Python 3?

Thông thường trình biên dịch JIT là điều duy nhất có thể cải thiện hiệu suất trong ngôn ngữ diễn giải, vì vậy tôi đề cập đến điều này, nếu các giải pháp khác có sẵn, tôi muốn chấp nhận câu trả lời mới.

+1

PyPy có JIT: http://doc.pypy.org/en/latest/jit/index.html – rubik

+0

@rubik cảm ơn nhưng tôi đã tìm kiếm giải pháp cho python 3 không phải python 2 và cho người phiên dịch chính thức, không phải bất kỳ thông dịch viên nào khác. – guz

+1

Mặc dù pypy chưa hỗ trợ python 3. Tùy thuộc vào những gì bạn đang làm, có tất cả các cách để cải thiện hiệu suất - ví dụ, sử dụng các thuật toán tốt hơn, song song bằng cách sử dụng mô-đun 'multiprocssing' hoặc' threading' hoặc viết mở rộng trong C (có thể được thực hiện dễ dàng hơn bằng cách sử dụng [cython] (http://cython.org/) hoặc phần mềm tương tự). – James

Trả lời

42

Trước hết, Python 3 (.x) là một ngôn ngữ, trong đó có thể có bất kỳ số lần triển khai nào. Được rồi, cho đến ngày nay không thực hiện trừ CPython thực sự triển khai các phiên bản ngôn ngữ đó. Nhưng điều đó sẽ thay đổi (PyPy đang bắt kịp).

Để trả lời câu hỏi bạn muốn đặt ra: CPython, 3.x hoặc cách khác, không, không bao giờ làm, và có khả năng sẽ không bao giờ chứa trình biên dịch JIT. Một số triển khai Python khác (PyPy nguyên bản, Jython và IronPython bằng cách tái sử dụng các trình biên dịch JIT cho các máy ảo mà chúng xây dựng trên) có trình biên dịch JIT. Và không có lý do gì mà các trình biên dịch JIT của chúng sẽ ngừng hoạt động khi chúng thêm hỗ trợ Python 3.

Nhưng trong khi tôi đang ở đây, cũng cho tôi địa chỉ một quan niệm sai lầm:

Thông thường một trình biên dịch JIT là điều duy có thể cải thiện màn trình diễn trong ngôn ngữ thông dịch

Đây không phải là chính xác. Một trình biên dịch JIT, ở dạng cơ bản nhất của nó, chỉ đơn thuần loại bỏ chi phí thông dịch, mà nó giải thích cho một số chậm lại mà bạn thấy, nhưng không phải cho đa số. Trình biên dịch JIT cũng thực hiện một loạt các tối ưu hóa để loại bỏ chi phí cần thiết để triển khai nhiều tính năng Python nói chung (bằng cách phát hiện các trường hợp đặc biệt cho phép thực hiện hiệu quả hơn), các ví dụ nổi bật là nhập động, đa hình và các tính năng nội suy khác nhau.

Chỉ cần triển khai trình biên dịch không hỗ trợ điều đó. Bạn cần tối ưu hóa rất thông minh, hầu hết trong số đó chỉ hợp lệ trong các trường hợp rất cụ thể và trong một thời gian giới hạn. Các trình biên dịch JIT có dễ dàng ở đây, vì chúng có thể tạo mã chuyên biệt vào thời gian chạy (đó là toàn bộ điểm), có thể phân tích chương trình dễ dàng hơn (và chính xác hơn) bằng cách quan sát nó khi nó chạy và có thể hoàn tác tối ưu hóa khi chúng trở thành không hợp lệ. Họ cũng có thể tương tác với các thông dịch viên, không giống như các trình biên dịch trước thời hạn, và thường làm điều đó bởi vì đó là một quyết định thiết kế hợp lý. Tôi đoán đây là lý do tại sao họ được liên kết với thông dịch viên trong tâm trí của mọi người, mặc dù họ có thể và tồn tại độc lập.

Ngoài ra còn có các cách tiếp cận khác để thực hiện Python nhanh hơn, ngoài việc tối ưu hóa mã của trình thông dịch - ví dụ, dự án HotPy (2). Nhưng những người hiện đang trong giai đoạn nghiên cứu hoặc thử nghiệm, và vẫn chưa thể hiện hiệu quả của họ (và sự trưởng thành) w.r.t. mã thực.

Và tất nhiên, hiệu suất của chương trình cụ thể tùy thuộc vào chương trình chính nó nhiều hơn so với việc triển khai ngôn ngữ. Việc thực hiện ngôn ngữ chỉ đặt giới hạn trên cho tốc độ bạn có thể tạo một chuỗi các hoạt động. Nói chung, bạn có thể cải thiện hiệu suất của chương trình tốt hơn nhiều chỉ đơn giản bằng cách tránh việc không cần thiết, tức là bằng cách tối ưu hóa chương trình. Điều này đúng bất kể bạn chạy chương trình thông qua trình thông dịch, trình biên dịch JIT hay trình biên dịch trước thời hạn. Nếu bạn muốn một cái gì đó để được nhanh chóng, không đi ra khỏi con đường của bạn để có được tại một thực hiện ngôn ngữ nhanh hơn. Có những ứng dụng không khả thi với chi phí giải thích và năng động, nhưng chúng không phổ biến như bạn nghĩ (và thường, được giải quyết bằng cách gọi vào mã được biên dịch mã một cách chọn lọc).

+0

tôi có tai rằng Google quan tâm đến việc làm cho python nhanh hơn với JIT cho bản phát hành 3.x nên tôi đang tìm câu trả lời. vấn đề với việc có trình thông dịch khác nhau chỉ là thực tế là bạn đã có nhiều hơn 1 lần triển khai, cũng có nhiều ứng dụng cung cấp bàn điều khiển python tích hợp chỉ đề cập đến trình thông dịch python chính thức. Vì vậy, cuối cùng không có gì tốt và sẵn sàng cho python 3? – guz

+6

@guz Dự án Swallow Unladden của Google đã bị hủy bỏ (http://www.python.org/dev/peps/pep-3146/#pep-withdrawal) một thời gian dài trước đây, và trong khi một số công việc của họ tồn tại trong CPython và ở nơi khác, trình biên dịch JIT của họ đã chết (và không bao giờ làm việc tốt để bắt đầu với). Tôi thấy có nhiều triển khai ** như một lợi thế ** nói chung, mặc dù điểm về nhúng là một điều tốt. – delnan

+0

JIT của Java không biên dịch cho JVM? Tôi đoán là Jython sẽ làm điều tương tự. Nếu đúng như vậy, chúng ta có thể không nói rằng Python biên dịch cho máy ảo của riêng nó? Mô-đun 'dis' có thể hiển thị những gì đang thực sự được chạy. –

4

Bạn có thể thử pypy py3 branch, tương thích more or less python, nhưng việc triển khai CPython chính thức không có JIT.

+0

cảm ơn, tôi chỉ quan tâm đến trình thông dịch python chính thức cho phiên bản 3.x của ngôn ngữ, vì vậy tôi sẽ thực hiện điều này như một _no_ – guz

+0

Tuy nhiên, bạn nên thử chỉ để tối ưu hóa mã của mình, nó thường giúp ích. – lolopop

11

Việc triển khai Python duy nhất có JIT là PyPy. Byt - PyPy là một triển khai Python 2, không phải là triển khai Python 3. Bạn có thể support the Python 3 port.

+1

Hỗ trợ Python 3 hiện đã hoàn thành ít hơn, với Python 3.2 – naught101

2

Điều này sẽ được trả lời tốt nhất bởi một số người phát triển Python đáng chú ý trên trang web này.

Tôi vẫn muốn bình luận: Khi thảo luận tốc độ của ngôn ngữ giải thích, tôi chỉ yêu để trỏ đến một dự án lưu trữ tại this location: Computer Language Benchmarks Game

Đó là một trang web dành riêng để chuẩn chạy. Có những nhiệm vụ được chỉ định để thực hiện. Bất kỳ ai cũng có thể gửi một giải pháp bằng ngôn ngữ ưa thích của mình và sau đó kiểm tra so sánh thời gian chạy của mỗi giải pháp. Các giải pháp có thể được xem xét ngang hàng, thường được cải thiện hơn bởi những người khác và kết quả được kiểm tra so với thông số kỹ thuật. Về lâu dài, đây là hệ thống điểm chuẩn hợp lý nhất để so sánh các ngôn ngữ khác nhau.

Như bạn có thể thấy từ indicative summaries like this one, các ngôn ngữ được biên dịch khá nhanh so với các ngôn ngữ thông dịch. Tuy nhiên, sự khác biệt có lẽ không quá nhiều trong loại biên dịch chính xác, đó là thực tế là Python (và những người khác trong đồ thị chậm hơn python) là hoàn toàn năng động. Các đối tượng có thể được sửa đổi khi đang di chuyển. Các loại có thể được sửa đổi khi đang bay. Vì vậy, một số loại kiểm tra đã được trì hoãn để chạy, thay vì thời gian biên dịch.

Vì vậy, trong khi bạn có thể tranh luận về lợi ích của trình biên dịch, bạn phải tính đến các tính năng khác nhau ở các ngôn ngữ khác nhau. Và những tính năng đó có thể có giá nội tại.

Cuối cùng, khi nói về tốc độ: Thông thường nó không phải là ngôn ngữ và sự chậm trễ cảm nhận của một ngôn ngữ gây ra vấn đề, đó là một thuật toán xấu. Tôi không bao giờ phải chuyển đổi ngôn ngữ vì một ngôn ngữ quá chậm: Khi có vấn đề về tốc độ trong mã của tôi, tôi sửa thuật toán. Tuy nhiên, nếu có các vòng chuyên sâu tốn nhiều thời gian, tính toán trong mã của bạn, thì nó thường có giá trị trong thời gian để biên dịch lại các mã đó. Một ví dụ nổi bật là các thư viện được mã hóa bằng C được sử dụng bởi các ngôn ngữ kịch bản (Perl XS libs, hoặc ví dụ: numpy/scipy cho Python, lapack/blas là các ví dụ về libs có sẵn với các ràng buộc cho nhiều ngôn ngữ kịch bản)

+0

có nhưng nếu tôi chỉ chạy mã từ tệp source.py tôi có thể không được hưởng lợi từ _dynamic-ness_ này, cũng trong thời điểm chính xác mà tôi sẽ chạy mã từ các tập tin bạn có thể xác định hệ điều hành của tôi, nền tảng của tôi và những gì chương trình của tôi sẽ làm, mà có lẽ là thông tin hữu ích có thể dẫn đến tối ưu hóa như trong ví dụ JIT. – guz

+0

@igouy: Cảm ơn bạn đã chỉ ra. Tôi đã làm rõ phản ứng của tôi. – cfi

+0

Tên dự án được hiển thị trong biểu ngữ trên mọi trang và trong thanh tiêu đề trình duyệt web và các đoạn văn được hiển thị trên trang web giải thích lý do dự án không được gọi là "loạt đá luân lưu" trong ít nhất 5 năm. – igouy

0

Nếu bạn có nghĩa là JIT như trong Chỉ trong thời gian trình biên dịch để một đại diện Bytecode sau đó nó có một tính năng (kể từ 2.2). Nếu bạn có nghĩa là JIT để mã máy, sau đó không. Tuy nhiên, việc biên dịch thành mã byte cung cấp rất nhiều cải thiện hiệu suất. Nếu bạn muốn nó biên dịch thành mã máy, thì Pypy là sự triển khai mà bạn đang tìm kiếm.

Lưu ý: pypy không hoạt động với Python 3.x

7

Dự án Numba sẽ hoạt động trên Python 3. Mặc dù nó không chính xác như những gì bạn đã hỏi, nhưng bạn có thể thử: https://github.com/numba/numba/blob/master/docs/source/doc/userguide.rst.

Nó không hỗ trợ tất cả cú pháp Python tại thời điểm này.

+1

Numba, theo như tôi có thể nói, không phải là và không bao giờ có ý định, một thực hiện của Python. Thay vào đó, nó rõ ràng là một thực hiện cho một ngôn ngữ trông giống như Python, nhưng thực sự không có gì giống như nó - hy sinh nhiều tính năng ngôn ngữ để thực hiện. Đúng nếu tôi sai.Có lẽ các nhà phát triển PyPy đã tẩy não tôi, nhưng tôi nghĩ rằng điều này không nên so sánh với Python (hoặc thậm chí được gọi là như vậy) ngoại trừ nhà nước rằng nó hoàn toàn không giống như Python. – delnan

+0

@delnan: Thật thú vị. Tại sao không gọi nó là Python với ít tính năng hơn? Tôi không biết dự án tốt nhưng IIUC bạn có một tập tin Python, sau đó áp dụng các trang trí jit và bạn đang thực hiện :) Có lẽ đây là quá lạc quan và/hoặc ngây thơ. Trên thực tế tôi thậm chí không thử, mặc dù tôi muốn ... – rubik

+0

Bởi vì "Python với ít tính năng" không phải là Python, nó là một ngôn ngữ rất khác nhau cũng xảy ra cũng được chấp nhận cho Python. Có, giả sử nó chỉ hoạt động là quá lạc quan. Trừ khi các nhà phát triển Numba một tay đã làm những gì PyPy đã làm, với rất nhiều hạn chế bổ sung, trong thời gian ít hơn rất nhiều với nhân lực ít hơn, Numba nhất thiết chỉ hỗ trợ một tập con nhỏ của Python. Tôi muốn nói các hạn chế tối thiểu là (ẩn, dễ dàng suy luận) gõ tĩnh. Tôi sẽ ngạc nhiên nếu họ hỗ trợ các đối tượng tùy ý do người dùng định nghĩa, nhưng tôi nghi ngờ nó. – delnan

0

Nếu bạn đang tìm kiếm các cải tiến về tốc độ trong một khối mã, bạn có thể muốn xem rpythonic, biên dịch xuống C bằng pypy. Nó sử dụng một trang trí để chuyển đổi nó trong một JIT cho Python.

Các vấn đề liên quan