Điều gì quyết định tốc độ cao của một ngôn ngữ lập trình?


38

Giả sử một chương trình được viết bằng hai ngôn ngữ riêng biệt, hãy để chúng là ngôn ngữ X và ngôn ngữ Y, nếu trình biên dịch của chúng tạo ra cùng một mã byte, tại sao tôi nên sử dụng ngôn ngữ X thay vì ngôn ngữ Y? Điều gì định nghĩa rằng một ngôn ngữ nhanh hơn ngôn ngữ khác?

Tôi hỏi điều này bởi vì bạn thường thấy mọi người nói những câu như: "C là ngôn ngữ nhanh nhất, ATS là ngôn ngữ nhanh như C". Tôi đang tìm cách hiểu định nghĩa "nhanh" cho các ngôn ngữ lập trình.


21
Nếu một chương trình nhanh hơn chương trình khác, điều đó có nghĩa là chúng không thể có cùng mã byte.
Svick 13/03/2015

5
Ngôn ngữ chỉ là một khái niệm mà người ta sử dụng để viết chương trình, vì vậy bạn không thể thực sự nói về tốc độ của ngôn ngữ.
Juho

1
@Raphael Tôi cảm thấy nó lạc đề, không rõ ràng và quá rộng. Mặc dù chủ đề phù hợp hơn với Kỹ thuật phần mềm , tôi nghi ngờ nó sẽ bị đóng vì "quá rộng" ở đó.
David Richerby 14/03/2015

2
Thực hiện sang một bên, "tốc độ" là mơ hồ, có tốc độ khác nhau để thực hiện, biên dịch, thực hiện và gỡ lỗi, và bạn thường sẽ được giao dịch tắt một số cho những người khác (nếu không chúng tôi sẽ tất cả được sử dụng các ngôn ngữ lập trình)
Nick T

Như trên. Các ngôn ngữ không tạo cùng mã byte. Một số ngôn ngữ dễ dàng phân tích thành mã byte. Một số có mức độ trừu tượng cao hơn.
siêu sáng

Câu trả lời:


23

Có nhiều lý do có thể được xem xét để chọn ngôn ngữ X trên ngôn ngữ Y. Khả năng đọc chương trình, dễ lập trình, khả năng di chuyển đến nhiều nền tảng, sự tồn tại của môi trường lập trình tốt có thể là những lý do như vậy. Tuy nhiên, tôi sẽ chỉ xem xét tốc độ thực hiện theo yêu cầu trong câu hỏi. Câu hỏi dường như không xem xét, ví dụ, tốc độ phát triển.

Hai ngôn ngữ có thể biên dịch thành cùng mã byte, nhưng điều đó không có nghĩa là cùng một mã sẽ được tạo ra,

Trên thực tế, mã byte chỉ là mã cho một máy ảo cụ thể. Nó có lợi thế về kỹ thuật, nhưng không giới thiệu những khác biệt cơ bản với việc biên dịch trực tiếp cho một phần mềm cụ thể. Vì vậy, bạn cũng có thể xem xét so sánh hai ngôn ngữ được biên dịch để thực hiện trực tiếp trên cùng một máy.

Điều này nói rằng, vấn đề về tốc độ tương đối của các ngôn ngữ là một vấn đề cũ, bắt nguồn từ các trình biên dịch đầu tiên.

Trong nhiều năm, trong những thời kỳ đầu, chuyên gia cho rằng mã viết tay nhanh hơn mã biên dịch. Nói cách khác, ngôn ngữ máy được coi là nhanh hơn các ngôn ngữ cấp cao như Cobol hoặc Fortran. Và nó là, cả nhanh hơn và thường nhỏ hơn. Các ngôn ngữ cấp cao vẫn được phát triển vì chúng dễ sử dụng hơn đối với nhiều người không phải là nhà khoa học máy tính. Chi phí sử dụng các ngôn ngữ cấp cao thậm chí có một tên: tỷ lệ mở rộng, có thể liên quan đến kích thước của mã được tạo (một vấn đề rất quan trọng trong thời gian đó) hoặc số lượng lệnh thực sự được thực thi. Khái niệm này chủ yếu là thử nghiệm, nhưng tỷ lệ ban đầu lớn hơn 1, vì các trình biên dịch đã thực hiện một công việc khá đơn giản theo tiêu chuẩn ngày nay.

