Chúng ta có thể đưa ra tuyên bố chung về hiệu suất của mã được giải thích so với mã được biên dịch không?

Tôi đang so sánh hai công nghệ để đạt được khuyến nghị nên sử dụng công nghệ nào. Mã công nghệ A được diễn giải trong khi mã công nghệ B được biên dịch thành mã máy. Trong so sánh của tôi, tôi nói rằng công nghệ B nói chung sẽ có hiệu suất tốt hơn vì nó không có thêm chi phí cho quá trình giải thích. Tôi cũng nói rằng vì một chương trình có thể được viết theo nhiều cách nên vẫn có thể một chương trình được viết trong công nghệ A có thể vượt trội hơn một chương trình được viết trong công nghệ B.

Khi tôi gửi báo cáo này để xem xét, người đánh giá nói rằng tôi không đưa ra lý do rõ ràng tại sao nói chung, quá trình giải thích sẽ đủ lớn để chúng tôi có thể kết luận rằng hiệu suất của B công nghệ sẽ tốt hơn.

Vì vậy, câu hỏi của tôi là chúng ta có thể nói bất cứ điều gì về hiệu suất của các công nghệ được biên dịch / giải thích không? Nếu chúng ta có thể nói được biên dịch thường nhanh hơn thì được giải thích, làm thế nào tôi có thể thuyết phục người đánh giá về quan điểm của mình?

Không.

Nhìn chung, hiệu suất của việc thực hiện ngôn ngữ chủ yếu phụ thuộc vào số tiền, tài nguyên, nhân lực, nghiên cứu, kỹ thuật và phát triển dành cho nó.

Và đặc biệt, hiệu suất của một chương trình cụ thể chủ yếu phụ thuộc vào lượng suy nghĩ đưa vào thuật toán của nó.

Có một số trình thông dịch rất nhanh ngoài kia, và một số trình biên dịch tạo mã rất chậm .

Ví dụ, một trong những lý do Forth vẫn còn phổ biến là bởi vì trong nhiều trường hợp, chương trình Forth được giải thích nhanh hơn chương trình C được biên dịch tương đương, đồng thời, chương trình người dùng được viết bằng Forth cộng với trình thông dịch Forth được viết in C nhỏ hơn chương trình người dùng viết bằng C.

Khái quát và kịch bản cụ thể là đối lập theo nghĩa đen.

Bạn dường như đang mâu thuẫn với chính mình. Một mặt, bạn muốn đưa ra một tuyên bố chung về việc diễn giải so với các ngôn ngữ được biên dịch. Nhưng mặt khác, bạn muốn áp dụng tuyên bố chung đó vào một kịch bản cụ thể liên quan đến Công nghệ A và Công nghệ B.

Khi bạn áp dụng một cái gì đó vào một kịch bản cụ thể, nó không còn khái quát nữa . Vì vậy, ngay cả khi bạn có thể làm cho trường hợp các ngôn ngữ được diễn giải nói chung chậm hơn , bạn vẫn không đưa ra quan điểm của mình. Người đánh giá của bạn không quan tâm đến việc khái quát hóa. Bạn đang làm một phân tích về hai công nghệ rất cụ thể. Đó là nghĩa đen của việc khái quát hóa.

Theo nguyên tắc thông thường, một chương trình được thông dịch chậm hơn khoảng 10 lần so với việc viết chương trình bằng ngôn ngữ máy chủ của trình thông dịch, với các trình thông dịch cho các ngôn ngữ động hơn sẽ chậm hơn. Điều này là do chương trình diễn giải phải thực hiện tất cả các công việc thực tế, nhưng ngoài ra còn có chi phí diễn giải.

Tùy thuộc vào cấu trúc của trình thông dịch, có thể có sự khác biệt rất đáng kể. Có hai trường phái mâu thuẫn về thiết kế trình thông dịch: Một người nói rằng opcodes nên càng nhỏ càng tốt để họ có thể tối ưu hóa dễ dàng hơn, cái còn lại nói opcodes nên càng lớn càng tốt để chúng ta làm việc nhiều hơn trong trình thông dịch. Khi cấu trúc chương trình của bạn phù hợp với triết lý của trình thông dịch, chi phí sẽ không đáng kể.

