Tại sao C quá nhanh và tại sao các ngôn ngữ khác lại nhanh hay nhanh hơn? [đóng cửa]

Khi nghe podcast StackOverflow, jab tiếp tục phát hiện ra rằng "lập trình viên thực sự" viết bằng C và C nhanh hơn rất nhiều vì nó "gần với máy". Rời khỏi khẳng định trước đây cho một bài đăng khác, điều gì đặc biệt ở C cho phép nó nhanh hơn các ngôn ngữ khác? Hoặc đặt một cách khác: những gì để ngăn các ngôn ngữ khác có thể biên dịch thành nhị phân chạy nhanh như C?

Không có gì đặc biệt về C. Đó là một trong những lý do tại sao nó nhanh.

Các ngôn ngữ mới hơn có hỗ trợ thu gom rác , gõ động và các phương tiện khác giúp lập trình viên dễ dàng viết chương trình hơn.

Điều thú vị là, có thêm chi phí xử lý sẽ làm giảm hiệu suất của ứng dụng. C không có bất kỳ thứ gì trong đó, điều đó có nghĩa là không có phí, nhưng điều đó có nghĩa là lập trình viên cần có khả năng phân bổ bộ nhớ và giải phóng chúng để tránh rò rỉ bộ nhớ và phải xử lý việc gõ biến tĩnh.

Điều đó nói rằng, nhiều ngôn ngữ và nền tảng, chẳng hạn như Java (với Máy ảo Java ) và .NET (với Thời gian chạy ngôn ngữ chung) đã cải thiện hiệu suất qua nhiều năm với những tiến bộ như biên dịch đúng lúc tạo ra mã máy gốc từ mã byte để đạt được hiệu suất cao hơn.

Có một sự đánh đổi mà các nhà thiết kế C đã thực hiện. Điều đó có nghĩa là, họ đã đưa ra quyết định đưa tốc độ lên trên mức an toàn. C sẽ không

• Kiểm tra giới hạn chỉ số mảng
• Kiểm tra các giá trị biến chưa được khởi tạo
• Kiểm tra rò rỉ bộ nhớ
• Kiểm tra độ chính xác của con trỏ null

Khi bạn lập chỉ mục vào một mảng, trong Java, nó sẽ thực hiện một số cuộc gọi phương thức trong máy ảo, kiểm tra ràng buộc và kiểm tra độ tỉnh táo khác. Điều đó là hợp lệ và hoàn toàn tốt , bởi vì nó thêm an toàn khi đến hạn. Nhưng trong C, ngay cả những thứ tầm thường cũng không được an toàn. Ví dụ: C không yêu cầu memcpy để kiểm tra xem các vùng có sao chép trùng lặp hay không. Nó không được thiết kế như một ngôn ngữ để lập trình một ứng dụng kinh doanh lớn.

Nhưng những quyết định thiết kế là không lỗi trong ngôn ngữ C . Chúng là theo thiết kế, vì nó cho phép các trình biên dịch và người viết thư viện lấy mọi bit hiệu năng ra khỏi máy tính. Đây là tinh thần của C làm thế nào tài liệu C Cation giải thích nó:

Mã C có thể không di động. Mặc dù nó cố gắng tạo cơ hội cho các lập trình viên viết các chương trình di động thực sự, Ủy ban không muốn buộc các lập trình viên phải viết một cách hợp lý, để ngăn chặn việc sử dụng C như một 'trình biên dịch cấp cao' ': khả năng viết cụ thể của máy mã là một trong những điểm mạnh của C.

Giữ tinh thần của C. Ủy ban giữ mục tiêu chính là giữ gìn tinh thần truyền thống của C. Có nhiều khía cạnh của tinh thần C, nhưng bản chất là một tình cảm cộng đồng của các nguyên tắc cơ bản mà ngôn ngữ C dựa trên. Một số khía cạnh của tinh thần C có thể được tóm tắt trong các cụm từ như

• Tin tưởng lập trình viên.
• Đừng ngăn cản lập trình viên làm những gì cần phải làm.
• Giữ ngôn ngữ nhỏ và đơn giản.
• Chỉ cung cấp một cách để thực hiện một thao tác.
• Làm cho nó nhanh, ngay cả khi nó không được đảm bảo là di động.

Câu tục ngữ cuối cùng cần một lời giải thích nhỏ. Tiềm năng tạo mã hiệu quả là một trong những thế mạnh quan trọng nhất của C. Để giúp đảm bảo rằng không có vụ nổ mã nào xảy ra đối với hoạt động rất đơn giản, nhiều thao tác được xác định là cách phần cứng của máy mục tiêu thực hiện thay vì một quy tắc trừu tượng chung. Một ví dụ về sự sẵn sàng sống với những gì máy có thể được nhìn thấy trong các quy tắc chi phối việc mở rộng các đối tượng char để sử dụng trong các biểu thức: việc các giá trị của các đối tượng char mở rộng thành số lượng có dấu hoặc không dấu thường phụ thuộc vào hoạt động byte nào nhiều hơn hiệu quả trên máy mục tiêu.

Nếu bạn dành một tháng để xây dựng một cái gì đó trong C chạy trong 0,05 giây và tôi dành một ngày để viết điều tương tự bằng Java và nó chạy trong 0,10 giây, thì C có thực sự nhanh hơn không?

Nhưng để trả lời câu hỏi của bạn, được viết tốt mã C thường sẽ chạy nhanh hơn mã được viết tốt bằng các ngôn ngữ khác vì một phần của việc viết mã C "tốt" bao gồm thực hiện tối ưu hóa thủ công ở cấp độ gần máy.

Mặc dù các trình biên dịch thực sự rất thông minh, nhưng chúng chưa thể sáng tạo ra mã cạnh tranh với các thuật toán được tạo khối bằng tay (giả sử "bàn tay" thuộc về một lập trình viên giỏi C).

Biên tập:

Rất nhiều bình luận dọc theo dòng chữ "Tôi viết bằng C và tôi không nghĩ về việc tối ưu hóa."

Nhưng để lấy một ví dụ cụ thể từ bài đăng này :

Trong Delphi tôi có thể viết điều này:

function RemoveAllAFromB(a, b: string): string;
var
  before, after :string;
begin
  Result := b;
  if 0 < Pos(a,b) then begin
    before := Copy(b,1,Pos(a,b)-Length(a));
    after := Copy(b,Pos(a,b)+Length(a),Length(b));
    Result := before + after;
    Result := RemoveAllAFromB(a,Result);  //recursive
  end;
end;

và trong CI viết điều này:

char *s1, *s2, *result; /* original strings and the result string */
int len1, len2; /* lengths of the strings */
for (i = 0; i < len1; i++) {
   for (j = 0; j < len2; j++) {
     if (s1[i] == s2[j]) {
       break;
     }
   }
   if (j == len2) {  /* s1[i] is not found in s2 */
     *result = s1[i]; 
     result++; /* assuming your result array is long enough */
   }
}

