C++ có nhanh hơn Java không?

Đây là những gì tôi đã học được sau hơn 20 năm làm việc với cả C++ và Java (và nhiều năm trước đó với C++)

• Theo nguyên tắc thông thường, khi bạn chuyển đổi C++ được tối ưu hóa sang Java, mã sẽ chậm hơn khoảng 3 lần
• Theo nguyên tắc thông thường, khi bạn chuyển đổi Java sang C++, mã sẽ chậm hơn khoảng 3 lần. Điều này ban đầu không có ý nghĩa gì, cho đến khi bạn cho rằng mã được viết bằng Java được "điều chỉnh" theo cách mã Java có xu hướng được viết, đó hoàn toàn không phải là cách mà bất kỳ ai làm việc trong C++ sẽ cấu trúc mã C++
• Cấu trúc dữ liệu đồng thời có xu hướng hiệu quả hơn trong Java, bởi vì JVM có thể loại bỏ các rào cản bộ nhớ và đồng bộ hóa khi cấu trúc dữ liệu không được sử dụng đồng thời và có thể làm sai lệch phương pháp quản lý đồng thời dựa trên thông tin cấu hình thời gian chạy
• Quản lý bộ nhớ động có xu hướng hiệu quả hơn trong Java, đặc biệt là nó càng bị lạm dụng nhiều hơn và đặc biệt là trong các hệ thống đa luồng
• Nội tuyến có xu hướng tốt hơn nhiều trong Java, trừ khi bạn thực hiện tối ưu hóa dựa trên trình lược tả mở rộng trong C++ (hoặc biết chính xác nội tuyến là gì và buộc nó phải như vậy. phải yêu những tập tin tiêu đề đó. )
• Các dự án lớn có xu hướng dễ dàng tối ưu hóa hơn trong Java, bởi vì JVM xử lý nhiều tối ưu hóa "toàn cầu" (chẳng hạn như khả năng nội tuyến mã được tải động) cho nhà phát triển

Trong trường hợp nào thì Java nhanh hơn, nếu có, so với C++?. ban đầu xuất hiện trên Quora. Câu trả lời tốt nhất cho bất kỳ câu hỏi. Đặt một câu hỏi, nhận được một câu trả lời tuyệt vời. Học hỏi từ các chuyên gia và tiếp cận kiến ​​thức nội bộ. Bạn có thể theo dõi Quora trên Twitter, Facebook và Google+. thêm câu hỏi

Một thử nghiệm cho thấy hiệu suất gấp đôi của mã chạy trên JVM so với mã C gốc tương đương

https. //github. com/xemantic/java-2-lần-nhanh-hơn-c

Gì???

Có thể là 2 lần, có thể là 10 lần khi mã C không được tối ưu hóa. Khó nói chính xác vì vẫn chưa hiểu tại sao nó nhanh. Giúp mình giải thích hiện tượng này với. Tôi có một giả thuyết nhưng tôi có thể hoàn toàn nhầm lẫn và tuyên bố đó có thể sai. Có lẽ điều duy nhất mà dự án này thể hiện là kỹ năng C kém của tôi, bởi vì lần cuối cùng tôi viết mã C có lẽ là 2 thập kỷ trước. Tôi tin rằng có rất nhiều không gian để cải thiện, vì vậy

Xin vui lòng cho thấy rằng tôi đã sai

Mã gần như giống nhau ở cả hai ngôn ngữ, vẫn sử dụng các quy ước điển hình của cả hai ngôn ngữ

• java_2_times_faster_than_c. c
• Java2TimesNhanh hơnC. java

Nó cũng cho thấy Java thực sự gần gũi và chịu ảnh hưởng như thế nào bởi C, và cách nó được thiết kế để chạy gần với phần cứng một cách đáng ngạc nhiên (các kiểu dữ liệu nguyên thủy). Trước tiên, mã đang thiết lập một vòng các nút, sau đó liên tục duyệt qua nó trong khi xóa các nút theo một hướng và chèn chúng vào một hướng khác

Tại sao?

Tôi đã thử viết ví dụ đơn lẻ này vì thiếu thông tin về chủ đề này trên Internet và vì trực giác của tôi xuất hiện sau kinh nghiệm xây dựng hệ thống phụ trợ cho các tổ chức khác nhau. Trong những năm này, tôi có thể quan sát sự phát triển của JVM và hiệu suất được cải thiện như thế nào, đặc biệt là trong môi trường có tính đồng thời cao và với các mô hình mới như lập trình phản ứng

Mức tăng hiệu suất điển hình như vậy là như thế nào?

Khó nói. Bạn có thể tìm thấy nhiều microbenchmark thường hiển thị JVM chậm hơn khoảng 10% -20% so với mã gốc được tối ưu hóa tương đương. Nhưng những điểm chuẩn này thường tránh cấp phát bộ nhớ, đây dường như là một vấn đề ở đây. Nhiều thuật toán biệt lập có thể được viết để tránh quản lý bộ nhớ, nhưng điều đó phản trực giác trong quy trình phát triển phần mềm chuyển tiếp nhiều trên các cấu trúc dữ liệu được tiêu chuẩn hóa có kích thước khác nhau. Vì vậy, tôi sẽ nói rằng nó có thể khá điển hình. Nếu mã của bạn đại diện cho ngăn xếp web động điển hình, với dữ liệu được truy xuất từ ​​cơ sở dữ liệu, có thể được truyền phát trực tuyến và được chuyển đổi thành JSON một cách nhanh chóng, thì mỗi yêu cầu thường bao gồm vô số phân bổ trong đường dẫn, các phân bổ này sẽ bị loại bỏ ngay lập tức ở cuối yêu cầu. Mục tiêu là giảm thiểu thời gian phản hồi và JVM dường như góp phần rất lớn vào việc đó

