CHƯƠNG 5 TINH CHỈNH mã NGUỒN và xây DỰNG tài LIỆU CHƯƠNG TRÌNH

• Với toán, làm để: – Thiết kế giải thuật nhằm giải toán – Cài đặt giải thuật chương trình máy tính -Hãy tính đến tính hiệu chương trình CHƯƠNG V TINH CHỈNH MÃ NGUỒN VÀ XÂY DỰNG TÀI LIỆU CHƯƠNG TRÌNH I II Tinh chỉnh mã nguồn Xây dựng tài liệu chương trình Hiệu chương trình tinh chỉnh mã nguồn Các phương pháp tinh chỉnh mã nguồn I TINH CHỈNH MÃ NGUỒN (CODE TUNING) 1.1 Hiệu • Sau áp dụng kỹ thuật xây dựng CT PM: • CT có tốc độ đủ nhanh – Không thiết phải quan tâm đến viêc tối ưu hóa hiệu – Chỉ cần giữ cho CT đơn giản dễ đọc • Hầu hết thành phần CT có tốc độ đủ nhanh – Thường phần nhỏ làm cho CT chạy chậm – Tối ưu hóa riêng phần cần • Các bước làm tăng hiệu thực CT – Tính toán thời gian thực phần khác CT – Xác định “hot spots” – đoạn mã lệnh đòi hỏi nhiều thời gian thực – Tối ưu hóa phần CT đòi hỏi nhiều thời gian thực – Lặp lại bước cần Tối ưu hóa hiệu CT ? • • Cấu trúc liệu tốt hơn, giải thuật tốt Cải thiện độ phức tạp tiệm cận (asymptotic complexity) – Tìm cách khống chế tỉ lệ số phép toán cần thực số lượng tham số đầu vào – Ví dụ: thay giải thuật xếp có độ phức tạp O(n2) giải thuật có độ phức tạp O(n log n) • • Cực kỳ quan trọng lượng tham số đầu vào lớn Đòi hỏi LTV phải nắm vững kiến thức CTDL giải thuật • • Mã nguồn tốt hơn: viết lại đoạn lệnh cho chúng trình dịch tự động tối ưu hóa tận dụng tài nguyên phần cứng Cải thiện yếu tố thay đổi – Ví dụ: Tăng tốc độ tính toán bên vòng lặp: từ 1000n thao tác tính toán bên vòng lặp xuống 10n thao tác tính toán • • Cực kỳ quan trọng phần CT chạy chậm Đòi hỏi LTV nắm vững kiến thức phần cứng, trình dịch quy trình thực CT  Code tuning 1.2 Code tuning (tinh chỉnh mã nguồn) ? • Thay đổi mã nguồn chạy thông theo hướng hiệu • Chỉ thay đổi phạm vi hẹp, ví dụ liên quan đến CTC, tiến trình hay đoạn mã nguồn • Không liên quan đến việc thay đổi thiết kế phạm vi rộng, góp phần cải thiện hiệu cho phần thiết kế tổng quát 1.3 Cải thiện hiệu thông qua cải thiện mã nguồn • Có cách tiếp cận để cải thiện hiệu thông qua cải thiện mã nguồn – Lập hồ sơ mã nguồn (profiling): đoạn lệnh tiêu tốn nhiều thời gian thực – Tinh chỉnh mã nguồn (code tuning): tinh chỉnh đoạn mã nguồn – Tinh chỉnh có chọn lựa (options tuning): tinh chỉnh thời gian thực tài nguyên sử dụng để thực CT • Khi cần cải thiện hiệu theo hướng – Sau kiểm tra gỡ rối chương trình • Không cần tinh chỉnh CT chạy chưa • Việc sửa lỗi làm giảm hiệu CT • Việc tinh chỉnh thường làm cho việc kiểm thử gỡ rối trở nên phức tạp – Sau bàn giao CT • Duy trì cải thiện hiệu • Theo dõi việc giảm hiệu CT đưa vào sử dụng 1.4 Quan hệ hiệu tinh chỉnh mã nguồn • Việc giảm thiểu số dòng lệnh viết NNLT bậc cao KHÔNG: – Làm tăng tốc độ chạy CT – làm giảm số lệnh viết ngôn ngữ máy for i = to 10 a[i] = i; a[ a[ a[ a[ a[ ] ] ] ] ] = = = = = ; : ; ; ; a[ a[ a[ a[ a[ 2]=2; 4]=4; 6]=6; 8]=8; 10 ] = 10 ; Quan hệ hiệu tinh chỉnh mã nguồn • Luôn định lượng hiệu cho phép toán • Hiệu phép toán phụ thuộc vào: – – – – – Ngôn ngữ lập trình Trình dịch / phiên sử dụng Thư viện / phiên sử dụng Processor Bộ nhớ máy tính • Hiệu việc tinh chỉnh mã nguồn máy khác khác Quan hệ hiệu tinh chỉnh mã nguồn • số kỹ thuật viết mã hiệu áp dụng để tinh chỉnh mã nguồn • Nhưng nhìn chung không nên vừa viết chương trình vừa tinh chỉnh mã nguồn – Không thể xác định nút thắt chương trình trước chạy thử toàn chương trình – Việc xác định sớm nút thắt chương trình gây nút thắt chạy thử toàn chương trình – Nếu vừa viết chương trình vừa tìm cách tối ưu mã nguồn, làm sai lệch mục tiêu chương trình Ví dụ: thích đoạn mã nguồn /* Tinh duong kinh va chu vi */ diam = * radius; circum = PI * (double)diam; /* In ket qua */ printf("A circle with radius %d has diameter %d\n", radius, diam); printf("and circumference %f.\n", circum); return 0; } Những thành phần mã nguồn bắt buộc phải có thích • Tất file (nếu chương trình gồm nhiều file) cấn thích nội dung file • Tất hàm: dùng để làm gì, dùng biến đầu vào nào, trả 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 thích – int total; cần • Tất struct/typedef (trừ phi thực tầm thường) Ví dụ: thích file /********************************************************************** class: GigaTron (GIGATRON.CPP) author: Dwight K Coder date: July 4, 2014 Routines to control the twenty-first century's code evaluation tool The entry point to these routines is the EvaluateCode() routine at the bottom of this file **********************************************************************/ Chú thích hàm • Mô tả cần thiết để gọi hàm cách xác – Mô tả hàm làm gì, làm – Bản thân mã nguồn phải rõ ràng, dễ hiểu để biết cách hàm làm việc – Nếu không, viết thích bên định nghĩa hàm • Mô tả đầu vào: Tham số truyền vào, đọc file gì, biến tổng thể dùng • Mô tả đầu ra: giá trị trả về, tham số truyền ra, ghi files gì, biến tổng thể mà tác động tới • Mô tả bẫy lỗi: có hay không việc bẫy lỗi Ví dụ: thích hàm • Bad function comment /* decomment.c */ int main(void) { /* Đọc ký tự Dựa ký tự trạng thái DFA thời, gọi hàm xử lý trạng thái tương ứng Lặp hết tệp end-of-file */ … } – Describes how the function works Ví dụ: thích hàm • Good function comment /* decomment.c */ int main(void) { /* Đọc CT C qua stdin Ghi stdout với thích thay dấu cách Trả thành công, EXIT_FAILURE không thành công */ … } – Describes what the function does Các quy tắc viết thích khác • Chú thích bạn cố tình thực thao tác kỳ cục khiến LTV khác điên đầu • Nếu thích dài, tốt nên đặt tham chiếu sang đoạn văn mô tả chi tiết chỗ khác • Đừng cố gắng định dạng thích theo cách gây nhầm lẫn với mã nguồn (ví dụ, đặt gióng hàng riêng cho thích) Tài liệu cho LTV khác • Giới thiệu với LTV khác mã nguồn dùng để làm • Nhiều công ty lớn tự đặt chuẩn riêng để viết tài liệu • Mục tiêu cho phép LTV khác sử dụng thay đổi mã nguồn mà không cần đọc hiểu dòng lệnh • Đừng quên viết tài liệu cho tập lớn Viết tài liệu ngoài: bước • Miêu tả cách tổng quát cách thức hoạt động CT – – – – CT phải làm ? Phải đọc từ nguồn liệu nào, ghi vào đâu? Giả thiết với đầu vào ? Dùng giải thuật ? Viết tài liệu ngoài: bước • Miêu tả cách tổng quát quy trình nghiệp vụ CT – Có thể vẽ biểu đồ – Ví dụ: dùng flowchart • Giải thích giải thuật phức tạp sử dụng chương trình, cho biết tìm lời giải thích đâu – Ví dụ: "I use the vcomplexsort; see Knuth page 45 for more details" Viết tài liệu ngoài: bước • Nếu CT bao gồm nhiều file, giải thích nội dung file • Giải thích cấu trúc liệu sử dụng phổ biến CT • Giải thích việc sử dụng biến toàn cục CTC Viết tài liệu ngoài: bước • Miêu tả hàm CT – LTV tự định hàm hàm CT – Xem xét hàm hàm nghiệp vụ thực sự, ko thiết phải hàm dài hay khó viết • Miêu tả tham số đầu vào giá trị trả Viết tài liệu cho người dùng • Hướng dẫn sử dụng (user manual) • Là phần thiếu viết tài liệu cho dự án phần mềm, phần quan trọng Viết tài liệu cho người dùng • Thu thập thông tin liên quan đến sản phẩm cần viết hướng dẫn sử dụng • Miêu tả sản phẩm • Miêu tả quy trình sử dụng chức sản phẩm • Dùng thử sản phẩm theo bước miêu tả quy trình sử dụng Viết tài liệu kiểm thử • Tài liệu kiểm thử số tài liệu quan dự án phần mềm • Nếu được, LTV nên viết số chứng việc bạn kiểm thử chương trình với nhiều tham số đầu vào khác • Việc không viết tài liệu kiểm thử gây nhiều hậu nặng nề [...]...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ữ assembly Lưu ý: Càng thay đổi nhiều thì càng không cải thiện được hiệu năng 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 – Initial code if ( 5 < x ) && ( x... lập trình một cách thông minh, đừng quá cứng nhắc – Không cần tối ưu 1 chương trình đủ nhanh – Tối ưu hóa chương trình đúng lúc, đúng chỗ • Tăng tốc chương trình – Cấu trúc dữ liệu tốt hơn, giải thuật tốt hơn: hành vi tốt hơn – Các đoạn mã tối ưu: chỉ thay đổi ít • Các kỹ thuật tăng tốc chương trình – Tinh chỉnh mã nguồn theo hướng • Giúp đỡ trình dịch • Khai thác khả năng phần cứng II XÂY DỰNG TÀI LIỆU... thác khả năng phần cứng II XÂY DỰNG TÀI LIỆU Các loại tài liệu chương trình • Tài liệu trong (Internal documentation) – Các chú thích cho mã nguồn (comments) • Tài liệu ngoài (External documentation) – Dành cho các lập trình viên khác khi làm việc với mã nguồn • Tài liệu dành cho người sử dụng – Cẩm nang dành cho những người sử dụng mã nguồn 1 Tài liệu trong • Làm thế nào để viết được các chú thích hợp... 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” (thường chỉ chiếm khoảng 5% mã nguồn) • Viết lại mã nguồn các “hot spots” bằng assembly để cải thiện hiệu năng của toàn bộ chương trình Giúp trình dịch làm tốt công việc của nó • Trình dịch có thể thực hiện 1 số thao tác tôi ưu hóa tự động – Cấp phát thanh ghi – Lựa chọn lệnh để thực hiện và thứ... trình để xác định “hot spots” – Đọc lại phần mã viết bằng assembly do trình dịch sản sinh ra – Xem lại mã nguồn để giúp trình dịch làm tốt công việc của nó 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... 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 2 .5 Tinh chỉnh dãy lệnh (đã học) • Sử dụng các hàm inline 2.6 Viết lại mã nguồn bằng ngôn ngữ assembly • Viết chương trình hoàn chỉnh. .. } 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 ]; 2.1 Tinh chỉnh các biểu thức logic • Lazy evaluation: 1 trong các kỹ thuật viết mã chương trình hiệu quả đã học 2.2 Tinh chỉnh. .. 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 Các... thiểu các phép tính toán bên trong vòng lặp nếu có thể 2.3 Tinh chỉnh việc biến đổi dữ liệu • Một số kỹ thuật viết mã hiệu quả đã học: – Sử dụng kiểu dữ liệu có kích thước nhỏ nếu có thể – Sử dụng mảng có số chiều nhỏ nhất có thể – Đem các phép toán trên mảng ra ngoài vòng lặp nếu có thể – Sử dụng các chỉ số phụ – Sử dụng biến trung gian 2.4 Tinh chỉnh các biểu thức (đã học) • Thay thế phép nhân bằng phép... kém hiệu quả • Nhưng trình dịch không thể tự xác định – Các hiệu ứng phụ (side effect) của hàm hay biểu thức: ngoài việc trả ra kết quả, việc tính toán có làm thay đổi trạng thái hay có tương tác với các hàm/biểu thức khác hay không – Hiện tượng nhiều con trỏ trỏ đến cùng 1 vùng nhớ (memory aliasing) • Tinh chỉnh mã nguồn có thể giúp nâng cao hiệu năng – Chạy thử từng đoạn chương trình để xác định “hot ...CHƯƠNG V TINH CHỈNH MÃ NGUỒN VÀ XÂY DỰNG TÀI LIỆU CHƯƠNG TRÌNH I II Tinh chỉnh mã nguồn Xây dựng tài liệu chương trình Hiệu chương trình tinh chỉnh mã nguồn Các phương pháp tinh chỉnh mã nguồn. .. mã nguồn, làm sai lệch mục tiêu chương trình Các kỹ thuật tinh chỉnh mã nguồn • • • • • • • Tinh chỉnh biểu thức logic Tinh chỉnh vòng lặp Tinh chỉnh việc biến đổi liệu Tinh chỉnh biểu thức Tinh. .. việc tinh chỉnh mã nguồn máy khác khác Quan hệ hiệu tinh chỉnh mã nguồn • số kỹ thuật viết mã hiệu áp dụng để tinh chỉnh mã nguồn • Nhưng nhìn chung không nên vừa viết chương trình vừa tinh chỉnh