Nhưng có bao nhiêu tối ưu hóa trong phiên bản C? Chúng tôi đưa ra rất nhiều quyết định về việc triển khai mà tôi không nghĩ tới trong phiên bản Delphi. Làm thế nào là một chuỗi thực hiện? Ở Delphi tôi không thấy nó. Trong C, tôi đã quyết định nó sẽ là một con trỏ tới một mảng các số nguyên ASCII, mà chúng ta gọi là ký tự. Trong C, chúng tôi kiểm tra sự tồn tại của nhân vật một lần. Trong Delphi, tôi sử dụng Pos.

Và đây chỉ là một ví dụ nhỏ. Trong một chương trình lớn, một lập trình viên C phải đưa ra các loại quyết định cấp thấp này với mỗi vài dòng mã. Nó thêm vào một thực thi thủ công, tối ưu hóa bằng tay.

Tôi không nhìn thấy nó rồi, vì vậy tôi sẽ nói nó: C có xu hướng nhanh hơn bởi vì hầu như tất cả mọi thứ khác được viết bằng C .

Java được xây dựng trên C, Python được xây dựng trên C (hoặc Java hoặc .NET, v.v.), Perl là, v.v. Hệ điều hành được viết bằng C, các máy ảo được viết bằng C, các trình biên dịch được viết bằng C, thông dịch viên được viết bằng C. Một số điều vẫn được viết bằng ngôn ngữ hội, có xu hướng thậm chí còn nhanh hơn. Ngày càng có nhiều thứ được viết bằng thứ khác, chính nó được viết bằng C.

Mỗi câu lệnh mà bạn viết bằng các ngôn ngữ khác (không phải hội) thường được triển khai bên dưới như một số câu lệnh trong C, được biên dịch thành mã máy gốc. Vì các ngôn ngữ khác có xu hướng tồn tại để đạt được mức độ trừu tượng cao hơn C, các câu lệnh bổ sung được yêu cầu trong C có xu hướng tập trung vào việc thêm an toàn, thêm độ phức tạp và cung cấp xử lý lỗi. Đó thường là những điều tốt, nhưng chúng có chi phí , và tên của nó là tốc độ và kích thước .

Cá nhân, tôi đã viết bằng hàng chục ngôn ngữ bao trùm hầu hết các phổ có sẵn và cá nhân tôi đã tìm kiếm điều kỳ diệu mà bạn gợi ý:

Làm thế nào tôi có thể có bánh của tôi và ăn nó? Làm cách nào tôi có thể chơi với các bản tóm tắt cấp cao bằng ngôn ngữ yêu thích của mình, sau đó thả xuống mức độ khó chịu của C cho tốc độ?

Sau một vài năm nghiên cứu, câu trả lời của tôi là Python (trên C). Bạn có thể muốn cho nó một cái nhìn. Nhân tiện, bạn cũng có thể thả xuống hội từ Python (với một số trợ giúp nhỏ từ một thư viện đặc biệt).

Mặt khác, mã xấu có thể được viết bằng bất kỳ ngôn ngữ nào . Do đó, mã C (hoặc hội) không tự động nhanh hơn. Tương tự như vậy, một số thủ thuật tối ưu hóa có thể mang lại các phần mã ngôn ngữ cấp cao gần với mức hiệu năng của C. Nhưng, đối với hầu hết các ứng dụng, chương trình của bạn dành phần lớn thời gian chờ đợi cho mọi người hoặc phần cứng, vì vậy sự khác biệt thực sự không quan trọng.

Thưởng thức.

Có rất nhiều câu hỏi trong đó - chủ yếu là những câu hỏi mà tôi không đủ điều kiện để trả lời. Nhưng đối với điều cuối cùng này:

Điều gì để ngăn các ngôn ngữ khác không thể biên dịch thành nhị phân chạy nhanh như C?

Trong một từ, Trừu tượng.

C chỉ là một hoặc 2 mức độ trừu tượng cách xa ngôn ngữ máy. Các ngôn ngữ Java và .Net ở mức tối thiểu 3 mức độ trừu tượng khỏi trình biên dịch chương trình. Tôi không chắc chắn về Python và Ruby.

Thông thường, càng nhiều đồ chơi lập trình (kiểu dữ liệu phức tạp, v.v.), bạn càng đến từ ngôn ngữ máy và càng phải thực hiện nhiều bản dịch.

Tôi ra khỏi đây và ở đó nhưng đó là ý chính cơ bản.

Cập nhật ------- Có một số bình luận tốt về bài đăng này với nhiều chi tiết hơn.

Không quá nhiều khi C nhanh vì mô hình chi phí của C là minh bạch . Nếu một chương trình C chậm, thì nó chậm theo một cách rõ ràng: bằng cách thực hiện rất nhiều câu lệnh. So với chi phí hoạt động trong C, hoạt động cấp cao trên các đối tượng (đặc biệt là phản xạ) hoặc chuỗi có thể có chi phí không rõ ràng.

Hai ngôn ngữ thường biên dịch thành nhị phân nhanh như C là ML chuẩn (sử dụng trình biên dịch MLton ) và Objective Caml . Nếu bạn kiểm tra trò chơi điểm chuẩn, bạn sẽ thấy rằng đối với một số điểm chuẩn, như cây nhị phân, phiên bản OCaml nhanh hơn C. (Tôi không tìm thấy bất kỳ mục MLton nào.) Nhưng đừng quá coi trọng việc bắn súng; như một trò chơi, kết quả thường phản ánh mức độ nỗ lực của mọi người trong việc điều chỉnh mã.

C không phải lúc nào cũng nhanh hơn.

C chậm hơn, ví dụ Modern Fortran.

C thường chậm hơn Java đối với một số thứ. (Đặc biệt là sau khi trình biên dịch JIT có mã của bạn)

C cho phép khử răng cưa xảy ra, điều đó có nghĩa là một số tối ưu hóa tốt là không thể. Đặc biệt khi bạn có nhiều đơn vị thực thi, điều này gây ra các quầy tìm nạp dữ liệu. Ow.

Giả định rằng công việc số học con trỏ thực sự gây ra hiệu năng cồng kềnh chậm trên một số họ CPU (đặc biệt là PIC!) Nó được sử dụng để hút số lớn trên x86 được phân đoạn.

Về cơ bản, khi bạn nhận được một đơn vị vectơ hoặc trình biên dịch song song, C hôi thối và Fortran hiện đại chạy nhanh hơn.

Các thủ thuật lập trình C như thunking (sửa đổi thực thi khi đang di chuyển) gây ra các quầy hàng tìm nạp CPU.

