Phần 3 bài giảng Kỹ thuật lập trình - Chương 5: Tinh chỉnh mã nguồn và xây dựng tài liệu chương trình cung cấp cho người học các kiến thức: Tinh chỉnh mã nguồn, xây dựng tài liệu chương trình. Mời các bạn cùng tham khảo nội dung chi tiết.
• Với toán, làm để: – Thiết kế giải thuật nhằm giải tố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 tố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ố khơng thể thay đổi – Ví dụ: Tăng tốc độ tính tốn bên vịng lặp: từ 1000n thao tác tính tốn bên vịng lặp xuống cịn 10n thao tác tính tố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 tốn • Hiệu phép tố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ử tồ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ử tồ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ì, khơng phải 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 ngồi 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 ngồi • 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 ngồ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 ngồi: bước • Miêu tả cách tổng qt 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 ngồ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 khơng thể 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ề ... 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ử tồ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ử tồn chương. ..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... nhanh – Tối ưu hóa chương trình lúc, chỗ • Tăng tốc chương trình – Cấu trúc liệu tốt hơn, giải thuật tốt hơn: hành vi tốt – Các đoạn mã tối ưu: thay đổi • Các kỹ thuật tăng tốc chương trình – Tinh