Do đó, ngôn ngữ máy đã nhanh hơn nói, Fortran.

Tất nhiên, điều đó đã thay đổi qua nhiều năm, khi các trình biên dịch trở nên tinh vi hơn, đến mức lập trình bằng ngôn ngữ lắp ráp bây giờ rất hiếm. Đối với hầu hết các ứng dụng, các chương trình ngôn ngữ lắp ráp cạnh tranh kém với mã được tạo bằng cách tối ưu hóa trình biên dịch.

Điều này cho thấy một vấn đề chính là chất lượng của các trình biên dịch có sẵn cho ngôn ngữ được xem xét, khả năng phân tích mã nguồn của chúng và để tối ưu hóa nó cho phù hợp.

Khả năng này có thể phụ thuộc vào một số mở rộng về các tính năng của ngôn ngữ để nhấn mạnh các thuộc tính cấu trúc và toán học của nguồn để làm cho công việc dễ dàng hơn cho trình biên dịch. Ví dụ, một ngôn ngữ có thể cho phép bao gồm các câu lệnh về các thuộc tính đại số của các hàm do người dùng xác định, để cho phép trình biên dịch sử dụng các thuộc tính này cho mục đích tối ưu hóa.

Quá trình biên dịch có thể dễ dàng hơn, do đó tạo ra mã tốt hơn, khi mô hình lập trình của ngôn ngữ gần với các tính năng của các máy sẽ giao tiếp mã, cho dù là máy thật hay máy ảo.

Một điểm khác là liệu các mô hình được thực hiện trong ngôn ngữ có bị đóng đối với loại vấn đề đang được lập trình hay không. Người ta hy vọng rằng một ngôn ngữ lập trình chuyên biệt cho các mô hình lập trình cụ thể sẽ biên dịch các tính năng rất hiệu quả liên quan đến mô hình đó. Do đó, việc lựa chọn ngôn ngữ lập trình có thể phụ thuộc, vì sự rõ ràng và tốc độ, của sự lựa chọn ngôn ngữ lập trình phù hợp với loại vấn đề đang được lập trình.

Sự phổ biến của C đối với lập trình hệ thống có lẽ là do C gần với kiến ​​trúc máy và lập trình hệ thống cũng liên quan trực tiếp đến kiến ​​trúc đó.

Một số vấn đề khác sẽ được lập trình dễ dàng hơn, với việc thực thi nhanh hơn bằng cách sử dụng lập trình logic và ngôn ngữ phân giải ràng buộc .

Các hệ thống phản ứng phức tạp có thể được lập trình rất hiệu quả với các ngôn ngữ lập trình đồng bộ chuyên dụng như Esterel , thể hiện kiến ​​thức rất chuyên sâu về các hệ thống đó và tạo mã rất nhanh.

Hoặc lấy một ví dụ cực đoan, một số ngôn ngữ có tính chuyên môn cao, chẳng hạn như ngôn ngữ mô tả cú pháp được sử dụng để phân tích cú pháp chương trình. Một máy phát điện phân tích cú pháp là gì, nhưng một trình biên dịch cho các ngôn ngữ như vậy. Tất nhiên, nó không hoàn thành Turing, nhưng các trình biên dịch này cực kỳ tốt cho chuyên môn của họ: sản xuất các chương trình phân tích cú pháp hiệu quả. Các lĩnh vực kiến ​​thức bị hạn chế, các kỹ thuật tối ưu hóa có thể rất chuyên biệt và điều chỉnh rất tinh vi. Các trình tạo trình phân tích cú pháp này thường tốt hơn nhiều so với những gì có thể thu được bằng cách viết mã bằng ngôn ngữ khác. Có nhiều ngôn ngữ chuyên môn cao với trình biên dịch tạo ra mã xuất sắc và nhanh chóng cho một lớp vấn đề bị hạn chế.

Do đó, khi viết một hệ thống lớn, có thể không nên dựa vào một ngôn ngữ duy nhất, mà nên chọn ngôn ngữ tốt nhất cho các thành phần khác nhau của hệ thống. Điều này, tất nhiên, đặt ra vấn đề tương thích.

Một điểm khác quan trọng thường đơn giản là sự tồn tại của các thư viện hiệu quả cho các chủ đề được lập trình.