Bạn có được sự trôi dạt?

Và người bạn tốt của chúng tôi, x86, thực hiện một tập lệnh mà ngày nay có ít mối quan hệ với kiến ​​trúc CPU thực tế. Thanh ghi bóng, tối ưu hóa lưu trữ tải, tất cả trong CPU. Vậy C gần với kim loại ảo. Kim loại thật, Intel không cho bạn thấy. (Về mặt lịch sử, CPU của VLIW hơi ồn ào, có lẽ điều đó không tệ lắm.)

Nếu bạn lập trình trong C trên DSP hiệu suất cao (có thể là TI DSP?), Trình biên dịch phải thực hiện một số công cụ khó khăn để hủy đăng ký C qua nhiều đơn vị thực thi song song. Vì vậy, trong trường hợp đó C không gần với kim loại, nhưng nó gần với trình biên dịch, sẽ thực hiện tối ưu hóa toàn bộ chương trình. Kỳ dị.

Và cuối cùng, một số CPU (www.ajile.com) chạy mã byte Java trong phần cứng. C sẽ sử dụng PITA trên CPU đó.

Điều gì để ngăn các ngôn ngữ khác không thể biên dịch thành nhị phân chạy nhanh như C?

Không có gì. Các ngôn ngữ hiện đại như ngôn ngữ Java hoặc .NET được định hướng nhiều hơn về năng suất của lập trình viên thay vì hiệu suất. Phần cứng là ngày nay giá rẻ. Ngoài ra, việc biên dịch thành biểu diễn trung gian mang lại rất nhiều phần thưởng như bảo mật, tính di động, v.v. .NET CLR có thể tận dụng các phần cứng khác nhau - ví dụ bạn không cần phải tối ưu hóa / biên dịch lại chương trình theo cách thủ công để sử dụng bộ lệnh SSE.

Các yếu tố chính là ngôn ngữ được nhập tĩnh và được biên dịch thành mã máy. Ngoài ra, vì là ngôn ngữ cấp thấp, nên nó thường không làm bất cứ điều gì bạn không nói với nó.

Đây là một số yếu tố khác mà đến với tâm trí.

• Các biến không được tự động khởi tạo
• Không có giới hạn kiểm tra trên mảng
• Thao tác con trỏ không được kiểm tra
• Không kiểm tra tràn số nguyên
• Các biến được nhập tĩnh
• Các lệnh gọi hàm là tĩnh (trừ khi bạn sử dụng các con trỏ hàm)
• Người viết trình biên dịch đã có nhiều thời gian để cải thiện mã tối ưu hóa. Ngoài ra, mọi người lập trình trong C với mục đích đạt được hiệu suất tốt nhất, do đó có áp lực để tối ưu hóa mã.
• Các phần của đặc tả ngôn ngữ được xác định theo triển khai, vì vậy trình biên dịch có thể tự do thực hiện mọi thứ theo cách tối ưu nhất

Hầu hết các ngôn ngữ gõ tĩnh có thể được biên dịch nhanh hoặc nhanh hơn C, đặc biệt là nếu chúng có thể đưa ra các giả định mà C không thể vì bí danh con trỏ, v.v.

Tôi đoán bạn đã quên rằng ngôn ngữ hội cũng là một ngôn ngữ :)

Nhưng nghiêm túc, các chương trình C chỉ nhanh hơn khi lập trình viên biết mình đang làm gì. Bạn có thể dễ dàng viết một chương trình C chạy chậm hơn các chương trình được viết bằng các ngôn ngữ khác làm cùng một công việc.

Lý do tại sao C nhanh hơn là vì nó được thiết kế theo cách này. Nó cho phép bạn thực hiện nhiều công cụ "cấp thấp hơn" giúp trình biên dịch tối ưu hóa mã. Hoặc, chúng tôi sẽ nói, bạn lập trình viên chịu trách nhiệm tối ưu hóa mã. Nhưng nó thường khá phức tạp và dễ bị lỗi.

Các ngôn ngữ khác, như những ngôn ngữ khác đã được đề cập, tập trung nhiều hơn vào năng suất của lập trình viên. Người ta thường tin rằng thời gian lập trình viên đắt hơn nhiều so với thời gian máy (ngay cả trong thời đại cũ). Vì vậy, sẽ rất có ý nghĩa để giảm thiểu thời gian lập trình viên dành cho việc viết và gỡ lỗi chương trình thay vì thời gian chạy chương trình. Để làm điều đó, bạn sẽ hy sinh một chút về những gì bạn có thể làm để làm cho chương trình nhanh hơn vì rất nhiều thứ được tự động hóa.

Đối với hầu hết các phần, mỗi lệnh C tương ứng với một vài lệnh biên dịch hợp ngữ. Về cơ bản, bạn đang viết mã máy cấp cao hơn, vì vậy bạn có quyền kiểm soát hầu hết mọi thứ mà bộ xử lý làm. Nhiều ngôn ngữ được biên dịch khác, chẳng hạn như C ++, có rất nhiều hướng dẫn tìm kiếm đơn giản có thể biến thành nhiều mã hơn bạn nghĩ (các hàm ảo, sao chép hàm tạo, v.v.) Và các ngôn ngữ được dịch như Java hoặc Ruby có một lớp khác hướng dẫn mà bạn không bao giờ thấy - Máy ảo hoặc Trình thông dịch.

Tôi biết nhiều người đã nói điều đó một cách dài dòng, nhưng:

C nhanh hơn vì nó làm ít hơn (đối với bạn).

C ++ trung bình nhanh hơn (như ban đầu, phần lớn là siêu khối của C, mặc dù có một số khác biệt). Tuy nhiên, đối với các điểm chuẩn cụ thể, thường có một ngôn ngữ khác nhanh hơn.

https://benchmarkgame-team.pages.debian.net/benchmarkgame/

fannjuch-redux nhanh nhất ở Scala

n-bodyvà fastađã nhanh hơn trong Ada.

spectral-norm là nhanh nhất ở Fortran.

reverse-complement, mandelbrotVà pidigitslà nhanh nhất trong ATS.

regex-dna là nhanh nhất trong JavaScript.

chameneou-redux nhanh nhất là Java 7.

thread-ring là nhanh nhất trong Haskell.

Phần còn lại của điểm chuẩn là nhanh nhất trong C hoặc C ++.

Nhiều câu trả lời trong số này đưa ra lý do hợp lệ cho lý do tại sao C là, hoặc không, nhanh hơn (nói chung hoặc trong các tình huống cụ thể). Không thể phủ nhận rằng:

