Hiệu suất Mono

Question

Có bất kỳ điểm chuẩn hiệu suất nào cho Mono so với nói Java trong GNU/Linux không?

Bạn đã bao giờ thử nghiệm hiệu suất của Mono chưa?

Answer 1

Có một bài đăng thú vị từ Miguel về điều này.

"Alvaro chỉ ra rằng trong Benchmark Language loạt đá luân lưu Mono đến ở vị trí thứ 18 so với vị trí thứ 10 của Java.

Chúng ta biết rằng độc quyền Java phiên bản của Sun (không phải là mã nguồn mở một, như mà không có nơi nào được tìm thấy) nhanh hơn Mono, nhưng tôi đã ngạc nhiên khi chúng tôi ở xa phía sau. Vì vậy, tôi đã xem xét sự so sánh giữa Java6 và Mono. "

Comparison - Java and Mono http://tirania.org/pictures/javavsmono.png

See Details Here

Answer 2

Tôi đã nhìn thấy một http://shootout.alioth.debian.org/gp4/csharp.php

Answer 3

amazedsaint>Có một bài thú vị từ Miguel về vấn đề này.

Biểu đồ đó đã lỗi thời!

Dưới đây là the current Mono C# 4.0 comparison

Answer 4

tôi benchmarked Mono 2.2 against various other VMs including OCaml, LLVM, .NET and Java:

Mono 2.2 vs OCaml vs .NET vs LLVM vs JDK http://2.bp.blogspot.com/_NMRkpon4Ps0/SYNY8YtzTCI/AAAAAAAAACg/Bkjli4JV-NU/s1600-h/scimark2_individual.gif

Nói tóm lại, Mono 2.2 là tốt hơn so với Mono 2.0 nhưng vẫn thường là một nhiều chậm hơn so với hầu hết mọi thứ khác.

Answer 5

benchmark của tôi (sử dụng các vấn đề toán học phức tạp và thao tác bộ nhớ (với chuỗi thô)):

MonoDevelop Windows (chạy trên giao diện điều khiển sử dụng .net 3.5): Realizando cálculos em 1.000.000 itens ... 535 Realizando operações com strings longas ... 2.038 Realizando cálculos em 1.000.000 itens ... 530 Realizando operações com strings longas ... 1.962 Realizando cálculos em 1.000.000 itens ... 530 Realizando operações com strings longas. .. 1.963

Sử dụng mono.exe trên Windows: Realizando cálculos em 1.000.000 itens ... 6.875 Realizando operações com strings longas ... 6.206 Realizando cálculos em 1.000.000 itens ... 6.840 Realizando operações com strings longas .. . 6,114 Realizando cálculos em 1.000.000 itens ... 6,857 Realizando operações com chuỗi longas ... 6,116

Sử dụng mono trên Linux Ubuntu: Realizando cálculos em 1.000.000 itens ... 5,934 Realizando operações com dây longas ... 6,915 Realizando cálculos em 1.000.000 mặt hàng ... 6,034 hoạt động Thực hiện với chuỗi dài ... 7489 tính toán có Hiệu suất 1.000.000 sản phẩm ... 5740 hoạt động Thực hiện với chuỗi dài ... 6.731

mã nguồn tương tự, nhưng trên Visual Studio 2008: tính toán có Hiệu suất 1.000.000 sản phẩm ... 588 hoạt động Thực hiện với chuỗi dài ... 1289 tính toán Performing 1.000.000 mục ... 566 hoạt động Thực hiện với chuỗi dài ... 1320 tính toán Performing 1.000.000 mục ... 702 hoạt động biểu diễn cùng chuỗi dài ... 1393

VS 2008 tạo ra exe với NGEN (thực thi bản địa): tính toán có Hiệu suất 1.000.000 sản phẩm ... 567 hoạt động Thực hiện với chuỗi dài ... 1255 tính toán Performing 1.000.000 mục ... 563 hoạt động Performing với chuỗi dài ... 1269 tính toán Performing 1.000.000 mục 562 ... bằng cách thực hiện các hoạt động với chuỗi dài

... 1263

