2013-02-13 18 views
8

Tôi đang cung cấp băm cho bộ dữ liệu để lấy dấu vân tay dữ liệu và nhận dạng dữ liệu bằng băm - đây là trường hợp sử dụng cốt lõi cho các băm nhanh như SHA1 và MD5.Việc triển khai thực hiện bản địa của băm mật mã gốc trên Windows nhanh hơn bao nhiêu so với phiên bản .Net Managed?

Trong .Net, có một tùy chọn để đi với việc triển khai bản địa hoặc được quản lý của một số các băm này (các biến thể SHA, dù sao). Tôi đang tìm một thực hiện quản lý MD5, và có vẻ không phải là một trong. Net Framework, nhưng tự hỏi nếu CSP bản địa gói là nhanh hơn anyway, và nếu tôi chỉ nên sử dụng nó nội dung sẽ không có perf vấn đề sử dụng nó. Câu trả lời hàng đầu cho Why is there no managed MD5 implementation in the .NET framework? cho thấy hiệu suất nhanh hơn có thể là lý do khiến biến thể được quản lý không tồn tại.

Điều này có đúng không và nếu có, CSP gốc sẽ nhanh hơn bao nhiêu?

+0

Việc thực hiện MS của MD5 sucks, ít nhất là cho các chuỗi ngắn. Tôi đã tăng tốc 10 lần bằng cách p/gọi OpenSSL. – CodesInChaos

+0

Tôi rất vui khi biết điều này, vì tôi quan tâm đến việc thử nghiệm triển khai OpenSSL. – codekaizen

+0

Quảng cáo nhỏ: Nếu bạn muốn có khả năng chống va chạm (không phải MD5 hay SHA-1) hàm băm nhanh để nhận dạng tệp, thì bạn có thể xem xét Blake2. Nó được thiết kế cho kịch bản đó. Nhưng bạn sẽ cần một thư viện riêng để có hiệu suất tối đa. – CodesInChaos

Trả lời

17

Thật không may, CSP gốc được bao bọc cho MD5 - MD5CryptoServiceProvider - chậm hơn đáng kể so với triển khai được quản lý thuần túy. Nó là một quan điểm bướng bỉnh mà giữ rằng mã nguồn gốc là rõ ràng nhanh hơn so với mã được quản lý: trong nhiều trường hợp ngược lại là đúng sự thật. Đây là trường hợp như vậy, ít nhất là trong các phép đo từ đầu đến đầu.

Sử dụng translated reference MD5 implementation by David Anson, tôi đã tạo quick performance test (source) nhằm mục đích đo lường bất kỳ khác biệt lớn nào về hiệu suất giữa hai lần triển khai. Trong khi đối với mảng dữ liệu nhỏ, sự khác biệt là không đáng kể, như mong đợi, vào khoảng 16kB, việc triển khai gốc bắt đầu cho thấy sự chậm trễ đáng kể có thể xảy ra - theo thứ tự mili giây. Điều này có vẻ không nhiều, nhưng nó là đơn đặt hàng của cường độ chậm hơn so với thực hiện quản lý thuần túy. Sự khác biệt này được duy trì khi kích thước của dữ liệu được băm tăng, và tại mảng dữ liệu thử nghiệm lớn nhất - ~ 250MB - sự khác biệt về thời gian CPU là khoảng 8,5 giây. Xem xét rằng một hash như thế này thường được sử dụng để dấu vân tay các tập tin rất lớn, sự chậm trễ thêm này sẽ trở nên đáng chú ý, ngay cả đối với sự chậm trễ thường lớn hơn nhiều từ I/O.

Không rõ nơi trì hoãn xuất phát, vì thử nghiệm gốc thuần túy không được thực hiện (việc phân phối CSP và tiêu thụ trong mã được quản lý), nhưng cho hình dạng gần giống hệt nhau của biểu đồ quy mô nhật ký, có vẻ như việc triển khai gốc và được quản lý có cùng hiệu suất nội tại, nhưng hiệu suất mã gốc được "chuyển" xuống hiệu suất có khả năng do chi phí của interop giữa mã gốc và mã được quản lý khi chạy. Đây là performance difference between wrapped native CSPs and pure managed implementations has also been reproduced and documented by other investigators.

Ngoài việc trả lời câu hỏi "việc triển khai bản địa nhanh hơn bao nhiêu" trong trường hợp cụ thể này, tôi hy vọng bằng chứng này phục vụ cho prompt more reflection and investigation khi câu hỏi về phát sinh gốc và được quản lý, phá vỡ phản ứng lâu dài và nguy hiểm các câu hỏi tương tự mà mã gốc luôn nhanh hơn và do đó, bằng cách nào đó, tốt hơn. Mã được quản lý rõ ràng là rất nhanh, ngay cả trong miền băm dữ liệu số lượng lớn nhạy cảm với hiệu suất này.

MD5 Hash Computation Time MD5 Hash Computation Time (Logarithmic)

+0

'" dịch chuyển "xuống' nhưng trong không gian logarit tương ứng với chênh lệch tốc độ yếu tố không đổi. Vì vậy, nó có thể là một thực hiện bản địa xấu.Nếu được thực hiện đúng kiểu gốc phải đánh bại được quản lý có thể đo lường được trên dữ liệu lớn. – usr

+1

Vâng, đó là điểm tôi muốn thực hiện: "nó sẽ xuất hiện rằng việc triển khai được quản lý và bản địa có cùng hiệu suất nội tại". Nhưng tại sao mã gốc lại có hiệu suất cao hơn? Nếu bạn cấu hình những gì jitter đầu ra và tránh tạm dừng bộ sưu tập GC, bạn sẽ nhận được về hiệu suất tương tự trừ khi bạn đặc biệt nhắm mục tiêu hướng dẫn phần cứng/đăng ký mà jitter CLR không. Mã được quản lý không chỉ chậm hơn vì lý do ma thuật, có những điều cụ thể làm chậm nó xuống mà có thể tránh được cho mã nhạy cảm hoàn hảo. – codekaizen

+1

Vâng, tôi không đồng ý rằng quản lý và bản địa có cùng một nội tại perf và dữ liệu là bằng chứng cho điều đó. Dữ liệu là bằng chứng * chống lại * Chi phí đầu vào PInvoke ở các kích thước dữ liệu cao vì tần suất của các cuộc gọi PInvoke sẽ tiến tới 0. .NET JIT khá nghèo nói chung. Một trình biên dịch C tốt có thể vượt qua nó một cách dễ dàng. Tôi đã nghiên cứu chi tiết về mã được quản lý và nó gây thất vọng về nhiều khía cạnh. Như một ví dụ thực tế, JIT được quản lý chỉ mới nhận được hỗ trợ cho các lệnh xoay vòng (điều này chưa được phát hành). – usr

Các vấn đề liên quan