Cuối cùng, tốc độ không phải là tiêu chí duy nhất và có thể mâu thuẫn với các tiêu chí khác như an toàn mã (ví dụ như liên quan đến đầu vào xấu hoặc khả năng phục hồi các lỗi hệ thống), sử dụng bộ nhớ, dễ lập trình (mặc dù khả năng tương thích mô hình thực sự có thể giúp điều đó ), kích thước mã đối tượng, khả năng duy trì chương trình, v.v.

Tốc độ không phải lúc nào cũng là thông số quan trọng nhất. Ngoài ra, nó có thể có những chiêu bài khác nhau, như độ phức tạp có thể là độ phức tạp trung bình hoặc độ phức tạp của trường hợp xấu hơn. Ngoài ra, trong một hệ thống lớn như trong một chương trình nhỏ hơn, có những phần mà tốc độ là rất quan trọng, và những phần khác là vấn đề nhỏ. Và không phải lúc nào cũng dễ dàng xác định điều đó trước.


Cảm ơn. Nó giống như thế. Tôi đang tìm kiếm. Thật khó để tìm tài liệu cho chủ đề này. Điều này làm rõ đủ.
Rodrigo Valente

@ RodrigoAraújoValente Cảm ơn, bạn có thể muốn xem câu hỏi này . Một quan điểm cực đoan là một trình biên dịch cho ngôn ngữ L chỉ có thể bó một trình thông dịch cho L với mã nguồn của chương trình, mà không cần làm gì cả. Sau đó, bạn có thể làm tốt hơn bằng cách cố gắng tối ưu hóa tính toán của gói (đánh giá một phần). Bạn càng tối ưu hóa và ngôn ngữ của bạn sẽ càng nhanh. Câu hỏi là: điều gì có thể giúp bạn tối ưu hóa? Câu trả lời có thể bao gồm kiến thức tốt về vấn đề chuyên môn hóa, sự giúp đỡ từ lập trình viên, phân tích tinh vi, vv ...
babou

Bằng "cùng mã byte" Tôi đoán rằng bạn có nghĩa là "cùng một kiểu biểu diễn thực thi". Rõ ràng các tệp thực thi giống hệt nhau sẽ chạy ở cùng một tốc độ (giả sử cùng một hệ thống thực thi). (Tôi có thể đã xem xét điều này từ góc độ thông tin / giao tiếp. Về lý thuyết , một lập trình viên có thể biết mọi thứ về chương trình và phần cứng trong khi ngôn ngữ thường hạn chế giao tiếp (giới hạn những gì được phép hoặc không hữu ích) và trình biên dịch có thể không biết chi tiết vi kiến ​​trúc. Biên dịch và phát triển trình biên dịch có thể phân tích để phát triển và đào tạo. ...
Paul A. Clayton

Điều này sau đó đi sâu vào những gì con người nói chung là giỏi (ví dụ, nhận ra các mẫu chung) so với những gì máy tính thường giỏi (ví dụ: lưu giữ hồ sơ và "số học"). Ngoài ra, việc truyền đạt thông tin thời gian chạy thường thân thiện với máy tính hơn (tối ưu hóa theo hướng dẫn hồ sơ có thể khắc phục một số thiếu thông tin được truyền qua ngôn ngữ lập trình). Tối ưu hóa động sẽ không thực tế với các lập trình viên của con người ...
Paul A. Clayton

(mặc dù điều tương tự cũng có thể xảy ra khi viết tất cả phần mềm do các lập trình viên lành nghề nhắm vào phần cứng cụ thể, vào thời điểm phần mềm được tối ưu hóa, không chỉ phần cứng sẽ thay đổi mà phần mềm sẽ bị lỗi thời).)
Paul A. Clayton

16

Mặc dù mọi thứ cuối cùng đều chạy trên CPU * , có nhiều sự khác biệt giữa các ngôn ngữ khác nhau. Dưới đây là một số ví dụ.