trong những bài kiểm tra, mono là chậm hơn so với 10x .NET 3.5 SP 1 = (

Answer 6

C++, C# (Mono), và C Vala:

http://jpaflacerda.wordpress.com/2011/11/08/vala-benchmarking/ Nhiều ngôn ngữ

: http://attractivechaos.github.com/plb/

Kết luận: Mono phát triển rất nhiều, nhưng nó vẫn còn chậm Khi So với các ngôn ngữ có sẵn khác. Tôi đã quan tâm đến Moat, trong đó có gần như cùng một cú pháp của C# nhưng nhanh hơn so với C đồng bằng trong một số trường hợp.

Answer 7

Phiên bản mới nhất này bắn ra có thể được tìm thấy here.

Tóm lại, So với Java, Mono sử dụng ít dung lượng bộ nhớ và chạy chậm hơn một chút.

Để giữ cho mọi thứ trong quan điểm, CẢ Họ chạy về tốc độ như nhau trong các chương trình lớn của sự vật. Họ CẢ Những thử nghiệm chạy tự độ lớn nhanh hơn so với các ngôn ngữ như Ruby, LUA, Python, PHP và Perl. Cả Họ đang ở trong bóng công viên giống như Pascal, OCAML, Haskell, Lisp và khoảng một nửa họ mà làm cho nhanh như C và C++. here Nhấn vào để xem chi tiết hơn.

Để nitpick, cornichons được rõ ràng que câu trả lời của chúng tôi ở đây so sánh Java và Mono C#. Cả mono và môi trường JVM được nhắm mục tiêu bằng ngôn ngữ khác nhau và lựa chọn những vấn đề ngôn ngữ. Ví dụ, nếu chúng ta so sánh F # trên Mono với Clojure trên JVM chúng tôi có được kết quả hoàn toàn khác nhau và đột nhiên "Mono" là "faster".

Trong khi Những so sánh thú vị và nhiều thông tin, bạn phải đưa họ với một hạt muối. Thứ nhất, mặc dù một số người, hầu hết mọi người viết Java và C# code không chạy gì, nhưng các thuật toán số học trong vòng chặt chẽ. Thứ hai, trong một số Những ngôn ngữ này, các thuật toán thử nghiệm có thể chỉ được gọi vào thư viện que được viết bằng C và không có trong ngôn ngữ mục tiêu ở tất cả. Cuối cùng, các tiêu chuẩn khác (và triển khai) sẽ mang lại kết quả khác nhau có khả năng.

Tuy nhiên, nó là hợp lý để suy ra đi đó là nhanh hơn nhiều so với Ruby, C++ nhanh hơn Go, và cả Java và C# khá thực hiện khá Với cách thức chúng được sản xuất (IMHO).

Answer 8

Hầu hết các tiêu chuẩn dựa trên tính toán nặng của vòng eo hẹp. Thời gian bắt đầu đếm ngay trước vòng và dừng lại ngay sau.Nếu ứng dụng của bạn đang xử lý dữ liệu nặng thì hãy tránh cả C# và Java, chỉ cần truy cập C/C++.

Có nhiều khả năng ứng dụng của bạn sẽ ở phía máy chủ. Rằng nó sẽ phải chấp nhận các truy vấn, lấy dữ liệu và gửi lại. Trong kịch bản như vậy tốc độ thô của mã được tạo không liên quan so với các thông số khác. Bạn nên xem xét hiệu quả của khung công tác cơ bản, giai đoạn khởi tạo trước khi thực thi mã của bạn nhanh đến mức nào, việc triển khai các công nghệ hiệu quả như I/O không bị chặn như thế nào, bộ nhớ được giải phóng như thế nào và xử lý tái chế sau khi thực thi mã. Việc triển khai mã dễ dàng như thế nào, hãy tăng quy mô ...

Thông số của con người thậm chí còn quan trọng hơn tất cả. Một Java viết kém là chậm hơn C# tốt và ngược lại. Vì vậy, bạn phải kiểm tra các nhà phát triển của bạn. Ngôn ngữ nào họ làm chủ, công cụ nào họ thích hơn? Họ có VS/resharper nghiện hoặc họ có thể sử dụng Java IDE? Thời gian dành cho việc học ngôn ngữ mới hoặc IDE sẽ không được chi cho việc viết mã tốt hơn, được tối ưu hóa nhiều hơn.