Điều gì chặn Ruby, Python để có được tốc độ V8 V8? [đóng cửa]

Có bất kỳ tính năng Ruby / Python nào đang ngăn chặn việc thực hiện tối ưu hóa (ví dụ: bộ nhớ đệm nội tuyến ) không?

Python được đồng phát triển bởi Google, vì vậy nó không bị chặn bởi các bằng sáng chế phần mềm.

Hoặc đây là vấn đề tài nguyên được đưa vào dự án V8 của Google.

Điều gì chặn Ruby, Python để có được tốc độ V8 V8?

Không có gì.

Thôi, được: tiền. (Và thời gian, con người, tài nguyên, nhưng nếu bạn có tiền, bạn có thể mua chúng.)

V8 có một đội ngũ kỹ sư giỏi, chuyên môn cao, giàu kinh nghiệm (và được trả lương cao) làm việc với nó, có nhiều thập kỷ kinh nghiệm (tôi đang nói riêng - nói chung giống như nhiều thế kỷ) trong việc tạo ra hiệu suất cao động cơ cho các ngôn ngữ OO năng động. Về cơ bản, họ là những người cũng đã tạo ra Sun HotSpot JVM (trong số nhiều người khác).

Lars Bak, nhà phát triển chính, đã làm việc trên các máy ảo trong 25 năm (và tất cả các máy ảo đó đã dẫn đến V8), về cơ bản là toàn bộ cuộc đời (chuyên nghiệp) của anh. Một số người viết Ruby VM thậm chí chưa 25 tuổi.

Có bất kỳ tính năng Ruby / Python nào đang ngăn chặn việc thực hiện tối ưu hóa (ví dụ: bộ nhớ đệm nội tuyến) không?

Cho rằng ít nhất IronRuby, JRuby, MagLev, MacRuby và Rubinius có bộ nhớ đệm nội tuyến đơn hình (IronRuby) hoặc đa hình, câu trả lời rõ ràng là không.

Các triển khai Ruby hiện đại đã thực hiện rất nhiều tối ưu hóa. Ví dụ, đối với các hoạt động nhất định, Hashlớp của Rubinius nhanh hơn YARV. Bây giờ, điều này nghe có vẻ không thú vị lắm cho đến khi bạn nhận ra rằng Hashlớp của Rubinius được triển khai trong Ruby nguyên chất 100%, trong khi YARV được triển khai trong C. được tối ưu hóa 100% bằng tay.

Vì vậy, ít nhất trong một số trường hợp, Rubinius có thể tạo mã tốt hơn GCC!

Hoặc đây là vấn đề tài nguyên được đưa vào dự án V8 của Google.

Đúng. Không chỉ Google. Dòng mã nguồn của V8 hiện đã 25 tuổi. Những người đang làm việc trên V8 cũng đã tạo ra Self VM (cho đến ngày nay, một trong những công cụ thực thi ngôn ngữ OO động nhanh nhất từng được tạo ra), VM định dạng Smalltalk VM (cho đến ngày nay là một trong những công cụ thực thi Smalltalk nhanh nhất từng được tạo ra), HotSpot JVM (JVM nhanh nhất từng được tạo, có thể là thời kỳ VM nhanh nhất) và OOVM (một trong những máy ảo Smalltalk hiệu quả nhất từng được tạo).

Trên thực tế, Lars Bak, nhà phát triển hàng đầu của V8, đã làm việc trên từng chiếc một , cộng với một vài thứ khác.

Có rất nhiều động lực để tối ưu hóa cao các trình thông dịch JavaScript, đó là lý do tại sao chúng ta thấy rất nhiều tài nguyên được đưa vào giữa Mozilla, Google và Microsoft. JavaScript phải được tải xuống, phân tích cú pháp, biên dịch và chạy trong thời gian thực trong khi một con người (thường thiếu kiên nhẫn) đang chờ đợi nó, nó phải chạy KHI một người đang tương tác với nó và nó đang làm điều này trong một ứng dụng khách không kiểm soát được môi trường có thể là máy tính, điện thoại hoặc máy nướng bánh mì. Nó đã được hiệu quả để chạy trong những điều kiện này một cách hiệu quả.