Ngôn ngữ được giải thích Một số ngôn ngữ được giải thích thay vì biên dịch , ví dụ Python, Ruby và Matlab. Điều đó có nghĩa là mã Python và Ruby không biên dịch thành mã máy, mà là được giải thích nhanh chóng. Có thể biên dịch Python và Ruby thành một máy ảo (xem điểm tiếp theo). Xem thêm câu hỏi này . Giải thích nói chung là chậm hơn so với mã được biên dịch vì nhiều lý do. Việc giải thích không chỉ có thể chậm, mà còn khó thực hiện tối ưu hóa. Tuy nhiên, nếu mã của bạn dành phần lớn thời gian cho các chức năng của thư viện (trường hợp của Matlab), hiệu suất sẽ không bị ảnh hưởng.

Máy ảo Một số ngôn ngữ được biên dịch thành mã byte , một "mã máy" được phát minh sau đó được giải thích. Các ví dụ tinh túy là Java và C #. Mặc dù mã byte có thể được chuyển đổi thành mã máy khi đang di chuyển, mã có thể vẫn sẽ chạy chậm hơn. Trong trường hợp của Java, một máy ảo được sử dụng cho tính di động. Trong trường hợp của C #, có thể có các mối quan tâm khác như bảo mật.

Chi phí hiệu quả Một số ngôn ngữ cho an ninh. Ví dụ: một số phiên bản của Pascal sẽ kiểm tra xem bạn không truy cập vào một mảng ngoài giới hạn. Mã C # được "quản lý" và điều này có chi phí. Một ví dụ phổ biến khác là bộ sưu tập rác, giúp tiết kiệm thời gian cho lập trình viên nhưng không hiệu quả như quản lý bộ nhớ. Có các nguồn chi phí khác như cơ sở hạ tầng để xử lý ngoại lệ hoặc để hỗ trợ lập trình hướng đối tượng.

* Trên thực tế, ngày nay các hệ thống hiệu năng cao cũng chạy mã trên GPU và thậm chí trên các GPU.


Vì vậy, về cơ bản nếu tôi cần hiệu suất cao hơn tôi nên đi ngôn ngữ biên dịch thì sao? Còn về mô thức? Có một lý do để chọn chức năng thay vì oop, hoặc ngược lại?
Rodrigo Valente

Nhận xét của bạn về bộ sưu tập rác là một chút đơn giản. Nó không phải lúc nào cũng có thể quyết định tĩnh khi bộ nhớ được phân bổ không còn được sử dụng. Ngay cả khi có thể quyết định, có thể rất khó xác định mà không mắc lỗi. Do đó, đôi khi GC là cần thiết và thường an toàn hơn (như giới hạn kiểm tra). Hơn nữa, nó có thể được kết hợp với phát hành rõ ràng.
babou

@ RodrigoAraújoValente Phụ thuộc. Mã crappy thường sẽ biên dịch thành mã crappy. Có thể mã bạn có thể viết bằng Python thực sự nhanh hơn mã bạn có thể viết bằng C.
Raphael

nit: như được giải thích bằng câu hỏi mà bạn liên kết đến, python không thực sự được giải thích "trên đường bay" :)
Eevee

Không có ngôn ngữ nào bạn đề cập trong phần diễn giải được diễn giải nhanh chóng. Python được biên dịch thành mã byte, Ruby đã được biên dịch sang AST, nhưng tôi tin rằng bây giờ được biên dịch thành mã byte. Matlab, tôi tin rằng bây giờ thực sự là JIT được biên dịch. Trên thực tế, tôi không biết bất kỳ triển khai ngôn ngữ không thích hợp nào diễn giải mọi thứ một cách nhanh chóng, sau đó ít nhất là biên dịch thành một loại biểu diễn máy ảo nào đó.
Winston Ewert

5

Có nhiều yếu tố khác nhau để chọn X thay vì Y, như

  • Dễ học
  • Dễ hiểu
  • Tốc độ phát triển
  • Trợ giúp thực thi mã chính xác
  • Hiệu suất của mã được biên dịch
  • Môi trường nền tảng được hỗ trợ
  • Tính di động
  • Phù hợp với mục đích

Một số ngôn ngữ phù hợp để phát triển các dự án kinh doanh như C # hoặc Python, nhưng mặt khác, một số ngôn ngữ này tốt cho lập trình hệ thống như C ++.

Bạn phải xác định theo nền tảng nào bạn sẽ làm việc và ứng dụng nào bạn sẽ tạo.


1
Vì vậy, làm thế nào tôi xác định hiệu suất của mã biên dịch? Về cơ bản, điều gì đã khiến tôi làm câu hỏi này.
Rodrigo Valente