Ví dụ Perl là một ngôn ngữ được giải thích theo hướng thao tác văn bản. Một chương trình Perl thành ngữ thực hiện thao tác văn bản sẽ không chậm hơn nhiều so với chương trình C và thậm chí có thể vượt trội hơn chương trình C trong một số trường hợp (có thể vì Perl sử dụng biểu diễn chuỗi khác nhau và có các tối ưu hóa liên quan đến văn bản và IO khác nhau). Tuy nhiên, thực hiện crunching số trong Perl sẽ chậm không thể chịu được. Gia số ++xlà một hướng dẫn lắp ráp đơn lẻ, nhưng bao gồm nhiều lần di chuyển con trỏ và các nhánh cho trình thông dịch Perl. Gần đây tôi đã chuyển một tập lệnh Perl gắn với CPU sang C ++ và nhận được tốc độ tăng tốc 20x của 20x, tùy thuộc vào mức độ tối ưu hóa của trình biên dịch.

Nói về tối ưu hóa là rất quan trọng ở đây, vì một trình thông dịch được tối ưu hóa, được tối ưu hóa có thể hợp lý tốt hơn một trình biên dịch ngây thơ không tối ưu hóa. Do việc tạo một trình biên dịch tối ưu hóa rất khó khăn và đòi hỏi nhiều nỗ lực, nên chắc chắn công nghệ BẠCH của bạn có mức độ trưởng thành này.

(Lưu ý: trang web Trò chơi Điểm chuẩn Ngôn ngữ Máy tính có cấu trúc khó hiểu, nhưng một khi bạn đạt được bảng thời gian cho một vấn đề, bạn sẽ nhận thấy rằng hiệu suất của các ngôn ngữ khác nhau ở mọi nơi - thường, không có ranh giới hiệu suất rõ ràng giữa các giải pháp được biên dịch và giải thích. Phần quan trọng nhất của trang web không phải là kết quả điểm chuẩn, mà là các cuộc thảo luận về mức độ khó của các điểm chuẩn có ý nghĩa.)

Khi chọn một công nghệ, hiệu năng của thời gian chạy ngôn ngữ tự nó là hoàn toàn không liên quan. Điều quan trọng hơn là công nghệ đáp ứng một số hạn chế cơ bản (ngân sách của chúng tôi là $ x, chúng tôi phải có thể giao hàng trước yyyy-mm-dd, chúng tôi phải đáp ứng các yêu cầu phi chức năng khác nhau) và nó có mức thấp hơn tổng chi phí sở hữu (bao gồm năng suất của nhà phát triển, chi phí phần cứng, chi phí cơ hội kinh doanh, rủi ro lỗi và các hạn chế bất ngờ trong công nghệ, chi phí bảo trì, chi phí đào tạo và thuê mướn). Ví dụ, trong một ngành công nghiệp mà thời gian tiếp thị là yếu tố quan trọng nhất, công nghệ có năng suất nhà phát triển tốt nhất sẽ phù hợp nhất. Đối với một tổ chức lớn, khả năng duy trì và chi phí dài hạn có thể thú vị hơn.

Bạn hoàn toàn có thể nói điều gì đó về hiệu suất của các công nghệ được biên dịch / giải thích. Nhưng trước tiên, bạn phải xác định "hiệu suất". Nếu bạn đang xây dựng một hệ thống nhúng đơn giản về mặt tính toán, thì "hiệu suất" có thể sẽ nghiêng về phía sử dụng bộ nhớ của mọi thứ. Trong khi đó một hệ thống phức tạp tính toán hoạt động trên các tập dữ liệu lớn sẽ tự xác định "hiệu suất" trong số lượng tính toán trên một đơn vị thời gian do chi phí bộ nhớ từ JVM hoặc .NET sẽ không đáng kể.