Python và Ruby được chạy trong một môi trường được kiểm soát bởi nhà phát triển / nhà triển khai. Một máy chủ mạnh mẽ hoặc hệ thống máy tính để bàn thường có yếu tố giới hạn sẽ là những thứ như I / O bộ nhớ và không phải là thời gian thực hiện. Hoặc nơi tối ưu hóa phi động cơ như bộ nhớ đệm có thể được sử dụng. Đối với những ngôn ngữ này, có lẽ sẽ có ý nghĩa hơn khi tập trung vào ngôn ngữ và tính năng thư viện được đặt trên tối ưu hóa tốc độ.

Lợi ích phụ của việc này là chúng tôi có hai công cụ JavaScript mã nguồn mở hiệu suất cao tuyệt vời có thể và đang được tái sử dụng cho tất cả các cách ứng dụng như Node.js.

Một phần tốt của nó phải làm với cộng đồng. Python và Ruby phần lớn không có sự hỗ trợ của công ty. Không ai được trả tiền để làm việc trên Python và Ruby toàn thời gian (và họ đặc biệt không được trả tiền để làm việc trên CPython hoặc MRI toàn bộ thời gian). V8, mặt khác, được hỗ trợ bởi công ty CNTT mạnh nhất thế giới.

Hơn nữa, V8 có thể nhanh hơn bởi vì điều duy nhất quan trọng với người V8 là trình thông dịch - họ không có thư viện chuẩn để làm việc, không phải lo ngại về thiết kế ngôn ngữ. Họ chỉ viết thông dịch viên. Đó là nó.

Nó không có gì để làm với luật sở hữu trí tuệ. Python cũng không được đồng phát triển bởi Google (người tạo ra nó hoạt động ở đó cùng với một vài thành viên khác, nhưng họ không được trả tiền để làm việc trên Python).

Một trở ngại khác đối với tốc độ Python là Python 3. Việc áp dụng nó dường như là mối quan tâm chính của các nhà phát triển ngôn ngữ - đến mức họ đã đóng băng phát triển các tính năng ngôn ngữ mới cho đến khi các triển khai khác bắt kịp.

Về các chi tiết kỹ thuật, tôi không biết nhiều về Ruby, nhưng Python có một số nơi có thể sử dụng tối ưu hóa (và Unladen Swallow, một dự án của Google, đã bắt đầu thực hiện những điều này trước khi cắn bụi). Dưới đây là một số tối ưu hóa mà họ đã lên kế hoạch . Tôi có thể thấy Python tăng tốc V8 trong tương lai nếu JIT a la PyPy được triển khai cho CPython, nhưng dường như điều đó không có khả năng trong những năm tới (trọng tâm ngay bây giờ là áp dụng Python 3, không phải JIT).

Nhiều người cũng cảm thấy rằng Ruby và Python có thể được hưởng lợi rất nhiều từ việc loại bỏ các khóa phiên dịch toàn cầu tương ứng của họ .

Bạn cũng phải hiểu rằng Python và Ruby đều là những ngôn ngữ nặng hơn nhiều so với JS - chúng cung cấp nhiều hơn theo cách của thư viện tiêu chuẩn, các tính năng ngôn ngữ và cấu trúc. Chỉ riêng hệ thống lớp định hướng đối tượng đã tăng thêm trọng lượng (theo cách tốt, tôi nghĩ vậy). Tôi gần như nghĩ về Javascript như một ngôn ngữ được thiết kế để được nhúng, như Lua (và theo nhiều cách, chúng giống nhau). Ruby và Python có một bộ tính năng phong phú hơn nhiều, và tính biểu cảm đó thường sẽ đến với chi phí tốc độ.

Hiệu suất dường như không phải là trọng tâm chính của các nhà phát triển Python cốt lõi, những người dường như cảm thấy rằng "đủ nhanh" là đủ tốt và các tính năng giúp lập trình viên làm việc hiệu quả hơn quan trọng hơn các tính năng giúp máy tính chạy mã nhanh hơn.