• Nhiều ngôn ngữ khác cung cấp các tính năng tự động mà chúng tôi được cấp. Ví dụ, kiểm tra giới hạn, kiểm tra loại thời gian chạy và quản lý bộ nhớ tự động, không đến miễn phí. Có ít nhất một số chi phí liên quan đến các tính năng này, điều mà chúng ta có thể không nghĩ về, hoặc thậm chí là nhận ra trong khi viết mã sử dụng các tính năng này.
• Bước từ nguồn đến máy thường không trực tiếp bằng các ngôn ngữ khác như trong C.
• OTOH, để nói rằng mã C được biên dịch thực thi nhanh hơn các mã khác được viết bằng các ngôn ngữ khác là một khái quát không phải lúc nào cũng đúng. Các ví dụ dễ tìm thấy (hoặc contrive).

Mặc dù vậy, có một điều khác tôi nhận thấy rằng, tôi nghĩ, ảnh hưởng đến hiệu suất so sánh của C so với nhiều ngôn ngữ khác nhiều hơn bất kỳ yếu tố nào khác. Để dí dỏm:

Các ngôn ngữ khác thường làm cho việc viết mã thực thi chậm hơn. Thông thường, nó thậm chí còn được khuyến khích bởi các triết lý thiết kế của ngôn ngữ. Hệ quả: một lập trình viên C có nhiều khả năng viết mã không thực hiện các hoạt động không cần thiết.

Ví dụ, hãy xem xét một chương trình Windows đơn giản trong đó một cửa sổ chính duy nhất được tạo. Phiên bản AC sẽ tạo ra một WNDCLASS[EX]cấu trúc sẽ được chuyển đến RegisterClass[Ex], sau đó gọi CreateWindow[Ex]và nhập một vòng lặp tin nhắn. Mã đơn giản và viết tắt cao như sau:

WNDCLASS wc;
MSG      msg;

wc.style         = 0;
wc.lpfnWndProc   = &WndProc;
wc.cbClsExtra    = 0;
wc.cbWndExtra    = 0;
wc.hInstance     = hInstance;
wc.hIcon         = NULL;
wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
wc.lpszMenuName  = NULL;
wc.lpszClassName = "MainWndCls";

RegisterClass(&wc);

