Bài giảng Kỹ thuật lập trình - Chương 07: Code tuning and documentation - Vũ Đức Vượng

Nội dung text: Bài giảng Kỹ thuật lập trình - Chương 07: Code tuning and documentation - Vũ Đức Vượng

1. I. Code tuning 1. Hiệu năng của chương trình và Code Tuning 2. Các phương pháp Code Tuning
2. Tối ưu hóa hiệu năng của CT ? • Cấu trúc dữ liệu tốt hơn, giải thuật tốt hơn – Cải thiện độ phức tạp tiệm cận (asymptotic complexity) • Tìm cách khống chế tỉ lệ giữa số phép toán cần thực hiện và số lượng các tham số đầu vào • Ví dụ: thay giải thuật sắp xếp có độ phức tạp O(n2) bằng giải thuật có độ phức tạp O(n log n) – Cực kỳ quan trọng khi lượng tham số đầu vào rất lớn – Đòi hỏi LTV phải nắm vững kiến thức về CTDL và giải thuật • Mã nguồn tốt hơn: viết lại các đoạn lệnh sao cho chúng có thể được trình dịch tự động tối ưu hóa và tận dụng tài nguyên phần cứng – Cải thiện các yếu tố không thể thay đổi • Ví dụ: Tăng tốc độ tính toán bên trong các vòng lặp: từ 1000n thao tác tính toán bên trong vòng lặp xuống còn 10n thao tác tính toán – Cực kỳ quan trọng khi 1 phần của CT chạy chậm – Đòi hỏi LTV nắm vững kiến thức về phần cứng, trình dịch và quy trình thực hiện CT → Code tuning
3. 1.3. Cải thiện hiệu năng thông qua cải thiện mã nguồn • Có 3 cách tiếp cận để cải thiện hiệu năng thông qua cải thiện mã nguồn – Lập hồ sơ mã nguồn (profiling): chỉ ra những đoạn lệnh tiêu tốn nhiều thời gian thực hiện – Tinh chỉnh mã nguồn (code tuning): tinh chỉnh các đoạn mã nguồn – Tinh chỉnh có chọn lựa (options tuning): tinh chỉnh thời gian thực hiện hoặc tài nguyên sử dụng để thực hiện CT • Khi nào cần cải thiện hiệu năng theo các hướng này – Sau khi đã kiểm tra và gỡ rối chương trình • Không cần tinh chỉnh 1 CT chạy chưa đúng • Việc sửa lỗi có thể làm giảm hiệu năng CT • Việc tinh chỉnh thường làm cho việc kiểm thử và gỡ rối trở nên phức tạp – Sau khi đã bàn giao CT • Duy trì và cải thiện hiệu năng • Theo dõi việc giảm hiệu năng của CT khi đưa vào sử dụng
4. Quan hệ giữa hiệu năng và tinh chỉnh mã nguồn • Luôn định lượng được hiệu năng cho các phép toán • Hiệu năng của các phép toán phụ thuộc vào: – Ngôn ngữ lập trình – Trình dịch / phiên bản sử dụng – Thư viện / phiên bản sử dụng – Processor – Bộ nhớ máy tính • Hiệu năng của việc tinh chỉnh mã nguồn trên các máy khác nhau là khác nhau.
5. 2. Các kỹ thuật tinh chỉnh mã nguồn • Tinh chỉnh các biểu thức logic • Tinh chỉnh các vòng lặp • Tinh chỉnh việc biến đổi dữ liệu • Tinh chỉnh các biểu thức • Tinh chỉnh dãy lệnh • Viết lại mã nguồn bằng ngôn ngữ assembler • Lưu ý: Càng thay đổi nhiều thì càng không cải thiện được hiệu năng
6. 2.1. Tinh chỉnh các biểu thức logic • Không kiểm tra khi đã biết kết quả rồi • Ví dụ: tinh chỉnh như thế nào ??? negativeInputFound = False; for ( i = 0; i < iCount; i++ ) { if ( input[ i ] < 0 ) { negativeInputFound = True; } } Dùng break:
7. 2.1. Tinh chỉnh các biểu thức logic • Sắp xếp thứ tự các phép kiểm tra theo tần suất xảy ra kết quả đúng –SelectTuned inputCharacter code Case "A" To "Z", "a" To "z" ProcessAlpha( inputCharacter ) Case " " ProcessSpace( inputCharacter ) Case ",", ".", ":", ";", "!", "?" ProcessPunctuation( inputCharacter ) Case "0" To "9" ProcessDigit( inputCharacter ) Case "+", "=" ProcessMathSymbol( inputCharacter ) Case Else ProcessError( inputCharacter ) End Select
8. 2.1. Tinh chỉnh các biểu thức logic • So sánh hiệu năng của các lệnh có cấu trúc tương đương
9. 2.1. Tinh chỉnh các biểu thức logic • Thay thế các biểu thức logic phức tạp bằng bảng tìm kiếm kết quả Tuned code // define categoryTable static int categoryTable[2][2][2] = { // !b!c !bc b!c bc 0, 3, 2, 2, // !a 1, 2, 1, 1 // a }; category = categoryTable[ a ][ b ][ c ];
10. 2.2. Tinh chỉnh các vòng lặp • Loại bỏ bớt việc kiểm tra điều kiện bên trong vòng lặp for ( i = 0; i < count; i++ ) { if ( sumType == SUMTYPE_NET ) { – Initial code netSum = netSum + amount[ i ]; } else { grossSum = grossSum + amount[ i ]; } } if ( sumType == SUMTYPE_NET ) { for ( i = 0; i < count; i++ ) { netSum = netSum + amount[ i ]; – Tuned code } } else { for ( i = 0; i < count; i++ ) { grossSum = grossSum + amount[ i ]; } }
11. 2.2. Tinh chỉnh các vòng lặp • Một số kỹ thuật viết các lệnh lặp hiệu quả đã học – Ghép các vòng lặp với nhau – Giảm thiểu các phép tính toán bên trong vòng lặp nếu có thể
12. 2.4. Tinh chỉnh các biểu thức (đã học) • Thay thế phép nhân bằng phép cộng • Thay thế phép lũy thừa bằng phép nhân • Thay việc tính các hàm lượng giác bằng cách gọi các hàm lượng giác có sẵn • Sử dụng kiểu dữ liệu có kích thước nhỏ nếu có thể – long long int → long, int – floating-point → fixed-point, int – double-precision → single-precision • Thay thế phép nhân đôi / chia đôi số nguyên bằng phép bitwise • Sử dụng hằng số hợp lý • Tính trước kết quả • Sử dụng biến trung gian
13. 2.6. Viết lại mã nguồn bằng ngôn ngữ assembler • Viết chương trình hoàn chỉnh bằng 1 NNLT bậc cao • Kiểm tra tính chính xác của toàn bộ chương trình • Nếu cần cải thiện hiệu năng thì áp dụng kỹ thuật lập hồ sơ mã nguồn để tìm “hot spots” (chỉ khoảng 5 % CT thường chiếm 50% thời gian thực hiện, vì vậy ta có thể thường xác định đc 1 mẩu code như là hot spots) • Viết lại những mẩu nhỏ các lệnh = assembler để tăng tốc độ thực hiện
14. Khai thác hiệu quả phần cứng • Tốc độ của 1 tập lệnh thay đổi khi môi trường thực hiện thay đổi • Dữ liệu trong thanh ghi và bộ nhớ đệm được truy xuất nhanh hơn dữ liệu trong bộ nhớ chính – Số các thanh ghi và kích thước bộ nhớ đệm của các máy tính khác nhau – Cần khai thác hiệu quả bộ nhớ theo vị trí không gian và thời gian • Tận dụng các khả năng để song song hóa – Pipelining: giải mã 1 lệnh trong khi thực hiện 1 lệnh khác • Áp dụng cho các đoạn mã nguồn cần thực hiện tuần tự – Superscalar: thực hiện nhiều thao tác trong cùng 1 chu kỳ đồng hồ (clock cycle) • Áp dụng cho các lệnh có thể thực hiện độc lập – Speculative execution: thực hiện lệnh trước khi biết có đủ điều kiện để thực hiện nó hay không
15. II. Xây dựng tài liệu 1. Các tài liệu trong và ngoài (internal và external) 2. Các quy tắc xây dựng tài liệu 3. Các quy định và kỹ thuật quy định Code Convention và Comment
16. 1.1. Làm thế nào để viết được các chú thích hợp lý (good comment) • Các chú thích có giúp người đọc hiểu được mã nguồn hay không ? • Các chú thích có thực sự bổ ích hay không ? Lập trình viên viết chú thích vì chú thích là thực sự cần thiết để hiểu mã nguồn hay viết để cho có ? • Người đọc có dễ dàng làm việc với mã nguồn hơn khi có chú thích hay không ? • Nếu không chú thích được thì nên đặt tham chiếu đến một tài liệu cho phép người đọc hiểu vấn đề sâu hơn.
17. Các chú thích cần tránh: chú thích chỉ nhằm mục đích phân đoạn mã nguồn while (j < ARRAYLEN) { printf ("J is %d\n", j); for (i= 0; i < MAXLEN; i++) { /* These comments only */ for (k= 0; k < KPOS; k++) { /* Serve to break up */ printf ("%d %d\n",i,k); /* the program */ } /* And make the indentation */ } /* Very hard for the programmer to see */ j++; }
18. Comments (cont.) • Chú thích các đoạn (“paragraphs”) code, đừng chú #include #includethích từng dòng code int main(void) /* Read a circle's radius from stdin, and compute and write its diameter and circumference to stdout. Return 0 if successful. */ { const double PI = 3.14159; int radius; int diam; double circum; /* Read the circle’s radius. */ printf("Enter the circle's radius:\n"); if (scanf("%d", &radius) != 1) { fprintf(stderr, "Error: Not a number\n"); exit(EXIT_FAILURE); /* or: return EXIT_FAILURE; */ }
19. Những thành phần nào của mã nguồn bắt buộc phải có chú thích • Tất cả các file (nếu chương trình gồm nhiều file) đều cấn chú thích về nội dung của file đó • Tất cả các hàm: dùng để làm gì, dùng các biến đầu vào nào, trả ra cái gi. • Biến có tên không rõ ràng – i,j,k cho vòng lặp, FILE *fptr không cần chú thích – nhưng int total; cần • Tất cả các struct/typedef (trừ phi nó thực sự quá tầm thường)
20. Function Comments • Mô tả những gì cần thiết để gọi hàm 1 cách chính xác – Mô tả Hàm làm gì, chứ không phải nó làm như thế nào – Bản thân Code phải rõ ràng, dễ hiểu để biết cách nó làm việc – Nếu không, hãy viết chú thích bên trong định nghĩa hàm • Mô tả đầu vào: Tham số truyền vào, đọc file gì, biến tổng thể được dùng • Mô tả outputs: giá trị trả về, tham số truyền ra, ghi ra files gì, các biến tổng thể mà nó tác động tới
21. Function Comments (cont.) • Good function comment /* decomment.c */ int main(void) { /* Đọc 1 CT C qua stdin. Ghi ra stdout với mỗi chú thích thay bằng 1 dấu cách. Trả về 0 nếu thành công, EXIT_FAILURE nếu không thành công. */ } –Describes what the function does
22. 1.2. Tài liệu ngoài cho các LTV khác • Giới thiệu với các LTV khác mã nguồn dùng để làm gì • Nhiều công ty lớn tự đặt chuẩn riêng để viết tài liệu ngoài • Mục tiêu là cho phép các LTV khác sử dụng và thay đổi mã nguồn mà không cần đọc và hiểu từng dòng lệnh • Đừng quên viết tài liệu ngoài cho bài tập lớn
23. Viết tài liệu ngoài: bước 2 • Miêu tả 1 cách tổng quát quy trình nghiệp vụ của CT (giống như cách miêu tả 1 flowchart) • Có thể vẽ biểu đồ • Giải thích các giải thuật phức tạp được ưử dụng trong chương trình, hoặc cho biết có thể tìm được lời giải thích ở đâu
24. Viết tài liệu ngoài: bước 2 • Miêu tả các hàm chính trong CT – LTV tự quyết định hàm nào là hàm chính trong CT của mình – Xem xét hàm nào là hàm nghiệp vụ thực sự, ko nhất thiết phải là hàm dài nhất hay khó viết nhất • Miêu tả các tham số đầu vào và giá trị trả về
25. 1.4. Viết tài liệu kiểm thử • Tài liệu kiểm thử là 1 trong số các tài liệu quan trong của 1 dự án phần mềm • Nếu được, bạn nên viết ra 1 số bằng chứng về việc bạn đã kiểm thử chương trình của bạn với nhiều đầu vào khác nhau • Việc không viết tài liệu kiểm thử có thể gây ra nhiều hậu quả nặng nề