Tuy nhiên, tuy nhiên, đã có một dự án Google (hiện đã bị bỏ rơi), không được nuốt , để tạo ra trình thông dịch Python nhanh hơn tương thích với trình thông dịch chuẩn. PyPy là một dự án khác dự định sản xuất Python nhanh hơn. Ngoài ra còn có Psyco , tiền thân của PyPy, có thể tăng hiệu năng cho nhiều tập lệnh Python mà không thay đổi toàn bộ trình thông dịch và Cython , cho phép bạn viết thư viện C hiệu suất cao cho Python bằng cách sử dụng cú pháp Python rất giống.

Câu hỏi sai lệch. V8 là một triển khai JIT (một trình biên dịch đúng lúc) của JavaScript và trong triển khai Node.js không phải trình duyệt phổ biến nhất của nó, nó được xây dựng xung quanh một vòng lặp sự kiện. CPython không phải là JIT & không có sự kiện. Nhưng những thứ này tồn tại trong Python phổ biến nhất trong dự án PyPy - một JIT tương thích CPython 2.7 (và sắp trở thành 3.0+). Và có rất nhiều thư viện máy chủ sự kiện như Tornado chẳng hạn. Các thử nghiệm trong thế giới thực tồn tại giữa PyPy chạy Tornado vs Node.js và sự khác biệt về hiệu suất là không đáng kể.

Tôi chỉ chạy qua câu hỏi này và đó cũng là một lý do kỹ thuật lớn cho sự khác biệt hiệu suất không được đề cập. Python có một hệ sinh thái rất lớn các phần mở rộng phần mềm mạnh mẽ, nhưng hầu hết các phần mở rộng này được viết bằng C hoặc các ngôn ngữ cấp thấp khác để thực hiện và được gắn chặt với API CPython.

Có rất nhiều kỹ thuật nổi tiếng (JIT, trình thu gom rác hiện đại, v.v.) có thể được sử dụng để tăng tốc độ triển khai CPython nhưng tất cả sẽ yêu cầu thay đổi đáng kể đối với API, phá vỡ hầu hết các tiện ích mở rộng trong quy trình. CPython sẽ nhanh hơn, nhưng rất nhiều thứ khiến Python trở nên hấp dẫn (kho phần mềm mở rộng) sẽ bị mất. Trong trường hợp, có một số triển khai Python nhanh hơn ngoài kia nhưng chúng có ít lực kéo so với CPython.

Bởi vì các ưu tiên thiết kế khác nhau và mục tiêu sử dụng trường hợp tôi tin.

Trong mục đích chính chung của các ngôn ngữ script (hay còn gọi là động) là "chất kết dính" giữa các lệnh gọi của các hàm riêng. Và các chức năng gốc này sẽ a) bao gồm hầu hết các khu vực quan trọng / thường xuyên sử dụng và b) có hiệu quả nhất có thể.

Dưới đây là một ví dụ: Sắp xếp jQuery khiến iOS Safari bị đóng băng Việc đóng băng có nguyên nhân là do sử dụng quá nhiều các lệnh gọi get-by-selector. Nếu get-by-selector sẽ được triển khai bằng mã gốc và thực sự nó sẽ không có vấn đề như vậy.

Xem xét bản demo ray-tracer thường được dùng để trình diễn V8. Trong thế giới Python, nó có thể được triển khai bằng mã gốc vì Python cung cấp tất cả các tiện ích cho các tiện ích mở rộng riêng. Nhưng trong lĩnh vực V8 (hộp cát phía máy khách), bạn không có lựa chọn nào khác ngoài việc làm cho VM trở nên [phụ] hiệu quả nhất có thể. Và do đó, tùy chọn duy nhất thấy triển khai ray-tracer là bằng cách sử dụng mã script.

Vì vậy, các ưu tiên và động lực khác nhau.