CreateWindow("MainWndCls", "", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
             CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

while(GetMessage(&msg, NULL, 0, 0)){
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

Một chương trình tương đương trong C # có thể chỉ là một dòng mã:

Application.Run(new Form());

Một dòng mã này cung cấp tất cả các chức năng mà gần 20 dòng mã C đã làm và thêm một số thứ chúng tôi bỏ qua, chẳng hạn như kiểm tra lỗi. Thư viện phong phú hơn, đầy đủ hơn (so với những thư viện được sử dụng trong một dự án C điển hình) đã làm rất nhiều việc cho chúng tôi, giải phóng thời gian của chúng tôi để viết nhiều đoạn mã ngắn hơn cho chúng tôi nhưng liên quan đến nhiều bước phía sau hậu trường.

Nhưng một thư viện phong phú cho phép phình mã dễ dàng và nhanh chóng không thực sự là quan điểm của tôi. Quan điểm của tôi rõ ràng hơn khi bạn bắt đầu kiểm tra những gì thực sự xảy ra khi một lớp lót nhỏ của chúng tôi thực sự thực thi. Để giải trí, đôi khi, cho phép truy cập nguồn .NET trong Visual Studio 2008 trở lên và bước vào một dòng đơn giản ở trên. Một trong những viên ngọc nhỏ thú vị mà bạn sẽ bắt gặp là nhận xét này trong getter cho Control.CreateParams:

// In a typical control this is accessed ten times to create and show a control.
// It is a net memory savings, then, to maintain a copy on control.
// 
if (createParams == null) {
    createParams = new CreateParams(); 
} 

Mười lần . Thông tin gần tương đương với tổng của những gì được lưu trữ trong một WNDCLASSEXcấu trúc và những gì được truyền đến CreateWindowExđược lấy từ Controllớp mười lần trước khi nó được lưu trữ trong một WNDCLASSEXcấu trúc và được truyền cho RegisterClassExvàCreateWindowEx .

Nói chung, số lượng lệnh được thực thi để thực hiện nhiệm vụ rất cơ bản này là 2 lệnh3 độ lớn hơn trong C # so với C. Một phần của điều này là do việc sử dụng thư viện giàu tính năng, nhất thiết phải được khái quát hóa, so với mã C đơn giản của chúng tôi thực hiện chính xác những gì chúng tôi cần và không có gì hơn. Nhưng một phần của nó là do bản chất được mô đun hóa, hướng đối tượng của .NET framework, cho vay rất nhiều sự lặp lại của việc thực thi thường bị tránh bởi một cách tiếp cận theo thủ tục.

Tôi không cố gắng chọn C # hoặc .NET framework. Tôi cũng không nói rằng mô đun hóa, khái quát hóa, các tính năng thư viện / ngôn ngữ, OOP, vv là những điều xấu . Tôi đã từng thực hiện hầu hết sự phát triển của mình trong C, sau đó là C ++ và gần đây nhất là C #. Tương tự, trước C, tôi đã sử dụng phần lớn là lắp ráp. Và với mỗi bước "cao hơn" ngôn ngữ của tôi đi, tôi viết các chương trình tốt hơn, dễ bảo trì hơn, mạnh mẽ hơn trong thời gian ngắn hơn. Họ làm, tuy nhiên, có xu hướng thực hiện chậm hơn một chút.

Tôi không nghĩ có ai đã đề cập đến thực tế rằng nhiều nỗ lực đã được đưa vào trình biên dịch C hơn bất kỳ trình biên dịch nào khác, có lẽ ngoại trừ Java.

C cực kỳ tối ưu hóa có thể vì nhiều lý do đã được nêu - nhiều hơn hầu hết các ngôn ngữ khác. Vì vậy, nếu cùng một lượng nỗ lực được đưa vào các trình biên dịch ngôn ngữ khác, C có thể vẫn sẽ đứng đầu.

Tôi nghĩ rằng có ít nhất một ngôn ngữ ứng cử viên với nỗ lực có thể được tối ưu hóa tốt hơn C và do đó chúng ta có thể thấy các triển khai tạo ra các nhị phân nhanh hơn. Tôi đang nghĩ về sao hỏa kỹ thuật số D vì người sáng tạo đã quan tâm xây dựng một ngôn ngữ có khả năng tối ưu hóa tốt hơn C. Có thể có các ngôn ngữ khác có khả năng này. Tuy nhiên tôi không thể tưởng tượng rằng bất kỳ ngôn ngữ nào cũng sẽ có trình biên dịch nhanh hơn chỉ vài phần trăm so với trình biên dịch C tốt nhất. Tôi rất thích được sai.

Tôi nghĩ rằng "trái cây treo thấp" thực sự sẽ có trong các ngôn ngữ được thiết kế để DỄ DÀNG để con người tối ưu hóa. Một lập trình viên lành nghề có thể làm cho bất kỳ ngôn ngữ nào đi nhanh hơn - nhưng đôi khi bạn phải làm những điều lố bịch hoặc sử dụng các cấu trúc không tự nhiên để thực hiện điều này. Mặc dù sẽ luôn nỗ lực, một ngôn ngữ tốt sẽ tạo ra mã tương đối nhanh mà không phải ám ảnh chính xác cách chương trình được viết.

Điều quan trọng nữa (ít nhất là với tôi) là mã trường hợp xấu nhất có xu hướng nhanh. Có rất nhiều "bằng chứng" trên web rằng Java nhanh hoặc nhanh hơn C, nhưng điều đó dựa trên các ví dụ chọn anh đào. Tôi không phải là fan hâm mộ lớn của C, nhưng tôi biết rằng BẤT CỨ điều gì tôi viết bằng C sẽ chạy tốt. Với Java, "có thể" sẽ chạy trong vòng 15% tốc độ, thường là trong vòng 25% nhưng trong một số trường hợp, nó có thể tồi tệ hơn nhiều. Bất kỳ trường hợp nào chỉ nhanh hoặc trong một vài phần trăm thường là do phần lớn thời gian được sử dụng trong mã thư viện được tối ưu hóa C rất nhiều.

Đây thực sự là một chút sai lầm vĩnh viễn. Mặc dù sự thật là các chương trình C thường nhanh hơn, nhưng điều này không phải lúc nào cũng đúng, đặc biệt là nếu lập trình viên C không giỏi về nó.

Một lỗ hổng lớn mà mọi người có xu hướng quên là khi chương trình phải chặn một số loại IO, chẳng hạn như đầu vào của người dùng trong bất kỳ chương trình GUI nào. Trong những trường hợp này, việc bạn sử dụng ngôn ngữ nào thực sự không quan trọng vì bạn bị giới hạn bởi tốc độ dữ liệu có thể đến thay vì tốc độ bạn có thể xử lý ngôn ngữ đó. Trong trường hợp này, sẽ không có vấn đề gì nhiều nếu bạn đang sử dụng C, Java, C # hoặc thậm chí Perl; bạn không thể đi nhanh hơn dữ liệu có thể đi vào.

Một điều quan trọng khác là việc sử dụng bộ sưu tập rác và không sử dụng các con trỏ thích hợp cho phép máy ảo thực hiện một số tối ưu hóa không khả dụng trong các ngôn ngữ khác. Ví dụ, JVM có khả năng di chuyển các đối tượng xung quanh trên heap để chống phân mảnh nó. Điều này làm cho phân bổ trong tương lai nhanh hơn nhiều vì chỉ mục tiếp theo có thể được sử dụng đơn giản hơn là tìm kiếm trong bảng. Các JVM hiện đại cũng không phải thực sự giải phóng bộ nhớ; thay vào đó, họ chỉ di chuyển các đối tượng sống xung quanh khi họ GC và bộ nhớ đã sử dụng từ các đối tượng chết về cơ bản được phục hồi miễn phí.

Điều này cũng mang đến một điểm thú vị về C và thậm chí còn hơn thế trong C ++. Có một cái gì đó của triết lý thiết kế "Nếu bạn không cần nó, bạn không phải trả tiền cho nó." Vấn đề là nếu bạn muốn nó, cuối cùng bạn sẽ trả tiền qua mũi cho nó. Chẳng hạn, việc triển khai vtable trong Java có xu hướng tốt hơn rất nhiều so với triển khai C ++, vì vậy các cuộc gọi hàm ảo nhanh hơn rất nhiều. Mặt khác, bạn không có lựa chọn nào khác ngoài việc sử dụng các hàm ảo trong Java và chúng vẫn có chi phí gì đó, nhưng trong các chương trình sử dụng nhiều hàm ảo, chi phí giảm sẽ tăng thêm.

Đó không phải là quá nhiều về ngôn ngữ như các công cụ và thư viện. Các thư viện và trình biên dịch có sẵn cho C cũ hơn nhiều so với các ngôn ngữ mới hơn. Bạn có thể nghĩ rằng điều này sẽ làm cho chúng chậm hơn, nhưng au contraire.

Các thư viện này được viết vào thời điểm sức mạnh xử lý và bộ nhớ ở mức cao. Chúng phải được viết rất hiệu quả để làm việc. Các nhà phát triển trình biên dịch C cũng đã có một thời gian dài để làm việc trong tất cả các loại tối ưu hóa thông minh cho các bộ xử lý khác nhau. Sự trưởng thành và áp dụng rộng rãi của C tạo nên lợi thế đáng kể so với các ngôn ngữ khác cùng tuổi. Nó cũng mang lại cho C lợi thế về tốc độ so với các công cụ mới hơn, không nhấn mạnh hiệu năng thô nhiều như C đã có.

Sự thiếu trừu tượng là điều làm cho C nhanh hơn. Nếu bạn viết một tuyên bố đầu ra, bạn biết chính xác những gì đang xảy ra. Nếu bạn viết một câu lệnh đầu ra trong java, nó sẽ được biên dịch thành một tệp lớp và sau đó được chạy trên một máy ảo giới thiệu một lớp trừu tượng. Việc thiếu các tính năng hướng đối tượng là một phần của ngôn ngữ cũng làm tăng tốc độ của nó đối với việc tạo ra ít mã hơn. Nếu bạn sử dụng C làm ngôn ngữ hướng đối tượng thì bạn đang thực hiện tất cả mã hóa cho những thứ như lớp học, tính không đúng, v.v. Điều này có nghĩa là sau đó tạo ra một cái gì đó đủ khái quát cho mọi người với số lượng mã và bút hiệu suất yêu cầu bạn chỉ viết những gì bạn cần để hoàn thành công việc

Thật ngạc nhiên khi thấy "C / C ++ cũ phải nhanh hơn Java vì Java được hiểu" huyền thoại vẫn còn sống và đang phát triển. Có những bài báo trở lại một vài năm , cũng như những bài gần đây , giải thích với các khái niệm hoặc phép đo tại sao điều này đơn giản không phải luôn luôn như vậy .

Việc triển khai máy ảo hiện tại (và không chỉ là JVM) có thể tận dụng thông tin được thu thập trong quá trình thực thi chương trình để tự động điều chỉnh mã khi chạy, sử dụng nhiều kỹ thuật:

• kết xuất các phương thức thường xuyên với mã máy
• nội tuyến phương pháp nhỏ,
• điều chỉnh khóa

và một loạt các điều chỉnh khác dựa trên việc biết mã thực sự đang làm gì và dựa trên các đặc điểm thực tế của môi trường mà nó đang chạy.

Mã chạy nhanh nhất sẽ được mã thủ công cẩn thận. Trình biên dịch sẽ gần như tốt. Cả hai đều ở mức rất thấp và phải mất rất nhiều mã viết để làm việc. C là một chút trên lắp ráp. Bạn vẫn có khả năng kiểm soát mọi thứ ở mức rất thấp trong máy thực tế, nhưng có đủ sự trừu tượng hóa để viết nó nhanh hơn và dễ dàng hơn sau đó là trình biên dịch. Các ngôn ngữ khác như C # và JAVA thậm chí còn trừu tượng hơn. Trong khi Trình biên dịch và mã máy được gọi là ngôn ngữ cấp thấp, C # và JAVA (và nhiều ngôn ngữ khác) được gọi là ngôn ngữ cấp cao. C đôi khi được gọi là ngôn ngữ trung cấp.

Đừng lấy từ của ai đó cho nó, hãy xem phần phân tách cho cả C và ngôn ngữ bạn chọn trong bất kỳ phần quan trọng nào về hiệu suất của mã. Tôi nghĩ bạn chỉ cần nhìn vào cửa sổ tháo gỡ trong thời gian chạy trong Visual Studio để thấy .Net đã được tháo rời. Nên có thể nếu Java khó sử dụng Windbg, mặc dù nếu bạn làm điều đó với .Net thì nhiều vấn đề sẽ giống nhau.

Tôi không muốn viết bằng C nếu tôi không cần, nhưng tôi nghĩ rằng nhiều tuyên bố được đưa ra trong các câu trả lời này cho thấy tốc độ của các ngôn ngữ khác ngoài C có thể được đặt sang một bên bằng cách đơn giản tách rời cùng một thói quen trong C và trong ngôn ngữ lựa chọn cấp cao hơn của bạn, đặc biệt nếu có nhiều dữ liệu liên quan như thường thấy trong các ứng dụng quan trọng về hiệu năng. Fortran có thể là một ngoại lệ trong lĩnh vực chuyên môn của nó, không biết. Có phải cấp độ cao hơn C?

Lần đầu tiên tôi đã so sánh mã JITed với mã gốc đã giải quyết bất kỳ và tất cả các câu hỏi liệu mã .Net có thể chạy tương đương với mã C hay không. Mức độ trừu tượng thêm và tất cả các kiểm tra an toàn đi kèm với một chi phí đáng kể. Các chi phí tương tự có thể sẽ áp dụng cho Java, nhưng đừng hiểu ý tôi, hãy thử nó trên một cái gì đó mà hiệu suất là rất quan trọng. (Bất cứ ai cũng biết đủ về Java JITed để tìm một thủ tục được biên dịch trong bộ nhớ? Điều đó chắc chắn là có thể)

1) Như những người khác đã nói, C làm ít hơn cho bạn. Không khởi tạo biến, không kiểm tra giới hạn mảng, không quản lý bộ nhớ, v.v. Những tính năng trong các ngôn ngữ khác có chi phí bộ nhớ và chu kỳ CPU mà C không chi tiêu.

2) Câu trả lời nói rằng C ít trừu tượng hơn và do đó nhanh hơn chỉ đúng một nửa tôi nghĩ. Về mặt kỹ thuật, nếu bạn có "trình biên dịch đủ nâng cao" cho ngôn ngữ X, thì ngôn ngữ X có thể tiếp cận hoặc bằng tốc độ của C. Sự khác biệt với C là vì nó ánh xạ rất rõ ràng (nếu bạn đã tham gia khóa học kiến ​​trúc) và trực tiếp đến ngôn ngữ lắp ráp mà ngay cả một trình biên dịch ngây thơ cũng có thể làm một công việc tốt. Đối với một cái gì đó như Python, bạn cần một trình biên dịch rất tiên tiến để dự đoán các loại đối tượng có thể xảy ra và tạo mã máy khi đang di chuyển - ngữ nghĩa của C đủ đơn giản để trình biên dịch đơn giản có thể làm tốt.