thần thoại

Có một số huyền thoại hiện đại liên quan đến máy ảo và quản lý bộ nhớ tự động

• thực thi mã trên VM luôn chậm hơn mã gốc
• thu gom rác luôn gây hại cho hiệu suất
• thu gom rác đang gây ra "dừng thế giới"

Không ai trong số này dường như là sự thật những ngày này

• có vẻ như mã thực thi trên VM thực sự có thể nhanh hơn nhiều so với mã gốc nhờ các công nghệ như HotSpot
• bộ sưu tập rác thực sự có thể cải thiện đáng kể hiệu suất của các thuật toán nhất định
• trên JVM GC ngày nay hầu hết diễn ra như một hoạt động song song

Bây giờ tôi có nên viết lại tất cả mã của mình bằng Java không?

Tuyệt đối không. Hiệu suất không phải là lý do duy nhất khiến chúng tôi chọn ngôn ngữ nhất định. Khi tôi bắt đầu viết mã trong JDK 1. 0. 2 (bản phát hành ổn định đầu tiên), nó chậm hơn 20 lần so với mã gốc, nhưng mã Java tôi đã biên dịch lại vào năm 1997 vẫn chỉ chạy trên JVM mới nhất của Java 15. Tôi không thể nói như vậy về mã từ thời điểm này được viết bằng Pascal, Assembler, C, C++. Lời hứa "Viết một lần, chạy mọi nơi" mà tôi đã mua Sun Microsystems huyền thoại, được giữ nguyên trong khi toàn bộ thời gian chạy và chuỗi công cụ trở thành nguồn mở. Đây là siêu năng lực thực sự của Java mà tôi muốn tri ân - nó đã giúp tôi xây dựng các hệ thống phần mềm phức tạp trong nhiều năm, với tốc độ của các trình biên dịch gia tăng vốn có trong thiết kế ngôn ngữ của huyền thoại không kém James Gosling

Ngày nay, tôi hiếm khi tự viết mã Java, thay vào đó là GLSL, JavaScript, HTML, CSS và Kotlin, cái cuối cùng vẫn thường chạy trên JVM, mặc dù với JavaScript và các mục tiêu biên dịch gốc càng tốt. IDE của tôi cũng chạy trên JVM. Đôi khi tôi dịch Java sang JavaScript. Đôi khi tôi chuyển mã JavaScript sang JavaScript. Có rất nhiều lý do có thể khác khiến bạn không nên sử dụng Java

• Bạn thành thạo một ngôn ngữ khác
• Bạn thích lập trình chức năng thuần túy hơn
• Các giải pháp dựa trên JVM có xu hướng chiếm dụng bộ nhớ cao hơn, điều này không đủ tiêu chuẩn trong nhiều hệ thống nhúng
• Đối với mã chủ yếu dựa vào mức tăng hiệu suất GPU trên CPU có thể bị bỏ qua
• vân vân

Nhưng nếu giải pháp của bạn yêu cầu một cụm gồm 100 máy chủ phía sau bộ cân bằng tải, thì bạn có thể cải thiện thời gian phản hồi trung bình từ 100 mili giây lên 50 mili giây trên cùng một phần cứng ảo trong khi tắt một nửa số máy này một cách an toàn không? . )

Tôi không phải là một fan hâm mộ lớn của microbenchmarks và so sánh ngôn ngữ thường thiên vị và gây hiểu nhầm mà không có ngữ cảnh, do đó thúc đẩy "cuộc thập tự chinh thần thánh" và "cuộc thi đo lường bộ phận sinh dục". Nhưng tôi là một người theo chủ nghĩa biểu tượng bẩm sinh, luôn háo hức so sánh huyền thoại với thực tế. Và trong thực tế, bạn sẽ thường nghe thấy "các lập luận từ hiệu suất" thường không liên quan đến ngữ cảnh mà chúng được thể hiện trong. Ngôn ngữ chỉ là công cụ. Tiếng nói thường được trân trọng trên bàn thờ của hệ tư tưởng quốc gia và những cái máy tính thường trở thành một thứ tôn sùng phong cách riêng của chúng ta mà chúng ta áp đặt lên những cái khác. Chúng ta có thể làm tốt hơn

Từ kinh nghiệm lãnh đạo các nhóm phần mềm xuất sắc của mình, tôi đã học được rằng sự thay đổi chất lượng thực tế trong hiệu suất không đến từ công nghệ cụ thể, mà là từ sự thay đổi mô hình trong kiến ​​trúc của toàn bộ hệ thống. JVM có thể là một công cụ cải tiến, nhưng nó cũng có thể bị lạm dụng một cách khủng khiếp

Java có chậm hơn C không?

C C++ hay Java cái nào nhanh hơn?

C có phải là ngôn ngữ nhanh nhất không?

C có tốt hơn Java không?

Java hay Python hay C cái nào nhanh hơn?

Java có mạnh hơn C không?