Khi bạn quyết định "hiệu suất" là gì, thì bạn có thể nói điều gì đó như "chúng ta sẽ có 50 tỷ đối tượng trong bộ nhớ tại bất kỳ thời điểm nào và techA giải thích thêm 8 byte cho mỗi đối tượng để quản lý nội bộ tương đương với chi phí bộ nhớ 400 GB so với techB không thêm dữ liệu này "

Đây là một câu hỏi kỹ thuật và bạn đã có nhiều câu trả lời kỹ thuật tốt, nhưng tôi muốn chỉ ra một khía cạnh hơi khác trong tình huống của bạn: thực tế là bạn không thể chỉ đưa ra một quyết định như "công nghệ A hoặc công nghệ B" về lý do kỹ thuật và / hoặc hiệu suất.

Các khía cạnh kỹ thuật của một cái gì đó như thế này chỉ là một phần nhỏ trong quyết định giữa A và B. Có hàng tá các yếu tố khác cần lưu ý:

• nó có liên quan đến bất kỳ chi phí cấp phép? Ví dụ: bạn phải trả (một số tiền đáng kể) để sử dụng một cụm máy SQL Server so với sử dụng cụm máy PostgreQuery.
• Tôi có nhân viên quen thuộc với công nghệ đó (stack) và hệ sinh thái của nó không? Nếu có, họ có sẵn? Nếu không, tôi có thể thuê một số? Tôi sẽ phải trả bao nhiêu cho nó? Hay tôi đào tạo những cái hiện có? Cái đó sẽ tốn bao nhiêu tiền?
• khách hàng muốn gì Đây có thể là một vấn đề rất nhiều thời gian.
• công nghệ tôi khuyên bạn đã sẵn sàng để sử dụng sản xuất chưa? Hay đó chỉ là một sự cường điệu hiện tại có thể sẽ chết? (ví dụ: nghĩ về Node.js khi nó ra mắt lần đầu tiên)
• công nghệ tôi khuyên dùng có phù hợp với kiến ​​trúc hiện có hoặc kiến ​​trúc tôi có trong đầu không? Hay tôi phải tiêu tốn rất nhiều tiền bằng cách khiến chúng hoạt động liền mạch?
• và nhiều khía cạnh khác phụ thuộc vào tình hình cụ thể của bạn.

Như bạn có thể thấy, có một TẤN thứ để xem xét khi đưa ra quyết định như vậy.

Tôi biết điều này không trả lời cụ thể câu hỏi của bạn, nhưng tôi nghĩ rằng nó mang lại cái nhìn toàn cảnh hơn về tình huống của bạn và chi tiết cụ thể của quyết định đó.

Đánh giá một phần là một khung khái niệm có liên quan để liên quan đến các thông dịch viên và trình biên dịch.

Chúng ta có thể đưa ra tuyên bố chung về hiệu suất của mã được giải thích so với mã được biên dịch không?

Ngôn ngữ lập trình là thông số kỹ thuật (được viết trong một số báo cáo, chẳng hạn như R5RS hoặc n1570 ). Chúng không phải là phần mềm, do đó, thậm chí không có ý nghĩa gì khi nói về hiệu suất . Nhưng một số ngôn ngữ lập trình có thể có một số triển khai, bao gồm trình thông dịch và trình biên dịch .

Ngay cả trong các ngôn ngữ được biên dịch theo truyền thống (nghĩa là các ngôn ngữ có triển khai thường là trình biên dịch) như C, một số phần thường được diễn giải. Ví dụ: chuỗi điều khiển định dạng của printf (được xác định trong tiêu chuẩn C) thường được "diễn giải" (bởi thư viện chuẩn C , có printf chức năng sử dụng các kỹ thuật đối số biến) nhưng một số trình biên dịch (bao gồm GCC ) có thể bị giới hạn cụ thể trường hợp - để tối ưu hóa nó và "biên dịch" nó thành các cuộc gọi cấp thấp hơn.