Quay trở lại những ngày tốt lành, chỉ có hai loại ngôn ngữ: được biên dịch và giải thích.

Các ngôn ngữ được biên dịch sử dụng một "trình biên dịch" để đọc cú pháp ngôn ngữ và chuyển đổi nó thành mã ngôn ngữ lắp ráp giống hệt nhau, có thể chỉ trực tiếp trên CPU. Các ngôn ngữ được giải thích đã sử dụng một vài lược đồ khác nhau, nhưng về cơ bản, cú pháp ngôn ngữ đã được chuyển đổi thành dạng trung gian và sau đó chạy trong "trình thông dịch", một môi trường để thực thi mã.

Do đó, theo một nghĩa nào đó, có một "lớp" khác - trình thông dịch - giữa mã và máy. Và, như mọi khi trong máy tính, nhiều tài nguyên hơn có nghĩa là được sử dụng nhiều hơn. Thông dịch viên chậm hơn, vì họ phải thực hiện nhiều thao tác hơn.

Gần đây, chúng tôi đã thấy nhiều ngôn ngữ lai như Java, sử dụng cả trình biên dịch và trình thông dịch để làm cho chúng hoạt động. Nó phức tạp, nhưng một JVM nhanh hơn, tinh vi hơn và được tối ưu hóa hơn so với các trình thông dịch cũ, do đó, nó thay đổi hiệu suất tốt hơn nhiều (theo thời gian) gần hơn với mã được biên dịch thẳng. Tất nhiên, các trình biên dịch mới hơn cũng có các thủ thuật tối ưu hóa lạ mắt hơn để chúng có xu hướng tạo ra mã tốt hơn so với trước đây. Nhưng hầu hết các tối ưu hóa, thường xuyên nhất (mặc dù không phải lúc nào cũng) tạo ra một số loại đánh đổi sao cho chúng không phải lúc nào cũng nhanh hơn trong mọi hoàn cảnh. Giống như mọi thứ khác, không có gì miễn phí, vì vậy các trình tối ưu hóa phải tự hào từ đâu đó (mặc dù thường sử dụng CPU thời gian biên dịch để tiết kiệm CPU thời gian chạy).

Quay trở lại C, đó là một ngôn ngữ đơn giản, có thể được biên dịch thành tập hợp khá tối ưu hóa và sau đó chạy trực tiếp trên máy đích. Trong C, nếu bạn tăng một số nguyên, nhiều khả năng đó chỉ là một bước biên dịch trong CPU, tuy nhiên, trong Java, nó có thể sẽ còn nhiều hơn thế (và cũng có thể bao gồm một chút bộ sưu tập rác: -) C cung cấp cho bạn một bản tóm tắt gần với máy hơn (trình biên dịch là gần nhất), nhưng cuối cùng bạn phải thực hiện nhiều công việc hơn để làm cho nó hoạt động và nó không được bảo vệ, dễ sử dụng hoặc thân thiện với lỗi. Hầu hết các ngôn ngữ khác cung cấp cho bạn mức độ trừu tượng cao hơn và quan tâm nhiều hơn đến các chi tiết cơ bản cho bạn, nhưng để đổi lấy chức năng nâng cao của chúng, chúng đòi hỏi nhiều tài nguyên hơn để chạy. Khi bạn khái quát một số giải pháp, bạn phải xử lý một phạm vi rộng hơn của máy tính,