6
Câu trả lời này chắc chắn có lời khuyên tốt, nhưng tôi không thấy cách nó trả lời câu hỏi, đó là về tốc độ như là một yếu tố lựa chọn cho một ngôn ngữ.
babou

@ RodrigoAraújoValente Họ thậm chí có thể không được biên dịch mã (nếu ngôn ngữ của bạn được diễn giải).
Raphael

1
Bạn có thể muốn thêm "Thư viện tốt" và "Công cụ tốt".
Raphael

@ RodrigoAraújoValente Bạn chạy nó và hồ sơ nó.
Kyle

2

Ngôn ngữ lập trình "nhanh nhất" mà bạn có thể có với bất kỳ nền tảng nào là ngôn ngữ lắp ráp cho chipset bạn đang xử lý. Ở cấp độ đó không có bản dịch. Tuy nhiên, cần có một số kiến ​​thức về cách chipset thực hiện các hướng dẫn, đặc biệt là những cách có thể thực hiện song song.

Việc chuyển đổi từ C sang lắp ráp rất "nông" đến mức gần một nhưng nó dễ đọc hơn. Tuy nhiên, nó có rất nhiều lớp ở trên do các thư viện tiêu chuẩn để cải thiện tính di động. Không có nhiều thứ mà trình biên dịch sẽ cần phải làm để lấy mã lắp ráp và các tối ưu hóa mạnh hơn thường có để thực hiện các thay đổi cụ thể của máy.

C ++ thêm một ngôn ngữ phong phú hơn. Tuy nhiên, vì ngôn ngữ thêm quá nhiều phức tạp, trình biên dịch sẽ khó tạo mã tối ưu hơn cho nền tảng.

Sau đó, chúng tôi đi đến phía bên kia của quy mô. Giải thích ngôn ngữ. Chúng có xu hướng chậm nhất vì ngoài việc thực hiện công việc còn có một chút thời gian để phân tích mã và chuyển đổi nó thành các cuộc gọi máy.

Sau đó, chúng tôi có những người ở giữa. Nói chung, họ có một lớp máy ảo được tối ưu hóa cho nền tảng. Và trình biên dịch sẽ tạo mã cho máy ảo thực thi. Đôi khi điều này xảy ra cùng một lúc như perl hoặc pascal hoặc ruby ​​hoặc Python. Hoặc trong một số giai đoạn như java.

Một số máy ảo này thêm khái niệm về trình biên dịch JIT giúp tăng tốc thời gian chạy bằng cách tạo mã cấp độ máy thay vì dịch mã byte trung gian.

Một số máy ảo ở mức thấp cho phép dịch ít hơn từ mã byte sang mã máy. Mà tăng tốc mọi thứ trong khi giữ tính di động.


Trong lịch sử, C được thiết kế để cho phép dịch dễ dàng sang mã máy. Tuy nhiên, ở một mức độ ngày càng tăng, việc biến C thành mã C hiệu quả đòi hỏi trình biên dịch phải tìm ra những gì lập trình viên đang cố gắng thực hiện và sau đó chuyển ý định đó thành mã máy. Ví dụ, về mặt lịch sử, mã máy tương đương *p++=*q++;với nhiều máy đã nhanh hơn array1[i]=array2[i];nhưng trên nhiều bộ xử lý thì điều ngược lại thường đúng và do đó trình biên dịch có thể chuyển đổi kiểu mã cũ sang kiểu sau - hầu như không phải là chuyển đổi "nông".
supercat

Đó thường là nếu bạn làm điều -O0đó sẽ không làm bất kỳ tối ưu hóa. Tối ưu hóa là một phần thưởng bạn nhận được với trình biên dịch, nhưng bản thân ngôn ngữ có thể dịch gần một thành một để lắp ráp.
Archimedes Trajano

2

Một điểm chưa được đề cập là trong một số ngôn ngữ, việc chạy cùng một đoạn mã nhiều lần sẽ luôn thực hiện cùng một chuỗi hành động; do đó, máy tính chỉ cần xác định một lần phần mã nên làm gì. Một trong những lợi ích chính của phương ngữ "sử dụng nghiêm ngặt" của JavaScript là nó một khi công cụ JavaScript tìm ra một đoạn mã làm gì, nó có thể sử dụng thông tin đó vào lần chạy tiếp theo; không "sử dụng nghiêm ngặt" thì không thể.