Và một số triển khai, ngay cả trong "trình thông dịch", đang sử dụng các kỹ thuật biên dịch JIT (để tạo mã máy khi chạy ). Một ví dụ tốt là luajit . Các triển khai khác (ví dụ Python, Ocaml, Java, Parrot, Lua) đang dịch mã nguồn thành mã byte sau đó được diễn giải.

SBCL là một "trình biên dịch" Lisp thông thường, dịch tự động mọi tương tác REPL (và gọi tới evalvv ...) thành mã máy. Vì vậy, bạn cảm thấy đó là một thông dịch viên. Hầu hết các triển khai JavaScript trong trình duyệt (ví dụ v8 ) sử dụng các kỹ thuật biên dịch JIT.

Nói cách khác, sự khác biệt giữa trình thông dịch và trình biên dịch là rất mờ (thực ra có sự liên tục giữa cả hai) và thực tế, hầu hết các triển khai ngôn ngữ lập trình thường có cả trình thông dịch và trình biên dịch (ít nhất là mã byte).

Việc triển khai có thể nhanh hoặc chậm độc lập với việc sử dụng hầu hết các "trình biên dịch" hoặc "trình thông dịch" như các kỹ thuật.

Một số đặc điểm ngôn ngữ ủng hộ cách tiếp cận phiên dịch (và chỉ có thể được biên dịch hiệu quả thông qua phân tích toàn bộ chương trình ).

Đối với một số loại vấn đề, thiết kế phần mềm với một số phương pháp siêu lập trình là đáng giá và mang lại tốc độ quan trọng. Bạn có thể tưởng tượng rằng với một số đầu vào cụ thể, chương trình của bạn sẽ tự động tạo mã chuyên dụng để xử lý nó. Điều này thậm chí có thể với C hoặc C ++ (sử dụng một số thư viện JIT hoặc tạo một số mã C, biên dịch nó dưới dạng plugin được tải động).

Xem thêm câu hỏi liên quan về Python và đó

Đối với mã như thế A = A + B, có thể biên dịch xuống một hoặc hai hướng dẫn máy, mỗi lệnh thực hiện một số chu kỳ nhất định. Không có thông dịch viên có thể làm điều tương tự trong số chu kỳ đó vì một lý do đơn giản.

Trình thông dịch cũng thực thi một tập lệnh của riêng nó (gọi chúng là mã byte, mã p, ngôn ngữ trung gian, bất cứ thứ gì). Mỗi lần nó nhìn thấy một mã byte như ADD, nó phải tìm kiếm nó bằng cách nào đó và phân nhánh đến mã thực hiện phép cộng.

Lần sau khi nhìn thấy nó, nó phải lặp lại việc tra cứu đó, trừ khi nó có cách để nhớ lần tra cứu trước. Nếu nó có cách để nhớ tra cứu trước đó, thì đó không còn là cái mà chúng ta gọi là "trình thông dịch", mà là một trình biên dịch chỉ trong thời gian, hoặc JITter.

Mặt khác...

Đối với mã như thế callSomeFunction( ... some args ...), có bao nhiêu chu kỳ được sử dụng giữa việc nhập mã đó và để lại mã? Tất cả phụ thuộc vào những gì xảy ra bên trong callSomeFunction. Nó có thể là một vài, và nó có thể là hàng nghìn tỷ, ngay cả khi callSomeFunctionnó được biên dịch. Nếu đó là rất nhiều, không có gì phải bàn cãi về chi phí giải thích của dòng mã đó - tiền ở nơi khác.

Hãy nhớ các ngôn ngữ được dịch có một giá trị của riêng chúng, chẳng hạn như, không cần phải biên dịch chúng. (Việc "biên dịch" cú pháp bề mặt thành mã byte mất thời gian không đáng kể. Lấy R hoặc MATLAB chẳng hạn.)

Ngoài ra, có sự linh hoạt cần thiết cho các cấp độ lập trình thông minh. Trong Hiệp hội Tâm trí của Minsky , Chương 6.4 B -Brains, có các chương trình A liên quan đến thế giới, và có các chương trình B liên quan đến các chương trình A, và có thể có các cấp độ khác. Các chương trình viết và quản lý các chương trình khác có thể được thực hiện dễ dàng hơn trong các hệ thống diễn giải.