Paul.

Đặt các kỹ thuật tối ưu hóa tiên tiến như tối ưu hóa điểm nóng , thuật toán meta được biên dịch sẵn và các dạng song song khác nhau , tốc độ cơ bản của ngôn ngữ tương quan mạnh mẽ với độ phức tạp phía sau hậu trường cần thiết để hỗ trợ các hoạt động thường gặp được chỉ định trong các vòng bên trong .

Có lẽ rõ ràng nhất là kiểm tra tính hợp lệ trên các tham chiếu bộ nhớ gián tiếp - chẳng hạn như kiểm tra các con trỏ nullvà kiểm tra các chỉ mục theo các ranh giới mảng. Hầu hết các ngôn ngữ cấp cao đều thực hiện các kiểm tra này một cách ngầm định, nhưng C thì không. Tuy nhiên, đây không nhất thiết là giới hạn cơ bản của các ngôn ngữ khác - một trình biên dịch đủ thông minh có thể có khả năng loại bỏ các kiểm tra này khỏi các vòng lặp bên trong của thuật toán thông qua một số dạng chuyển động mã bất biến vòng lặp .

Ưu điểm cơ bản hơn của C (và ở một mức độ tương tự, C ++ có liên quan chặt chẽ) là sự phụ thuộc nặng nề vào phân bổ bộ nhớ dựa trên ngăn xếp , vốn đã nhanh chóng để phân bổ, phân bổ và truy cập. Trong C (và C ++), ngăn xếp cuộc gọi chính có thể được sử dụng để phân bổ các nguyên hàm, mảng và tổng hợp ( struct/ class).

Mặc dù C cung cấp khả năng phân bổ động bộ nhớ có kích thước và tuổi thọ tùy ý (sử dụng cái gọi là 'heap'), nhưng làm như vậy được tránh theo mặc định (thay vào đó ngăn xếp được sử dụng).

Tantalizingly, đôi khi có thể sao chép chiến lược cấp phát bộ nhớ C trong môi trường thời gian chạy của các ngôn ngữ lập trình khác. Điều này đã được chứng minh bởi asm.js , cho phép mã được viết bằng C hoặc C ++ được dịch sang một tập hợp con của JavaScript và chạy an toàn trong môi trường trình duyệt web - với tốc độ gần như nguyên gốc.

Như một phần của một bên, một lĩnh vực khác mà C và C ++ vượt trội hơn hầu hết các ngôn ngữ khác về tốc độ là khả năng tích hợp liền mạch với các bộ hướng dẫn máy gốc. Một ví dụ đáng chú ý ở đây là tính khả dụng (phụ thuộc vào trình biên dịch và nền tảng) của nội tại SIMD hỗ trợ xây dựng các thuật toán tùy chỉnh tận dụng phần cứng xử lý song song gần như phổ biến hiện nay - trong khi vẫn sử dụng các tóm tắt phân bổ dữ liệu do ngôn ngữ cung cấp (thấp hơn phân bổ đăng ký -level được quản lý bởi trình biên dịch).

Tôi đã tìm thấy Câu trả lời trên liên kết về lý do tại sao một số ngôn ngữ nhanh hơn và một số ngôn ngữ chậm hơn, tôi hy vọng điều này sẽ làm rõ hơn lý do tại sao C hoặc C ++ nhanh hơn các ngôn ngữ khác, Có một số ngôn ngữ khác cũng nhanh hơn C, nhưng chúng tôi không thể sử dụng tất cả chúng Một số giải thích -

Một trong những lý do lớn mà Fortran vẫn quan trọng là vì nó nhanh: các thói quen giòn số được viết bằng Fortran có xu hướng nhanh hơn các thói quen tương đương được viết bằng hầu hết các ngôn ngữ khác. Các ngôn ngữ đang cạnh tranh với Fortran trong không gian này C và C ++ - được sử dụng vì chúng cạnh tranh với hiệu suất này.

Điều này đặt ra câu hỏi: tại sao? Điều gì về C ++ và Fortran giúp chúng phát triển nhanh và tại sao chúng lại vượt trội hơn các ngôn ngữ phổ biến khác, như Java hay Python?

Phiên dịch so với biên dịch Có nhiều cách để phân loại và xác định ngôn ngữ lập trình, theo phong cách lập trình mà họ khuyến khích và các tính năng họ cung cấp. Khi nhìn vào hiệu suất, sự khác biệt lớn nhất là giữa các ngôn ngữ được dịch và các ngôn ngữ được biên dịch.

Sự phân chia không khó; đúng hơn là có một quang phổ. Cuối cùng, chúng tôi có các ngôn ngữ được biên dịch truyền thống, một nhóm bao gồm Fortran, C và C ++. Trong các ngôn ngữ này, có một giai đoạn biên dịch rời rạc để dịch mã nguồn của chương trình thành một dạng thực thi mà bộ xử lý có thể sử dụng.

Quá trình biên dịch này có một số bước. Mã nguồn được phân tích và phân tích cú pháp. Các lỗi mã hóa cơ bản như lỗi chính tả và lỗi chính tả có thể được phát hiện tại thời điểm này. Mã được phân tích cú pháp được sử dụng để tạo ra một biểu diễn trong bộ nhớ, cũng có thể được sử dụng để phát hiện lỗi lỗi Lần này, các lỗi ngữ nghĩa, chẳng hạn như các hàm gọi không tồn tại hoặc cố gắng thực hiện các phép toán số học trên chuỗi văn bản.

Đại diện trong bộ nhớ này sau đó được sử dụng để điều khiển một trình tạo mã, phần tạo ra mã thực thi. Tối ưu hóa mã, để cải thiện hiệu suất của mã được tạo, được thực hiện tại nhiều thời điểm trong quy trình này: tối ưu hóa mức cao có thể được thực hiện trên biểu diễn mã và tối ưu hóa cấp thấp hơn được sử dụng trên đầu ra của trình tạo mã.

Trên thực tế việc thực thi mã xảy ra sau đó. Toàn bộ quá trình biên dịch được sử dụng đơn giản để tạo ra một cái gì đó có thể được thực thi.

Ở phía đối diện, chúng tôi có phiên dịch viên. Các trình thông dịch sẽ bao gồm một giai đoạn phân tích cú pháp tương tự như trình biên dịch, nhưng điều này sau đó được sử dụng để thúc đẩy thực thi trực tiếp, với chương trình được chạy ngay lập tức.