Ví dụ: trong trường hợp không sử dụng "nghiêm ngặt", một đoạn mã như:

function f() { return x; }

có thể trả về một biến X trong ngữ cảnh gọi ngay lập tức, nếu có một hoặc một biến X từ bối cảnh gọi bên ngoài hoặc nó có thể trả về Undefined. Tệ hơn, trong một vòng lặp như:

for (i=0; i<40; i+=1) { g(i); }

không có cách nào để công cụ JavaScript biết những gì g()có thể làm với i[hoặc với gchính nó cho vấn đề đó. Do ghoặc ihoàn toàn có thể thay đổi ithành một chuỗi, công cụ JavaScript không thể đơn giản sử dụng phép cộng số và so sánh số trong vòng lặp, mà phải trên mỗi lần chuyển qua kiểm tra vòng lặp để xem liệu một trong các lệnh gọi hàm có thực hiện được ihay không g. Ngược lại, trong phương ngữ "sử dụng nghiêm ngặt" [hơi nghiêm túc], công cụ JavaScipt có thể kiểm tra mã ở trên và biết rằng mỗi lần đi qua vòng lặp sẽ sử dụng cùng một biến số và gọi cùng một hàm. Do đó, nó sẽ chỉ cần xác định ivà chức năngg một lần, thay vì phải tìm kiếm chúng trên mỗi lần đi qua vòng lặp - một khoản tiết kiệm thời gian lớn.


2

Vâng có một số câu trả lời khá chuyên nghiệp ở đây, câu trả lời này không gần gũi với họ nhưng có thể trực quan cho bạn.

Bạn có thể đã nghe nhiều lần rằng khi bạn cần thực hiện một nhiệm vụ càng nhanh càng tốt, bạn sẽ muốn viết mã thực thi nó trong lắp ráp. Đó là bởi vì bạn chỉ thực hiện các lệnh mà bạn thực sự cần để hoàn thành nhiệm vụ và không có gì nữa. Mặc dù ở ngôn ngữ cấp cao, bạn có thể thực hiện tác vụ này trong một số dòng, trình biên dịch vẫn cần dịch chúng sang ngôn ngữ máy. Bản dịch này không phải lúc nào cũng tối giản vì bạn có thể viết nó trực tiếp. Điều đó có nghĩa là máy sẽ dành nhiều đồng hồ để thực hiện các lệnh mà bạn có thể dự phòng.

Mặc dù các trình biên dịch rất tinh vi ngày nay nhưng chúng vẫn không hiệu quả vì các lập trình viên lắp ráp tốt nhất có thể.

Tiếp tục theo hướng này, những lệnh không cần thiết đó sẽ tăng số lượng (thường) khi ngôn ngữ được phân cấp cao hơn. (điều này không đúng 100% với tất cả các ngôn ngữ cấp cao)

Vì vậy, với tôi, ngôn ngữ X nhanh hơn ngôn ngữ Y (trong thời gian chạy) nếu với một đoạn mã nhất định, mã máy của X ngắn hơn Y.


Hội hoàn toàn đá. Nó cần một nghệ sĩ thực sự để làm tốt hơn các trình biên dịch tốt nhất mặc dù.
Johan

1

Thật khó để trả lời câu hỏi này một cách dứt khoát vì nó rất phức tạp và đa chiều (gần giống như so sánh các thương hiệu xe hơi với tiêu chí linh tinh) nhưng có những nghiên cứu khoa học mới bao gồm một kho lưu trữ mã tuyệt vời được gọi là mã Rosetta , ( tổng quan về wikipedia ). Cuộc khảo sát năm 2014 này của Nanz và Furia nghiên cứu câu hỏi này khá dứt khoát và khoa học dựa trên các tiêu chí điển hình sau đây và một phân tích định lượng hiếm hoi về phẩm chất mã chủ quan điển hình. Bản tóm tắt chứa một số phát hiện khách quan và khái quát hóa. (Hy vọng các nghiên cứu khác dựa trên những kết quả này có thể được thực hiện trong tương lai.)

  • RQ1. Những ngôn ngữ lập trình làm cho mã ngắn gọn hơn?

  • RQ2. Những ngôn ngữ lập trình biên dịch thành các tệp thực thi nhỏ hơn?

  • RQ3. Những ngôn ngữ lập trình có hiệu suất thời gian chạy tốt hơn?

  • RQ4. Những ngôn ngữ lập trình sử dụng bộ nhớ hiệu quả hơn?

  • RQ5. Những ngôn ngữ lập trình ít bị thất bại?

Tóm tắt Đôi khi các cuộc tranh luận về ngôn ngữ lập trình mang tính tôn giáo nhiều hơn là khoa học. Các câu hỏi về ngôn ngữ nào ngắn gọn hoặc hiệu quả hơn, hoặc làm cho các nhà phát triển có năng suất cao hơn được thảo luận với sự nhiệt thành và câu trả lời của họ quá thường xuyên dựa trên giai thoại và niềm tin không có căn cứ. Trong nghiên cứu này, chúng tôi sử dụng tiềm năng nghiên cứu phần lớn chưa được khai thác của Rosetta Code, kho lưu trữ mã giải pháp cho các nhiệm vụ lập trình phổ biến bằng nhiều ngôn ngữ khác nhau, cung cấp một bộ dữ liệu lớn để phân tích. Nghiên cứu của chúng tôi dựa trên 7.087 chương trình giải pháp tương ứng với 745 nhiệm vụ trong 8 ngôn ngữ được sử dụng rộng rãi đại diện cho các mô hình lập trình chính (thủ tục: C và Go; hướng đối tượng: C # và Java; chức năng: F # và Haskell; scripting: Python và Ruby). Phân tích thống kê của chúng tôi cho thấy, đáng chú ý nhất, rằng: ngôn ngữ chức năng và kịch bản ngắn gọn hơn ngôn ngữ thủ tục và hướng đối tượng; C khó bị đánh bại khi nói đến tốc độ thô trên các đầu vào lớn, nhưng sự khác biệt về hiệu suất so với các đầu vào có kích thước vừa phải ít rõ ràng hơn và cho phép các ngôn ngữ được giải thích có thể cạnh tranh được; được biên dịch các ngôn ngữ được gõ mạnh, trong đó có nhiều lỗi hơn có thể bị bắt tại thời gian biên dịch, ít bị lỗi thời gian chạy hơn so với các ngôn ngữ được dịch hoặc gõ yếu. Chúng tôi thảo luận về ý nghĩa của những kết quả này cho các nhà phát triển, nhà thiết kế ngôn ngữ và nhà giáo dục. trong đó nhiều lỗi có thể được bắt gặp tại thời gian biên dịch, ít bị lỗi thời gian chạy hơn so với các ngôn ngữ được giải thích hoặc gõ yếu. Chúng tôi thảo luận về ý nghĩa của những kết quả này cho các nhà phát triển, nhà thiết kế ngôn ngữ và nhà giáo dục. trong đó nhiều lỗi có thể được bắt gặp tại thời gian biên dịch, ít bị lỗi thời gian chạy hơn so với các ngôn ngữ được giải thích hoặc gõ yếu. Chúng tôi thảo luận về ý nghĩa của những kết quả này cho các nhà phát triển, nhà thiết kế ngôn ngữ và nhà giáo dục.


0

Ngôn ngữ máy tính chỉ là một sự trừu tượng của các lệnh để giải thích cho máy tính phải làm gì.

Bạn thậm chí có thể viết bằng ngôn ngữ máy tính Pythonvà biên dịch nó bằng trình biên dịch C (cython).

Hãy ghi nhớ điều này, tốc độ của ngôn ngữ máy tính không thể so sánh được.

Nhưng bạn có thể so sánh các trình biên dịch cho cùng một ngôn ngữ cho đến một số phần mở rộng. Ví dụ GNU Ctrình biên dịch so với Intel Ctrình biên dịch. (Tìm kiếm điểm chuẩn của trình biên dịch)


2
Nếu bạn muốn bình luận về câu hỏi, xin vui lòng sử dụng hộp bình luận, không phải câu trả lời của bạn. Lưu ý rằng đây là Khoa học máy tính stack Exchange và khoa học máy tính không được lập trình, cũng giống như văn học không phải là xử lý văn bản. Câu hỏi lập trình trực tiếp trên Kỹ thuật phần mềm hoặc Stack Overflow .
David Richerby 14/03/2015
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.