Trong Lisp, bạn có thể viết (+ A B)để thêm A và B, nhưng một khi nó được viết, bạn chỉ có lựa chọn để chạy nó hay không. Bạn cũng có thể viết (eval (list '+ 'A 'B))mà xây dựng chương trình và sau đó thực hiện nó. Nó có thể xây dựng một cái gì đó khác nhau.

Chủ đề của chương trình là một chương trình khác . Điều này dễ dàng hơn để viết bằng ngôn ngữ được dịch (mặc dù, như Jorg chỉ ra, các phiên bản mới hơn của Lisp, trong khi chúng có eval, biên dịch nhanh, do đó chúng không bị phạt tốc độ khi phiên dịch).

Loại, tùy thuộc, nhưng theo quy tắc chung được biên dịch - có thể thông qua JIT hoặc được biên dịch tĩnh - môi trường sẽ nhanh hơn cho nhiều tác vụ chuyên sâu tính toán - giả sử đơn giản cùng một ngôn ngữ.

Một phần lý do là các ngôn ngữ được thông dịch cần phải có vòng lặp trình thông dịch - vòng lặp đọc một lệnh, chọn hành động thích hợp để thực hiện và thực thi nó. Trong trường hợp tốt nhất như giải thích mã Python hoặc Java (như JVM cũ đã làm), nó có một số ít hướng dẫn và chơi tàn phá với công cụ dự đoán nhánh - mà không có lệnh cuối cùng bạn có thể mong đợi những hình phạt khổng lồ do dự đoán sai. Ngay cả một JIT rất ngu ngốc cũng nên tăng tốc đáng kể.

Điều đó nói rằng ngôn ngữ giải thích có thể gian lận. Ví dụ, Matlab đã tối ưu hóa các thói quen để nhân ma trận và với một vài thay đổi bạn có thể nhận được mã chạy trên GPU (từ chối trách nhiệm: Tôi làm việc cho nVidia - mọi ý kiến ​​bày tỏ ở đây là của tôi và không đại diện cho quan điểm của chủ nhân của tôi). Bằng cách đó, bạn có thể viết mã cấp cao hơn ngắn và mạnh mẽ mà không phải lo lắng về chi tiết - ai đó đã quan tâm đến nó và đổ thời gian và tài nguyên để tối ưu hóa nó bằng ngôn ngữ cấp thấp. Không có gì được thừa hưởng về nó và nó không ngăn cản, ví dụ, Matlab để JIT mã nhưng thường không có lý do gì vì việc gọi thói quen cấp cao là tối thiểu so với thời gian ở cấp độ thấp.

TL; DR - các chương trình được biên dịch có lợi ích hiệu năng rất lớn so với các chương trình được giải thích (để so sánh táo với táo, xem PyPy Speed ). Tuy nhiên, tốc độ thực thi chỉ là một phần của vấn đề và nó có thể không đóng góp nhiều cho tốc độ chung (nếu thời gian chủ yếu dành cho các thư viện). Ngoài ra các vấn đề thực hiện.

Giả định của bạn là hoàn toàn có cơ sở, mặc dù đó là một giả định.

Tôi sẽ không đề cập đến lý do tại sao mã được biên dịch phải nhanh hơn mã được giải thích: nếu bạn biết máy tính hoạt động như thế nào, điều đó sẽ rõ ràng. Sự khác biệt có thể là thứ tự cường độ cho một số loại vấn đề nhất định. Nếu người đánh giá của bạn tranh chấp nghiêm túc về trường hợp chung đó, họ sẽ không biết họ đang nói gì.

Trường hợp họ có thể có một điểm mặc dù là sự khác biệt có ý nghĩa trong loại ứng dụng bạn đang phát triển. Nếu chủ yếu là I / O hoặc chủ yếu gọi các thư viện được biên dịch và nó không có nhiều tính toán, thì chi phí của quá trình giải thích có thể thực sự không đáng kể.

Nhưng quan điểm của bài viết của tôi là thế này: là một chuyên gia CNTT, bạn sẽ thường được gọi để đưa ra quyết định nhanh chóng dựa trên kiến ​​thức chung về cách mọi thứ nên hoạt động. Làm một bài kiểm tra cụ thể có thể giúp bạn có câu trả lời chính xác hơn, nhưng nó sẽ tốn kém hơn rất nhiều và nó sẽ không đưa bạn đến đó trước.

Nhưng theo thời gian, bạn bị bắt gặp. Nó đã xảy ra với tôi. Bạn đưa ra một giả định tốt và sau đó bạn thấy bạn thất bại khi tính đến sự ngu ngốc của thế giới.

Nhưng tôi không thể giải thích cũng như phim hoạt hình Dilbert yêu thích của tôi mọi thời đại. Không có gì thể hiện tốt hơn điều này là sự nguy hiểm của việc trở thành một người thông minh.

TL; DR: bạn nên đúng, nhưng kiểm tra thế giới thực chỉ trong trường hợp.

Trừ khi bạn sử dụng một cái gì đó hơi kỳ lạ, vấn đề của bạn sẽ không liên quan đến hiệu suất của ngôn ngữ A và ngôn ngữ được biên dịch B.

Bởi vì nếu bạn / nhóm của bạn biết A chứ không phải B và do đó viết mã tốt hơn trong A hơn B, bạn có thể có hiệu suất tốt hơn trong A so với B. Nếu bạn có người có kinh nghiệm về một ngôn ngữ và ngôn ngữ / thư viện có thể thực hiện công việc bạn cần, gắn bó với nó.

Đây là một liên kết về regex trong các ngôn ngữ khác nhau; bạn sẽ thấy regex được triển khai tốt hơn trong một số ngôn ngữ ngay cả khi được biên dịch hay không: http://benchmarkgame.alioth.debian.org/u64q/performance.php?test=regexdna

Tôi nghĩ rằng đó không phải là một ý tưởng tốt để nói về hiệu suất của hai công nghệ chỉ dựa trên thực tế là một được biên dịch và một công nghệ khác được giải thích. Như đã nêu trong các câu trả lời khác, nó có thể phụ thuộc vào lĩnh vực ứng dụng (một số ngôn ngữ có thể được tối ưu hóa để thực hiện một số thao tác rất nhanh và thực hiện những việc khác chậm hơn) cũng như kinh nghiệm của những người sắp sử dụng công nghệ đó.

Tôi không nghĩ là hợp lý khi hy vọng rằng bạn sẽ tăng hiệu suất nếu bạn sử dụng một số bộ mã hóa ngôn ngữ xuất sắc và cung cấp cho họ một số công nghệ mà họ không quen thuộc - có thể về mặt lý thuyết có thể mang lại hiệu suất tốt hơn, nhưng thực tế, không có kỹ năng và kinh nghiệm cần thiết, bạn sẽ không sử dụng tất cả các cơ hội tối ưu hóa.

Từ một trong những nhân viên nổi tiếng của công ty Thung lũng Silicon, tôi cũng đã nghe nói rằng họ thích ngôn ngữ đơn giản hơn để sử dụng vì sẽ tốn kém và rắc rối hơn khi phải trả cho một số nhà phát triển lành nghề để duy trì mã phức tạp nhưng được tối ưu hóa cao hơn là chỉ để mua thêm giàn khoan để đối phó với việc thực hiện kém hiệu quả hơn, do đó cũng nên được xem xét trong khi lựa chọn công nghệ.

Có lần tôi phải đưa ra một tuyên bố sâu rộng tương tự để biện minh cho một quyết định lớn.

Đầu tiên, họ có thể không muốn tin một kỹ sư khiêm tốn, vì vậy tôi đã tìm thấy một số bài kiểm tra điểm chuẩn tương đương và trích dẫn chúng. Có rất nhiều người trong số họ, từ những người như Microsoft, hoặc các trường đại học nổi tiếng. Và họ sẽ nói những thứ như: Phương pháp A nhanh hơn từ 3 đến 10 lần so với phương pháp B, tùy thuộc vào các biến X và Y.

Thứ hai, bạn có thể muốn chạy một điểm chuẩn của riêng bạn, có thể sử dụng một đoạn mã đại diện trong câu hỏi hoặc một cái gì đó tương tự bạn đã có. Chạy nó 1000 lần qua đêm để thực sự có một sự khác biệt có thể đo lường được.

Tại thời điểm này, sự khác biệt (hoặc thiếu nó) giữa A và B nên rõ ràng đến mức bạn chỉ phải trình bày nó. Vì vậy, định dạng kết quả rõ ràng, với sơ đồ nếu có thể, nêu rõ tất cả các giả định và xác định tất cả dữ liệu được sử dụng.

Tôi sẽ lập luận rằng bất kỳ ngôn ngữ động nào cũng có lợi thế hơn các ngôn ngữ được biên dịch tĩnh: "Tối ưu hóa thời gian chạy"

Đó là một trong những lý do Java có thể nhanh hơn C ++

Có, tải một ngôn ngữ gõ động sẽ luôn có chi phí dịch thuật và gặp bất lợi. Nhưng một khi nó đang chạy, trình thông dịch có thể cấu hình và tăng cường các đường dẫn mã thường xuyên với thông tin thời gian chạy mà các ngôn ngữ tĩnh sẽ không bao giờ có

LƯU Ý: Vâng, Java là ngôn ngữ được dịch, không phải là ngôn ngữ động. Nhưng nó là một ví dụ tuyệt vời về những gì bạn có thể tăng tốc với thông tin thời gian chạy

... Tôi cũng nói rằng vì một chương trình có thể được viết theo nhiều cách nên vẫn có thể một chương trình được viết trong công nghệ A có thể vượt trội hơn một chương trình được viết trong công nghệ B.

Khi tôi gửi báo cáo này để xem xét, người đánh giá nói rằng tôi không đưa ra lý do rõ ràng tại sao nói chung, quá trình giải thích sẽ đủ lớn để chúng tôi có thể kết luận rằng hiệu suất của B công nghệ sẽ tốt hơn. ...

Đây sẽ là cách tiếp cận của tôi:

Nói chung, các thông dịch viên được biên dịch, vì vậy mọi công nghệ được giải thích không gì khác hơn là một công nghệ được biên dịch nếu nhìn vào nó ở mức độ thấp. Do đó, các công nghệ được biên dịch chỉ là nhiều hơn và với nhiều khả năng hơn, bạn không bao giờ có thể trở nên tồi tệ hơn nếu bạn thông minh (nói chung là bạn). Nó phụ thuộc vào lượng thông tin có sẵn tại thời gian biên dịch và lượng thông tin chỉ có sẵn trong thời gian chạy và trình biên dịch và trình thông dịch tốt như thế nào, nhưng về mặt lý thuyết luôn luôn có thể bằng hiệu suất của bất kỳ trình thông dịch nào với trình biên dịch phù hợp, chỉ vì thông dịch viên được chế tạo bởi trình biên dịch. Điều đó là có thể, không có nghĩa đó là trường hợp của công nghệ A và B của bạn.

Trong thực tế, chỉ cần nói với người đánh giá về tất cả các điểm chuẩn có sẵn trong đó các hệ thống được biên dịch và giải thích được so sánh. Sau đó yêu cầu anh ấy đề xuất một trình thông dịch đánh bại thuật toán cụ thể được mã hóa tối ưu của bạn.

Có lẽ nên nói thêm rằng, bất kỳ tuyên bố chung nào như vậy đều không giúp ích gì khi so sánh hai công nghệ cụ thể A và B. Có sự lựa chọn A và B quan trọng hơn nhiều, hơn là nếu chúng được giải thích hoặc biên dịch.