Tại sao một số ngôn ngữ lập trình lại nhanh hơn hay chậm hơn các ngôn ngữ khác?

Tôi đã nhận thấy rằng một số ứng dụng hoặc thuật toán được xây dựng trên ngôn ngữ lập trình, nói rằng C ++ / Rust chạy nhanh hơn hoặc nhanh hơn so với các ứng dụng được xây dựng trên, Java / Node.js, chạy trên cùng một máy. Tôi có một vài câu hỏi liên quan đến điều này:

1. Lý do tại sao điều này xảy ra?
2. Điều gì chi phối "tốc độ" của ngôn ngữ lập trình?
3. Điều này có liên quan gì đến quản lý bộ nhớ không?

Tôi thực sự đánh giá cao nếu ai đó phá vỡ điều này cho tôi.

Trong thiết kế và thực hiện ngôn ngữ lập trình, có một số lượng lớn các lựa chọn có thể ảnh hưởng đến hiệu suất. Tôi sẽ chỉ đề cập đến một vài.

Mỗi ngôn ngữ cuối cùng phải được chạy bằng cách thực thi mã máy. Một ngôn ngữ "được biên dịch" như C ++ được phân tích cú pháp, giải mã và dịch sang mã máy chỉ một lần, tại thời gian biên dịch. Một ngôn ngữ "được giải thích", nếu được thực hiện theo cách trực tiếp, sẽ được giải mã khi chạy, ở mọi bước, mọi lúc. Đó là, mỗi khi chúng ta chạy một câu lệnh, intepreter phải kiểm tra xem đó là if-then-other, hay gán, v.v. và hành động tương ứng. Điều này có nghĩa là nếu chúng ta lặp 100 lần, chúng ta sẽ giải mã cùng một mã 100 lần, gây lãng phí thời gian. May mắn thay, các thông dịch viên thường tối ưu hóa điều này thông qua một hệ thống biên dịch đúng lúc. (Chính xác hơn, không có thứ gọi là ngôn ngữ "được biên dịch" hoặc "được giải thích" - đó là một tài sản của việc triển khai, không phải của ngôn ngữ. Tuy nhiên,

Trình biên dịch / phiên dịch khác nhau thực hiện tối ưu hóa khác nhau.

Nếu ngôn ngữ có quản lý bộ nhớ tự động, việc thực hiện ngôn ngữ đó phải thực hiện thu gom rác. Điều này có chi phí thời gian chạy, nhưng giải phóng lập trình viên khỏi một nhiệm vụ dễ bị lỗi.

Một ngôn ngữ có thể gần với máy hơn, cho phép lập trình viên chuyên gia tối ưu hóa mọi thứ và tăng hiệu năng ra khỏi CPU. Tuy nhiên, có thể tranh cãi nếu điều này thực sự có lợi trong thực tế, vì hầu hết các lập trình viên không thực sự tối ưu hóa vi mô và thường một ngôn ngữ cấp cao tốt hơn có thể được trình biên dịch tối ưu hóa tốt hơn những gì lập trình viên trung bình sẽ làm. (Tuy nhiên, đôi khi cách xa máy hơn cũng có thể có lợi ích của nó! Ví dụ, Haskell ở mức cực kỳ cao, nhưng nhờ các lựa chọn thiết kế của nó có thể có các sợi màu xanh lá cây rất nhẹ.)

Kiểm tra loại tĩnh cũng có thể giúp tối ưu hóa. Trong một ngôn ngữ được gõ động, diễn giải, mỗi khi tính toán x - y, trình thông dịch thường phải kiểm tra xem cả hai x,ycó phải là số hay không (ví dụ) đưa ra một ngoại lệ khác. Kiểm tra này có thể được bỏ qua nếu các loại đã được kiểm tra tại thời điểm biên dịch.

Một số ngôn ngữ luôn báo cáo lỗi thời gian chạy một cách lành mạnh. Nếu bạn viết a[100]bằng Java achỉ có 20 phần tử, bạn sẽ có ngoại lệ thời gian chạy. Trong C, điều đó sẽ gây ra hành vi không xác định, có nghĩa là chương trình có thể bị sập, ghi đè một số dữ liệu ngẫu nhiên trong bộ nhớ hoặc thậm chí thực hiện hoàn toàn mọi thứ khác (tiêu chuẩn ISO C không đặt ra giới hạn nào). Điều này đòi hỏi phải kiểm tra thời gian chạy, nhưng cung cấp một ngữ nghĩa đẹp hơn nhiều cho lập trình viên.

Tuy nhiên, hãy nhớ rằng, khi đánh giá một ngôn ngữ, hiệu suất không phải là tất cả. Đừng bị ám ảnh về nó. Đó là một cái bẫy phổ biến để cố gắng tối ưu hóa mọi thứ, nhưng không phát hiện ra rằng một cấu trúc dữ liệu / thuật toán không hiệu quả đang được sử dụng. Knuth từng nói "tối ưu hóa sớm là gốc rễ của mọi tội lỗi".

Đừng đánh giá thấp việc viết một chương trình đúng như thế nào là khó . Thông thường, tốt hơn là chọn một ngôn ngữ "chậm hơn" có ngữ nghĩa thân thiện với con người hơn. Hơn nữa, nếu có một số phần quan trọng về hiệu suất cụ thể, chúng luôn có thể được thực hiện bằng ngôn ngữ khác. Chỉ là một tài liệu tham khảo, trong cuộc thi lập trình ICFP 2016 , đây là những ngôn ngữ được sử dụng bởi những người chiến thắng:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Không ai trong số họ sử dụng một ngôn ngữ duy nhất.

Điều gì chi phối "tốc độ" của ngôn ngữ lập trình?

Không có thứ gọi là "tốc độ" của ngôn ngữ lập trình. Chỉ có tốc độ của một chương trình cụ thể được viết bởi một progammer cụ thể được thực thi bởi một phiên bản cụ thể của một triển khai cụ thể của một công cụ thực thi cụ thể chạy trong một môi trường cụ thể.

Có thể có sự khác biệt lớn về hiệu năng khi chạy cùng một mã được viết bằng cùng một ngôn ngữ trên cùng một máy bằng cách sử dụng các triển khai khác nhau. Hoặc thậm chí sử dụng các phiên bản khác nhau của cùng một thực hiện. Ví dụ: chạy chuẩn ECMAScript chính xác trên cùng một máy chính xác bằng phiên bản SpiderMonkey từ 10 năm trước so với phiên bản từ năm nay có thể sẽ mang lại hiệu suất tăng bất cứ nơi nào giữa 2 × mật5 ×, thậm chí có thể là 10 ×. Điều đó có nghĩa là ECMAScript nhanh hơn 2 × so với ECMAScript, bởi vì chạy cùng một chương trình trên cùng một máy sẽ nhanh hơn 2 × với việc triển khai mới hơn? Điều đó không có ý nghĩa.

Điều này có liên quan gì đến quản lý bộ nhớ không?

Không hẳn vậy.

Lý do tại sao điều này xảy ra?

Tài nguyên. Tiền bạc. Microsoft có thể sử dụng nhiều người pha cà phê cho các lập trình viên biên dịch của họ hơn toàn bộ cộng đồng PHP, Ruby và Python kết hợp có những người làm việc trên máy ảo của họ.

Đối với nhiều hay ít bất kỳ tính năng nào của ngôn ngữ lập trình tác động đến hiệu suất theo một cách nào đó, đó cũng là một giải pháp. Ví dụ: C (Tôi đang sử dụng C ở đây để thay thế cho một lớp ngôn ngữ tương tự, một số ngôn ngữ thậm chí tồn tại trước C) không an toàn cho bộ nhớ, do đó nhiều chương trình C chạy cùng lúc có thể giẫm đạp ký ức của nhau. Vì vậy, chúng tôi phát minh ra bộ nhớ ảo và làm cho tất cả các chương trình C trải qua một lớp gián tiếp để chúng có thể giả vờ rằng chúng là những cái duy nhất chạy trên máy. Tuy nhiên, điều đó rất chậm và vì vậy, chúng tôi phát minh ra MMU và triển khai bộ nhớ ảo trong phần cứng để tăng tốc nó.

Nhưng! Ngôn ngữ an toàn bộ nhớ không cần tất cả điều đó! Có bộ nhớ ảo không giúp họ một chút. Trên thực tế, điều tồi tệ hơn: không chỉ bộ nhớ ảo không giúp các ngôn ngữ an toàn bộ nhớ, bộ nhớ ảo, ngay cả khi được triển khai trong phần cứng, vẫn ảnh hưởng đến hiệu suất. Nó có thể đặc biệt có hại đối với hiệu suất của các bộ thu gom rác (đây là số lượng đáng kể việc triển khai các ngôn ngữ an toàn bộ nhớ sử dụng).

Một ví dụ khác: CPU mục đích chung chính hiện đại sử dụng các thủ thuật tinh vi để giảm tần suất bỏ lỡ bộ đệm. Rất nhiều mánh khóe đó để cố gắng dự đoán mã nào sẽ được thực thi và bộ nhớ nào sẽ cần thiết trong tương lai. Tuy nhiên, đối với các ngôn ngữ có mức độ đa hình thời gian chạy cao (ví dụ: ngôn ngữ OO), thực sự rất khó để dự đoán các mẫu truy cập đó.

Nhưng, có một cách khác: tổng chi phí của bộ nhớ cache bị mất là số lần bỏ lỡ bộ nhớ cache nhân với chi phí của một bộ nhớ cache riêng lẻ. CPU chính thống cố gắng giảm số lần bỏ lỡ, nhưng nếu bạn có thể giảm chi phí cho một lần bỏ lỡ thì sao?

CPU Azul Vega-3 được thiết kế đặc biệt để chạy các JVM ảo hóa và nó có MMU rất mạnh với một số hướng dẫn chuyên biệt để giúp thu gom rác và phát hiện thoát (phân tích động tương đương với phân tích thoát tĩnh) và toàn bộ hệ thống vẫn có thể đạt được tiến bộ với hơn 20000 lỗi bộ nhớ cache nổi bật trong chuyến bay. Thật không may, giống như hầu hết các CPU dành riêng cho ngôn ngữ, thiết kế của nó chỉ đơn giản là bị chi tiêu và hết sức - bị ép buộc bởi "gã khổng lồ" Intel, AMD, IBM và những thứ tương tự.

Kiến trúc CPU chỉ là một ví dụ có tác động đến việc thực hiện ngôn ngữ có hiệu suất cao hay khó đến mức nào. Một ngôn ngữ như C, C ++, D, Rust phù hợp với mô hình lập trình CPU chính hiện đại sẽ dễ dàng thực hiện nhanh hơn ngôn ngữ phải "chiến đấu" và phá vỡ CPU, như Java, ECMAScript, Python, Ruby , PHP.

Thực sự, đó là tất cả một câu hỏi về tiền bạc. Nếu bạn chi số tiền bằng nhau để phát triển thuật toán hiệu năng cao trong ECMAScript, thì việc triển khai ECMAScript hiệu năng cao, một hệ điều hành hiệu năng cao được thiết kế cho ECMAScript, CPU hiệu suất cao được thiết kế cho ECMAScript đã được sử dụng trong lần trước hàng thập kỷ để làm cho các ngôn ngữ giống như C đi nhanh, sau đó bạn có thể sẽ thấy hiệu suất tương đương. Chỉ có điều, vào thời điểm này, người ta đã bỏ ra rất nhiều tiền để tạo ra các ngôn ngữ giống như C nhanh hơn là làm cho các ngôn ngữ giống như ECMAScript nhanh chóng, và các giả định của các ngôn ngữ giống như C được đưa vào toàn bộ từ MMU và CPU cho các hệ điều hành và hệ thống bộ nhớ ảo lên đến thư viện và khung.

Cá nhân tôi quen thuộc nhất với Ruby (thường được coi là "ngôn ngữ chậm"), vì vậy tôi sẽ đưa ra hai ví dụ: Hashlớp (một trong những cấu trúc dữ liệu trung tâm trong Ruby, một từ điển giá trị khóa) trong Rubinius Việc triển khai Ruby được viết bằng Ruby nguyên chất 100% và nó có hiệu suất tương đương vớiHashlớp trong YARV (triển khai được sử dụng rộng rãi nhất), được viết bằng C. Và có một thư viện xử lý hình ảnh được viết dưới dạng phần mở rộng C cho YARV, cũng có một "phiên bản dự phòng" thuần túy của Ruby để triển khai 'hỗ trợ C sử dụng rất nhiều thủ thuật Ruby rất năng động và phản xạ; một nhánh thử nghiệm của JRuby, sử dụng khung trình thông dịch Truffle AST và khung biên dịch Graal JIT của Oracle Labs, có thể thực thi phiên bản "dự phòng" thuần túy của Ruby nhanh như YARV có thể thực hiện phiên bản C được tối ưu hóa cao ban đầu. Điều này chỉ đơn giản là (tốt, bất cứ điều gì nhưng) đạt được bởi một số người thực sự thông minh thực hiện công cụ thực sự thông minh với tối ưu hóa thời gian chạy động, biên dịch JIT và đánh giá một phần.

Về mặt lý thuyết, nếu bạn viết mã giống hệt nhau trong hai ngôn ngữ và biên dịch cả hai bằng trình biên dịch "hoàn hảo", hiệu suất của cả hai sẽ giống nhau.

Trong thực tế, có một số lý do tại sao hiệu suất sẽ khác nhau:

1. Một số ngôn ngữ khó tối ưu hơn.

   Điều này bao gồm các tính năng đặc biệt làm cho mã động hơn (gõ động, phương thức ảo, con trỏ hàm), nhưng cũng có thể là bộ sưu tập rác.

   Có nhiều cách khác nhau để tạo mã bằng các tính năng như vậy nhanh chóng, nhưng nó vẫn thường kết thúc chậm hơn ít nhất là không sử dụng chúng.

2. Một số triển khai ngôn ngữ phải thực hiện một số biên dịch trong thời gian chạy.

   Điều này đặc biệt áp dụng cho các ngôn ngữ có máy ảo (như Java) và các ngôn ngữ thực thi mã nguồn, không có bước trung gian cho nhị phân (như JavaScript).

   Việc triển khai ngôn ngữ như vậy phải thực hiện nhiều công việc hơn trong thời gian chạy, điều này ảnh hưởng đến hiệu suất, đặc biệt là thời gian khởi động / hiệu suất ngay sau khi khởi động.

3. Việc triển khai ngôn ngữ cố ý dành ít thời gian hơn cho việc tối ưu hóa hơn mức có thể.

   Tất cả các trình biên dịch quan tâm đến hiệu suất của chính trình biên dịch, không chỉ mã được tạo. Điều này đặc biệt quan trọng đối với các trình biên dịch thời gian chạy (trình biên dịch JIT), trong đó mất quá nhiều thời gian để biên dịch làm chậm quá trình thực thi ứng dụng. Nhưng nó cũng áp dụng cho các trình biên dịch trước thời hạn, giống như các trình biên dịch cho C ++. Ví dụ, phân bổ đăng ký là một vấn đề hoàn chỉnh NP, do đó không thực tế để giải quyết nó một cách hoàn hảo và thay vào đó các phương pháp phỏng đoán thực thi trong thời gian hợp lý được sử dụng.

4. Sự khác biệt trong thành ngữ trong các ngôn ngữ khác nhau.

   Mã được viết theo kiểu chung cho một ngôn ngữ nhất định (mã thành ngữ) sử dụng các thư viện chung có thể dẫn đến sự khác biệt về hiệu suất, bởi vì mã thành ngữ đó hành xử khác nhau một cách tinh tế trong mỗi ngôn ngữ.

   Ví dụ, xem xét vector[i]trong C ++, list[i]trong C # và list.get(i)Java. Mã C ++ có thể không kiểm tra phạm vi và thực hiện không có cuộc gọi ảo, mã C # thực hiện kiểm tra phạm vi, nhưng không có cuộc gọi ảo và mã Java thực hiện kiểm tra phạm vi và đó là cuộc gọi ảo. Tất cả ba ngôn ngữ đều hỗ trợ các phương thức ảo và không ảo và cả C ++ và C # có thể bao gồm kiểm tra phạm vi hoặc tránh nó khi truy cập vào mảng bên dưới. Nhưng các thư viện tiêu chuẩn của các ngôn ngữ này đã quyết định viết các hàm tương đương này một cách khác nhau và do đó, hiệu suất của chúng sẽ khác nhau.

5. Một số trình biên dịch có thể thiếu một số tối ưu hóa.

   Người viết trình biên dịch có tài nguyên hữu hạn, vì vậy họ không thể thực hiện mọi tối ưu hóa có thể, thậm chí bỏ qua các vấn đề khác. Và các tài nguyên họ có thể tập trung vào một lĩnh vực tối ưu hóa hơn các lĩnh vực khác. Kết quả là, mã được viết bằng các ngôn ngữ khác nhau có thể có hiệu suất khác nhau do sự khác biệt trong trình biên dịch của chúng, ngay cả khi không có lý do cơ bản tại sao một ngôn ngữ nên nhanh hơn hoặc thậm chí dễ dàng tối ưu hóa hơn ngôn ngữ kia.

Đây là một câu hỏi rất chung chung, nhưng trong trường hợp của bạn, câu trả lời có thể đơn giản. C ++ biên dịch thành mã máy, trong đó Java biên dịch thành mã byte Java, sau đó chạy bằng máy ảo Java (mặc dù cũng có biên dịch đúng lúc, giúp biên dịch mã byte Java thành mã máy riêng). Một sự khác biệt khác có thể là bộ sưu tập rác, đó là một dịch vụ chỉ Java cung cấp.

Câu hỏi của bạn quá chung chung, vì vậy tôi e rằng tôi không thể đưa ra câu trả lời chính xác mà bạn cần.

Để giải thích tốt nhất cho tôi, chúng ta hãy nhìn vào nền tảng C ++ và .Net.

C ++, rất gần với mã máy và là một trong những chương trình ưu tiên trong thời đại cũ (như hơn 10+ năm trước?) Vì hiệu suất. Không có nhiều tài nguyên cần thiết để phát triển và thực hiện chương trình C ++ ngay cả với IDE, chúng được coi là rất nhẹ và rất nhanh. Bạn cũng có thể viết mã C ++ trong bảng điều khiển và phát triển một trò chơi từ đó. Về bộ nhớ và tài nguyên, tôi đã quên mất khoảng bao nhiêu dung lượng trong một máy tính nhưng dung lượng là thứ bạn không thể so sánh với thế hệ ngôn ngữ lập trình hiện tại.

Bây giờ hãy xem .Net. Điều kiện tiên quyết để phát triển .Net là một IDE khổng lồ không chỉ bao gồm một loại ngôn ngữ lập trình. Ngay cả khi bạn chỉ muốn nhà phát triển trong giả sử C #, IDE sẽ bao gồm nhiều nền tảng lập trình theo mặc định như J #, VB, di động và vv theo mặc định. Trừ khi bạn thực hiện cài đặt tùy chỉnh và chỉ cài đặt chính xác những gì bạn muốn, miễn là bạn đủ kinh nghiệm để chơi với cài đặt IDE.

Ngoài việc tự cài đặt phần mềm IDE, .Net còn có dung lượng lớn các thư viện và khung công tác với mục đích dễ dàng truy cập vào bất kỳ loại nền tảng nào mà các nhà phát triển cần VÀ không cần.

Phát triển trong .Net có thể là một trải nghiệm thú vị vì nhiều chức năng và thành phần phổ biến có sẵn theo mặc định. Bạn có thể kéo và thả và sử dụng nhiều phương thức xác thực, đọc tệp, truy cập cơ sở dữ liệu và nhiều hơn nữa trong IDE.

Kết quả là, đó là một sự đánh đổi giữa tài nguyên máy tính và tốc độ phát triển. Những thư viện và khung công tác chiếm bộ nhớ và tài nguyên. Khi bạn thực thi một chương trình trong .Net IDE, nó có thể tiêu tốn hàng tấn thời gian để cố gắng biên dịch các thư viện, thành phần và tất cả các tệp của bạn. Và khi bạn gỡ lỗi, máy tính của bạn cần nhiều tài nguyên để quản lý quá trình gỡ lỗi trong IDE của bạn.

Thông thường, để phát triển .Net, bạn cần một máy tính tốt với một số Ram và bộ xử lý. Nếu không, bạn cũng có thể không lập trình. Ở khía cạnh này, nền tảng C ++ tốt hơn nhiều so với .Net. Mặc dù bạn vẫn cần một máy tính tốt, nhưng dung lượng sẽ không quá đáng quan tâm so với .Net.

Hy vọng câu trả lời của tôi có thể giúp với câu hỏi của bạn. Hãy cho tôi biết trong trường hợp bạn muốn biết thêm.

BIÊN TẬP:

Chỉ cần làm rõ vấn đề chính của tôi, tôi chủ yếu trả lời cho câu hỏi "Cái gì chi phối tốc độ lập trình".

Trong quan điểm IDE, sử dụng ngôn ngữ C ++ hoặc .Net trong IDE tương đối không ảnh hưởng đến tốc độ viết mã, nhưng nó sẽ ảnh hưởng đến tốc độ phát triển vì trình biên dịch Visual Studio mất nhiều thời gian hơn để thực thi chương trình, nhưng C ++ IDE nhẹ hơn nhiều và tiêu thụ ít tài nguyên máy tính. Vì vậy, về lâu dài, bạn có thể lập trình nhanh hơn với loại IDE C ++ so với .Net IDE, điều này phụ thuộc nhiều vào thư viện và khung. Nếu bạn mất một lượng thời gian chờ đợi IDE khởi động, biên dịch, thực thi chương trình, v.v., nó sẽ ảnh hưởng đến tốc độ lập trình. Trừ khi "tốc độ lập trình" thực sự chỉ tập trung vào "tốc độ viết mã".

Số lượng thư viện và khung trong Visual Studio cũng tiêu thụ dung lượng máy tính. Tôi không chắc liệu điều này có trả lời cho câu hỏi về "quản lý bộ nhớ" hay không, nhưng tôi chỉ muốn chỉ ra rằng Visual Studio IDE có thể chiếm nhiều tài nguyên khi chạy nó, và do đó làm chậm "tốc độ lập trình" chung. Tất nhiên, điều này không liên quan gì đến "tốc độ viết mã".

Như bạn có thể đoán, tôi không biết quá nhiều về C ++ vì tôi chỉ sử dụng nó làm ví dụ, điểm chính của tôi là về loại IDE nặng của Visual Studio tiêu thụ tài nguyên máy tính.

Nếu tôi có ý tưởng và hoàn toàn không trả lời câu hỏi khởi động chủ đề, hãy xin lỗi vì bài viết dài. Nhưng tôi sẽ khuyên người khởi động chủ đề làm cho câu hỏi rõ ràng và hỏi chính xác những gì anh ấy / cô ấy cần biết về "nhanh hơn" và "chậm hơn"