Đây là một câu hỏi rất khó và một câu hỏi mà tôi thường xuyên xử lý, khi tôi trao đổi mã khác nhau trong một gói để tăng tốc mọi thứ. Đôi khi một hồi quy hiệu suất đi kèm với một sự thay đổi trong thuật toán hoặc thực hiện, nhưng nó cũng có thể phát sinh do những thay đổi trong cấu trúc dữ liệu được sử dụng.
Luồng công việc tốt để phát hiện hồi quy hiệu suất trong gói R là gì?
Trong trường hợp của tôi, tôi có xu hướng có các trường hợp sử dụng rất cụ thể mà tôi đang cố gắng tăng tốc, với các tập dữ liệu cố định khác nhau. Như Spacedman đã viết, điều quan trọng là phải có một hệ thống tính toán cố định, nhưng điều đó gần như không khả thi: đôi khi một máy tính dùng chung có thể có các tiến trình khác làm chậm 10-20%, ngay cả khi nó trông khá nhàn rỗi.
bước của tôi:
- Chuẩn nền tảng (ví dụ: một hoặc một vài máy, một máy ảo cụ thể, hoặc một máy ảo + cơ sở hạ tầng cụ thể, EC2 loại dụ của một la Amazon).
- Chuẩn hóa tập dữ liệu sẽ được sử dụng để kiểm tra tốc độ.
- Tạo tập lệnh và đầu ra dữ liệu trung gian cố định (ví dụ: được lưu vào tệp .rdat) có liên quan đến việc chuyển đổi dữ liệu rất nhỏ. Trọng tâm của tôi là trên một số loại mô hình hóa, chứ không phải là thao tác hoặc chuyển đổi dữ liệu. Điều này có nghĩa là tôi muốn cung cấp chính xác cùng một khối dữ liệu cho các hàm mô hình hóa. Tuy nhiên, nếu chuyển đổi dữ liệu là mục tiêu, thì hãy đảm bảo rằng dữ liệu được chuyển đổi trước/được điều khiển càng gần với tiêu chuẩn trong các thử nghiệm của các phiên bản khác nhau của gói. (Xem this question để biết ví dụ về ghi nhớ, lưu vào bộ nhớ cache, v.v., có thể được sử dụng để chuẩn hóa hoặc tăng tốc độ tính toán không tập trung. Nó tham chiếu một số gói của OP.)
- Lặp lại các phép thử nhiều lần.
- Chia tỷ lệ các kết quả liên quan đến điểm chuẩn cố định, ví dụ: thời gian thực hiện hồi quy tuyến tính, để sắp xếp ma trận, v.v. Điều này có thể cho phép biến đổi "cục bộ" hoặc tạm thời trong cơ sở hạ tầng, chẳng hạn như I/O, hệ thống bộ nhớ, gói phụ thuộc, v.v.
Kiểm tra đầu ra hồ sơ càng mạnh càng tốt (xem this question để biết một số thông tin chi tiết, cũng tham khảo các công cụ từ OP).
Lý tưởng nhất là tôi đang tìm thứ gì đó tích hợp với R CMD kiểm tra thông báo cho tôi khi tôi đã giới thiệu hồi quy hiệu suất đáng kể trong mã của mình.
Thật không may, tôi không có câu trả lời cho điều này.
Quy trình làm việc tốt nói chung là gì?
Đối với tôi, nó khá giống với thử nghiệm mã động chung: là đầu ra (thời gian thực thi trong trường hợp này) có thể tái tạo, tối ưu và minh bạch không? Minh bạch đến từ sự hiểu biết những gì ảnh hưởng đến thời gian tổng thể. Đây là nơi những gợi ý của Mike Dunlavey là quan trọng, nhưng tôi thích đi xa hơn, với một trình biên dịch dòng.
Về trình bày sơ đồ đường, xem my previous question, đề cập đến các tùy chọn trong Python và Matlab cho các ví dụ khác. Điều quan trọng nhất là kiểm tra thời gian đồng hồ, nhưng cũng rất quan trọng để theo dõi phân bổ bộ nhớ, số lần dòng được thực hiện và gọi độ sâu ngăn xếp.
Ngôn ngữ nào khác cung cấp các công cụ tốt?
Hầu như tất cả các ngôn ngữ khác đều có công cụ tốt hơn. :) Các ngôn ngữ được giải thích như Python và Matlab có các ví dụ & tốt có thể là các ví dụ quen thuộc về các công cụ có thể được điều chỉnh cho mục đích này. Mặc dù phân tích động là rất quan trọng, phân tích tĩnh có thể giúp xác định nơi có thể có một số vấn đề nghiêm trọng. Matlab có một máy phân tích tĩnh tuyệt vời có thể báo cáo khi các đối tượng (ví dụ: vectơ, ma trận) đang phát triển bên trong vòng lặp, chẳng hạn. Thật kinh khủng khi tìm thấy điều này chỉ thông qua phân tích động - bạn đã lãng phí thời gian thực hiện để khám phá điều gì đó như thế này và không phải lúc nào cũng rõ ràng nếu ngữ cảnh thực thi của bạn khá đơn giản (ví dụ: chỉ một vài lần lặp hoặc đối tượng nhỏ).
Theo như phương pháp ngôn ngữ-agnostic, bạn có thể xem xét:
- Valgrind & cachegrind
- Giám sát của đĩa I/O, bộ đệm bẩn vv
- Giám sát RAM (Cachegrind là hữu ích, nhưng bạn chỉ có thể theo dõi phân bổ RAM và rất nhiều chi tiết về việc sử dụng RAM)
- Sử dụng nhiều lõi
Có phải thứ gì đó có thể được xây dựng trên thử nghiệm đơn vị hàng đầu hay thường được thực hiện riêng?
Điều này khó trả lời. Để phân tích tĩnh, nó có thể xảy ra trước khi thử nghiệm đơn vị. Đối với phân tích động, người ta có thể muốn thêm nhiều thử nghiệm hơn. Hãy suy nghĩ về nó như thiết kế tuần tự (nghĩa là từ một khung thiết kế thử nghiệm): nếu chi phí thực hiện xuất hiện, trong một số phụ cấp thống kê cho biến thể, giống nhau, thì không cần kiểm tra thêm. Tuy nhiên, nếu phương pháp B có vẻ có chi phí thực hiện trung bình lớn hơn phương pháp A, thì một phương pháp nên thực hiện các thử nghiệm chuyên sâu hơn.
Cập nhật 1: Nếu tôi có thể quá táo bạo, có một câu hỏi mà tôi muốn khuyên bạn nên bao gồm cả, đó là: "Một số vấn đề khi so sánh thời gian thực hiện hai phiên bản của một gói phần mềm là gì? " Điều này tương tự với giả định rằng hai chương trình thực hiện cùng một thuật toán phải có cùng một đối tượng trung gian. Điều đó không chính xác đúng (xem this question - không phải là tôi đang quảng bá câu hỏi của riêng mình, ở đây - nó chỉ là công việc khó khăn để làm cho mọi thứ tốt hơn và nhanh hơn ... dẫn đến nhiều câu hỏi SO về chủ đề này :)). Theo cách tương tự, hai lần thực thi cùng một mã có thể khác nhau về thời gian tiêu thụ do các yếu tố khác ngoài việc thực hiện.
Vì vậy, một số gotchas có thể xảy ra, hoặc trong cùng một ngôn ngữ hoặc qua ngôn ngữ, trong trường hợp thực hiện cùng một hoặc qua các trường hợp "giống hệt nhau", có thể ảnh hưởng đến thời gian chạy:
- Thu gom rác - triển khai khác nhau hoặc ngôn ngữ có thể nhấn vào bộ sưu tập rác trong các trường hợp khác nhau. Điều này có thể làm cho hai thực thi xuất hiện khác nhau, mặc dù nó có thể rất phụ thuộc vào ngữ cảnh, tham số, tập hợp dữ liệu, vv Việc thực thi GC-ám ảnh sẽ trông chậm hơn.
- Cache ở cấp đĩa, bo mạch chủ (ví dụ: L1, L2, L3 cache) hoặc các cấp khác (ví dụ: ghi nhớ). Thông thường, việc thực hiện đầu tiên sẽ phải trả tiền phạt.
- Dynamic voltage scaling - Cái này hút. Khi có vấn đề, đây có thể là một trong những thú vật khó tìm nhất, vì nó có thể biến mất nhanh chóng. Nó trông giống như bộ nhớ đệm, nhưng nó không phải là.
- Bất kỳ người quản lý ưu tiên công việc nào mà bạn không biết.
- Một phương pháp sử dụng nhiều lõi hoặc thực hiện một số công cụ thông minh về cách thức hoạt động được sắp xếp giữa các lõi hoặc CPU. Ví dụ, nhận được một quá trình bị khóa vào một lõi có thể hữu ích trong một số kịch bản. Việc thực thi gói R có thể rất may mắn về vấn đề này, một gói khác có thể rất thông minh ...
- Biến không sử dụng, chuyển dữ liệu quá mức, bộ đệm bẩn, bộ đệm không bị xóa, ... danh sách tiếp tục.
Kết quả chính là: Lý tưởng nhất, chúng ta nên kiểm tra sự khác biệt về giá trị mong đợi như thế nào tùy thuộc vào độ ngẫu nhiên do hiệu ứng đặt hàng? Vâng, khá đơn giản: quay trở lại thiết kế thử nghiệm. :)
Khi chênh lệch thực nghiệm trong thời gian thực thi khác với sự khác biệt "mong đợi", thật tuyệt vời khi bật tính năng giám sát hệ thống và thực thi bổ sung để chúng tôi không phải chạy lại thử nghiệm cho đến khi chúng tôi có màu xanh vào mặt.
Khéo léo. Bạn thậm chí có thể không chạy thử nghiệm trên cùng một máy tính như trước đây, do đó, nó sẽ phải tương đối so với một số điểm chuẩn ổn định ... – Spacedman
* [Phương pháp này] (http://stackoverflow.com/questions/375913/what -can-i-use-to-profile-c-code-in-linux/378024 # 378024) * hoạt động ở bất kỳ ngôn ngữ nào, bao gồm R. Nó không đo thời gian với bất kỳ độ chính xác nào; những gì nó làm là chỉ ra chính xác mã cần có thời gian và đưa ra ước tính sơ bộ về phần trăm thời gian cần thiết. Nếu bạn thấy sự thay đổi về những gì đang diễn ra, hoặc tăng đáng kể tỷ lệ phần trăm, điều đó sẽ cho bạn biết sự hồi quy là gì. –
... Nếu bạn xác định điều gì đó chiếm tỷ lệ cao, và bạn sửa nó, bạn sẽ thấy phần trăm do điều đó sẽ giảm xuống, và tổng thời gian sẽ giảm. Phần trăm của cái gì khác sẽ tăng lên vì nó chiếm một phần lớn hơn của tổng số nhỏ hơn. Đó là để được mong đợi. –