Trình thông dịch đơn giản nhất có mã thực thi tương ứng với các tính năng khác nhau mà ngôn ngữ hỗ trợ, vì vậy nó sẽ có các chức năng để thêm số, nối chuỗi, bất cứ ngôn ngữ nào khác có. Khi nó phân tích mã, nó sẽ tra cứu hàm tương ứng và thực thi nó. Các biến được tạo trong chương trình sẽ được lưu trong một loại bảng tra cứu ánh xạ tên của chúng vào dữ liệu của chúng.

Ví dụ cực đoan nhất của kiểu trình thông dịch là một cái gì đó giống như một tệp bó hoặc tập lệnh shell. Trong các ngôn ngữ này, mã thực thi thường không được tích hợp vào chính trình thông dịch, mà là các chương trình độc lập, riêng biệt.

Vậy tại sao điều này tạo ra sự khác biệt cho hiệu suất? Nói chung, mỗi lớp của indirection làm giảm hiệu suất. Ví dụ, cách nhanh nhất để thêm hai số là có cả hai số đó trong các thanh ghi trong bộ xử lý và sử dụng lệnh thêm của bộ xử lý. Đó là những gì chương trình biên dịch có thể làm; họ có thể đặt các biến vào các thanh ghi và tận dụng các hướng dẫn của bộ xử lý. Nhưng trong các chương trình được giải thích, cùng một phép cộng có thể yêu cầu hai lần tra cứu trong một bảng các biến để tìm nạp các giá trị để thêm, sau đó gọi một hàm để thực hiện phép cộng. Hàm đó rất có thể sử dụng cùng một lệnh xử lý như chương trình đã biên dịch sử dụng để thực hiện bổ sung thực tế, nhưng tất cả các công việc bổ sung trước khi lệnh thực sự có thể được sử dụng làm cho mọi thứ chậm hơn.

Nếu bạn muốn biết thêm xin vui lòng kiểm tra Nguồn

Một số thuật toán C ++ nhanh hơn C và một số triển khai thuật toán hoặc mẫu thiết kế trong các ngôn ngữ khác có thể nhanh hơn C.

Khi mọi người nói rằng C nhanh, và sau đó chuyển sang nói về một số ngôn ngữ khác, họ thường sử dụng hiệu suất của C làm điểm chuẩn.

Với các trình biên dịch tối ưu hóa hiện đại, rất khó có khả năng một chương trình C thuần túy sẽ nhanh hơn nhiều so với mã .net được biên dịch, nếu có. Với việc tăng cường năng suất mà các khuôn khổ như .net cung cấp các nhà phát triển, bạn có thể làm mọi thứ trong một ngày được sử dụng để mất vài tuần hoặc vài tháng trong C. thường xuyên Cùng với chi phí rẻ của phần cứng so với mức lương của một nhà phát triển, nó chỉ là CÁCH rẻ hơn để ghi các công cụ trong một ngôn ngữ cấp cao và ném phần cứng ở bất kỳ sự chậm chạp.

Lý do Jeff và Joel nói về C là ngôn ngữ "lập trình viên thực sự" là vì không có người nắm tay trong C. Bạn phải phân bổ bộ nhớ của riêng mình, phân bổ bộ nhớ đó, kiểm tra giới hạn của chính bạn, v.v. như đối tượng mới (); Không có bộ sưu tập rác, các lớp, OOP, khung thực thể, LINQ, thuộc tính, thuộc tính, trường hoặc bất cứ thứ gì tương tự. Bạn phải biết những thứ như số học con trỏ và làm thế nào để hủy bỏ con trỏ. Và, đối với vấn đề đó, biết và hiểu con trỏ là gì. Bạn phải biết khung stack là gì và con trỏ lệnh là gì. Bạn phải biết mô hình bộ nhớ của kiến ​​trúc CPU mà bạn đang làm việc. Có rất nhiều sự hiểu biết ngầm về kiến ​​trúc của một máy vi tính (thường là làmáy vi tính bạn đang làm việc) khi lập trình trong C mà đơn giản là không có mặt hoặc không cần thiết khi lập trình trong một cái gì đó như C # hoặc Java. Tất cả thông tin đó đã được tải xuống cho trình lập trình biên dịch (hoặc VM).

Đó là sự khác biệt giữa tự động và thủ công, ngôn ngữ cấp cao hơn là trừu tượng do đó tự động. C / C ++ được điều khiển và xử lý thủ công, thậm chí mã kiểm tra lỗi đôi khi là lao động thủ công.

C và C ++ cũng là các ngôn ngữ được biên dịch, có nghĩa là không có ngôn ngữ nào hoạt động ở mọi nơi, các ngôn ngữ này phải được tinh chỉnh cho phần cứng bạn làm việc với do đó thêm một lớp gotcha bổ sung. Mặc dù hiện tại điều này hơi khó hiểu vì trình biên dịch C / C ++ đang trở nên phổ biến hơn trên tất cả các nền tảng. Bạn có thể thực hiện các phần tổng hợp chéo giữa các nền tảng. Đây vẫn không phải là tình huống chạy ở mọi nơi, về cơ bản, trình biên dịch A của bạn sẽ biên dịch theo trình biên dịch B cùng mã với kiến ​​trúc khác nhau.

Các ngôn ngữ C dòng dưới cùng không có nghĩa là dễ hiểu hoặc lý do, đây cũng là lý do tại sao chúng được gọi là ngôn ngữ hệ thống. Họ đi ra trước tất cả những điều vô nghĩa trừu tượng cấp cao này. Đây cũng là lý do tại sao chúng không được sử dụng cho lập trình web front end. Họ chỉ không phù hợp với nhiệm vụ, ý nghĩa của họ để giải quyết các vấn đề phức tạp không thể giải quyết bằng công cụ ngôn ngữ thông thường.

Đây là lý do tại sao bạn có được những thứ điên rồ như (kiến trúc vi mô, trình điều khiển, vật lý lượng tử, Trò chơi AAA, hệ điều hành) có những thứ C và C ++ rất phù hợp. Tốc độ và số giòn là lĩnh vực chính.

C nhanh vì nó được biên dịch nguyên bản, ngôn ngữ cấp thấp. Nhưng C không phải là nhanh nhất. Các đệ quy Fibonacci Benchmark cho thấy Rust, Crystal, và Nim có thể nhanh hơn.

Có nhiều lý do, bao gồm:

• Nó biên dịch thành ngôn ngữ lắp ráp.
• Nó được gõ tĩnh.
• Không thu gom rác.
• Không xử lý lỗi.
• Nhiều ngôn ngữ lập trình thêm các tính năng mới. Một phần trong triết lý của C là giữ mọi thứ đơn giản thay vì thêm nhiều tính năng.