Trong Sciter tôi đã thực hiện một bài kiểm tra bằng cách thực hiện khá nhiều lõi jQurey đầy đủ. Trên các tác vụ thực tế như ScIDE (IDE làm bằng HTML / CSS / Script) tôi tin rằng giải pháp như vậy hoạt động tốt hơn đáng kể so với bất kỳ tối ưu hóa VM nào.

Như những người khác đã đề cập, Python có trình biên dịch JIT hiệu suất dưới dạng PyPy .

Làm cho điểm chuẩn có ý nghĩa luôn luôn tinh tế, nhưng tôi tình cờ có một điểm chuẩn đơn giản của K-nghĩa được viết bằng các ngôn ngữ khác nhau - bạn có thể tìm thấy nó ở đây . Một trong những hạn chế là tất cả các ngôn ngữ nên thực hiện cùng một thuật toán và nên cố gắng trở nên đơn giản và thành ngữ (trái ngược với tối ưu hóa tốc độ). Tôi đã viết tất cả các triển khai, vì vậy tôi biết rằng tôi đã không lừa dối, mặc dù tôi không thể yêu cầu tất cả các ngôn ngữ mà những gì tôi đã viết là thành ngữ (tôi chỉ có kiến ​​thức về một số trong số đó).

Tôi không yêu cầu bất kỳ kết luận dứt khoát nào, nhưng PyPy là một trong những triển khai nhanh nhất tôi nhận được, tốt hơn nhiều so với Node. CPython, thay vào đó, ở cuối bảng xếp hạng chậm nhất.

Tuyên bố không chính xác

Giống như V8 chỉ là một triển khai cho JS, CPython chỉ là một triển khai cho Python. Pypy có màn trình diễn phù hợp với động cơ V8 .

Ngoài ra, có vấn đề về hiệu suất nhận thức: vì V8 thực sự không bị chặn, nhà phát triển Web dẫn đến các dự án hiệu suất cao hơn vì bạn lưu chờ đợi IO. Và V8 chủ yếu được sử dụng cho dev Web trong đó IO là chìa khóa, vì vậy họ so sánh nó với các dự án tương tự. Nhưng bạn có thể sử dụng Python trong nhiều, nhiều lĩnh vực khác ngoài web dev. Và thậm chí bạn có thể sử dụng các phần mở rộng C cho rất nhiều nhiệm vụ, chẳng hạn như tính toán khoa học hoặc mã hóa, và dữ liệu giòn với sự hoàn hảo rực rỡ.

Nhưng trên web, hầu hết các dự án Python và Ruby phổ biến đều bị chặn. Python, đặc biệt, có sự kế thừa của tiêu chuẩn WSGI đồng bộ và các khung như Django nổi tiếng được dựa trên nó.

Bạn có thể viết Python không đồng bộ (như với Twisted, Tornado, gevent hoặc asyncio) hoặc Ruby. Nhưng nó không được thực hiện thường xuyên. Các công cụ tốt nhất vẫn đang chặn.

Tuy nhiên, chúng là một số lý do tại sao việc triển khai mặc định trong Ruby và Python không nhanh như V8.

Kinh nghiệm

Giống như Jörg W Mittag đã chỉ ra, những người làm việc trên V8 là những thiên tài VM. Python là một nhóm người đam mê, rất giỏi trong nhiều lĩnh vực, nhưng không chuyên về điều chỉnh VM.

Tài nguyên

Nền tảng phần mềm Python có rất ít tiền: chưa đến 40 nghìn trong một năm để đầu tư vào Python. Điều này thật điên rồ khi bạn nghĩ rằng những người chơi lớn như Google, Facebook hay Apple đều đang sử dụng Python, nhưng đó là sự thật xấu xí: hầu hết mọi công việc đều được thực hiện miễn phí. Ngôn ngữ cung cấp năng lượng cho Youtube và tồn tại trước khi Java được các tình nguyện viên làm thủ công.

Họ là những tình nguyện viên thông minh và tận tụy, nhưng khi họ xác định họ cần nhiều nước trái cây hơn trong một lĩnh vực, họ không thể yêu cầu 300k để thuê một chuyên gia xuất sắc hàng đầu cho lĩnh vực chuyên môn này. Họ phải tìm kiếm những người sẽ làm điều đó miễn phí.

Trong khi điều này hoạt động, nó có nghĩa là bạn phải rất cẩn thận về các ưu tiên của bạn. Do đó, bây giờ chúng ta cần xem xét:

Mục tiêu

Ngay cả với các tính năng hiện đại mới nhất, viết Javascript là khủng khiếp. Bạn có các vấn đề phạm vi, rất ít bộ sưu tập, thao tác chuỗi và chuỗi khủng khiếp, hầu như không có stdlist ngoài ngày, toán học và biểu thức chính quy, và không có đường cú pháp ngay cả đối với các hoạt động rất phổ biến.

Nhưng trong V8, bạn đã có tốc độ.

Điều này là do, tốc độ là mục tiêu chính của Google, vì đó là một nút cổ chai để kết xuất trang trong Chrome.

Trong Python, khả năng sử dụng là mục tiêu chính. Bởi vì nó gần như không bao giờ là nút cổ chai trong dự án. Tài nguyên khan hiếm ở đây là thời gian của nhà phát triển. Nó được tối ưu hóa cho nhà phát triển.

Bởi vì việc triển khai JavaScript không cần quan tâm đến khả năng tương thích ngược của các ràng buộc của chúng.

Cho đến gần đây, người dùng duy nhất triển khai JavaScript là trình duyệt web. Do yêu cầu bảo mật, chỉ có các nhà cung cấp trình duyệt web có đặc quyền mở rộng chức năng bằng cách viết các ràng buộc cho thời gian chạy. Do đó, không cần phải giữ API C của các liên kết tương thích ngược, cho phép các nhà phát triển trình duyệt web cập nhật mã nguồn của họ khi thời gian chạy JavaScript phát triển; họ đã làm việc cùng nhau Ngay cả V8, vốn là một người đến muộn trong trò chơi, và cũng được dẫn dắt bởi một nhà phát triển rất có kinh nghiệm, đã thay đổi API khi nó trở nên tốt hơn.

OTOH Ruby được sử dụng (chủ yếu) ở phía máy chủ. Nhiều phần mở rộng ruby ​​phổ biến được viết dưới dạng liên kết C (xem xét trình điều khiển RDBMS). Nói cách khác, Ruby sẽ không bao giờ thành công nếu không duy trì khả năng tương thích.

Ngày nay, sự khác biệt vẫn tồn tại ở một mức độ nào đó. Các nhà phát triển sử dụng node.js đang phàn nàn rằng thật khó để giữ các tiện ích mở rộng gốc của họ tương thích ngược, vì V8 thay đổi API theo thời gian (và đó là một trong những lý do khiến node.js bị rẽ nhánh). Viên ruby ​​IIRC vẫn đang sử dụng một cách tiếp cận bảo thủ hơn nhiều về mặt này.

V8 nhanh do JIT, Crankshaft, loại suy ra và mã được tối ưu hóa dữ liệu. Con trỏ được gắn thẻ, gắn thẻ NaN của đôi. Và tất nhiên nó tối ưu hóa trình biên dịch bình thường ở giữa.

Các động cơ ruby, python và perl đơn giản không làm được điều đó, chỉ là những tối ưu hóa cơ bản nhỏ.

Vm chính duy nhất đến gần là luajit, thậm chí không thực hiện suy luận kiểu, gấp liên tục, gắn thẻ NaN cũng như số nguyên, nhưng sử dụng cấu trúc dữ liệu và mã nhỏ tương tự, không béo như các ngôn ngữ xấu. Và ngôn ngữ động nguyên mẫu của tôi, potion và p2 có các tính năng tương tự như luajit và vượt trội so với v8. Với một hệ thống loại tùy chọn, "gõ dần dần", bạn có thể dễ dàng vượt qua v8, vì bạn có thể bỏ qua trục khuỷu. Xem phi tiêu.

Các phụ trợ được tối ưu hóa đã biết, như pypy hoặc jruby vẫn phải chịu các kỹ thuật quá kỹ thuật khác nhau.