Phần cứng rất rẻ, lập trình viên rất đắt

Với sự phát triển nhanh chóng của công nghệ phần cứng theo Định luật Moore, khi nào thì ta nên ném phần cứng vào một vấn đề lập trình? Như một quy tắc chung, tôi muốn nói gần như là luôn luôn.

Hãy xem xét mức lương trung bình của lập trình viên tại Mỹ:

Mức lương cho lập trình viên ở Mỹ luôn rất cao

Bạn có thể có một số những lập trình viên này trong danh sách nhân viên của mình. Tôi không thể nói bạn phải mất bao nhiêu chi phí hoặc cần số lượng bao nhiêu máy chủ. Hoặc, có thể bạn chẳng cần bất kỳ máy chủ nào cả – bởi vì tất cả code của bạn đều thực thi trên phần cứng của người dùng, đó là một kịch bản hoàn toàn khác. Rõ ràng, các tình huống là rất khác nhau. Nhưng ngay cả môn toán sơ đẳng nhất cũng sẽ cho bạn biết rằng chi phí cho rất nhiều phần cứng mới bằng với chi phí hàng năm trả lương cho một đội ngũ lập trình viên 5 người khiêm tốn.

Ví dụ, tôi vừa mới mua hai máy chủ rất mạnh mẽ cho Stack Overflow. Thậm chí sau khi tính toán thêm một máy chủ sao lưu thứ ba và các ổ đĩa cứng dự phòng, tổng số tiền mà tôi phải chi ra là khoảng $5.000 đô-la. Những máy chủ này, so với những máy chủ chúng tôi đang dùng hiện tại, sẽ mang lại giá trị:

• tốc độ CPU tăng hơn khoảng 50%
• dung lượng bộ nhớ tăng 2 đến 6 lần
• gần như gấp đôi không gian đĩa

Dưới chế độ phần cứng mới này, chúng tôi có thể mong chờ thời gian response trung bình của trang giảm xuống khoảng một nửa. Tất cả phần cứng này có chi phí ít hơn một tháng lương của một lập trình viên trung bình tại Mỹ.

Tôi muốn nói đó là một sự đầu tư tuyệt vời. Thậm chí không cần phải suy nghĩ nhiều.

Ngẫu nhiên, đây cũng là lý do tại sao việc không trang bị cho các lập trình viên được trả lương cao của bạn các thiết bị tốt theo Tuyên ngôn nhân quyền của Lập trình viên là một sai lầm to lớn. Nếu đầu tư một lần $4.000 đô-la cho mỗi lập trình viên khiến họ có năng suất tăng chỉ cần 5%, thì bạn cũng đã hưởng lợi ngay sau năm đầu tiên. Mỗi năm sau đó bạn đều có lợi nhuận. Ngoài ra, việc các lập trình viên tin rằng ông chủ của họthực sự quan tâm chu đáo về họ có thể là một chiến lược kinh doanh tốt cho các công ty thực sự muốn tồn tại và phát triển trong 5 đến 10 năm tới.

Rõ ràng, phần cứng rất rẻ, và các lập trình viên rất đắt. Bất cứ khi nào bạn đưa ra một cơ hội để tận dụng sự mất cân bằng đó, thì điều đó là cực kỳ ngu ngốc.

Mặc dù luôn luôn ngạc nhiên về việc phần cứng ngày càng trở nên mới hơn và tốt hơn sau mỗi năm, tôi cũng luôn nhớ đến đồ thị ưa thích của mình trong cuốn sáchProgramming Pearls:

Tất cả mọi thứ đều nhanh khi n nhỏ. Nhưng khi n lớn lên, đó là khi mọi thứ bắt đầu đi ngang. Đồ thị ở trên hiển thị thời gian tính toán trên một máy tính Trash-80 cổ và một máy tính DEC Alpha bán hiện đại, là một lời nhắc nhở nghiêm túc rằng phần cứng nhanh nhất trên thế giới này cũng chẳng thể cứu bạn khỏi những phần code tồi.Cụ thể hơn, đó là sự yếu kém trong việc lựa chọn cấu trúc dữ liệu hoặc thuật toán.

Dĩ nhiên, cũng chẳng chết ai khi chạy phần code được viết tồi trên những phần cứng nhanh nhất mà bạn có thể có. Nhưng nếu bạn muốn cải thiện hiệu suất một cách đáng kể, bạn cũng sẽ thường xuyên phải tìm tòi và tối ưu phần code của mình. Những kinh nghiệm mà Patrick Smacchia đã học được từ việc nâng cao hiệu suất trong thực tế là một ví dụ tuyệt vời trong tối ưu hóa.

Patrick đã cải thiện hiệu suất phân tích của nDepend lên gấp bốn lần, và cắt giảm tiêu thụ bộ nhớ chỉ còn một nửa. Đúng như dự đoán, hầu hết các cải tiến này chủ yếu ở phần thuật toán, nhưng ít nhất một nửa trong sự cải tiến tổng thể đến từ một loạt các kỹ thuật tối ưu hóa khác nhau. Patrick ví điều này giống như những ngày đầu tiên mà ông viết code demo trên chiếc máy Commodore Amiga:

Vào đầu những năm 90, tôi đã tham gia vào buổi demo giới thiệu máy Amiga. Đó là một minh họa tuyệt vời của ý tưởng rằng luôn luôn có thể làm cho hiệu suất trở nên tốt hơn. Mỗi demo đều chạy trên cùng một phần cứng. Đó là động lực hoàn hảo cho các lập trình viên tạo ra ngày càng nhiều phần code tối ưu hơn. Trong vài năm, mỗi tháng một kỷ lục lại bị xô đổ: số lượng các hình đa giác 3D, số lượng các sprites, hoặc số điểm hiển thị đồng thời với tốc độ 50 khung hình mỗi giây. Trong khoảng thời gian một vài năm, yếu tố hiệu suất tăng lên khoảng 50 lần! Hãy tưởng tượng điều đó có nghĩa là một phép tính bây giờ sẽ được thực hiện trong 1 giây mà trước đó phải cần 1 phút để hoàn thành. Kết quả tuyệt vời này đến từ cả việc cải thiện các thuật toán tốt hơn (có nhiều tính toán trước và các ủy nhiệm lên các sub-chip) và các tối ưu hóa mức vi mô ở cấp độ ngôn ngữ assembly (sử dụng tốt hơn các chip thanh ghi, sử dụng tốt hơn các tập lệnh).

Patrick đã đạt được kết quả tuyệt vời, nhưng xin nhớ rằng: tối ưu hóa code của bạn là công việc rất khó khăn. Và đôi khi nguy hiểm. Nó không phải là một cái gì đó bạn thực hiện nhẹ nhàng, và bạn chắc chắn sẽ muốn những lập trình viên có tay nghề cao nhất của mình làm việc trên nó. Để có một cái nhìn sâu sắc hơn, chúng ta hãy cùng điểm qua những phần trích dẫn kinh điển về vấn đề này.

Quy tắc của Tối ưu hóa:
Quy tắc 1: Đừng làm điều đó.
Quy tắc 2 (chỉ dành cho các chuyên gia): Nếu bạn chưa làm thì đừng làm điều đó.
– M.A. Jackson

Có nhiều tính toán với danh nghĩa để mang lại hiệu suất (không nhất thiết phải đạt được nó) hơn so với bất kỳ lý do nào khác – bao gồm cả sự ngu ngốc mù quáng.
– W.A. Wulf

Các lập trình viên thường có xu hướng sa lầy vào các chi tiết của việc tối ưu vì lợi ích tối ưu hóa, như tôi đã đề cập trước đây trong các bài viết Why Aren’t My Optimizations Optimizing? và Micro-Optimization and Meatballs. Nếu bạn không cực kỳ cẩn thận, bạn có thể sẽ mất rất nhiều thời gian phát triển tốn kém nhưng lại thu được rất ít kết quả. Hoặc tệ hơn, bạn sẽ thấy mình phải đối mặt với một loạt các vấn đề mới, thậm chí lỗi còn tinh vi hơn trong codebase của bạn.

Đó là lý do tại sao tôi đề nghị phương pháp tối ưu sau đây:

1. Cung cấp những phần cứng rẻ và nhanh hơn để giải quyết vấn đề hiệu suất đó.
2. Nếu sau khi có phần cứng mới, ứng dụng đã đáp ứng được các mục tiêu hiệu suất của bạn, thì hãy dừng lại.
3. Benchmark code của bạn để xác định chính xác nơi có các vấn đề về hiệu suất.
4. Phân tích và tối ưu hóa những nơi mà bạn đã xác định được trong bước trước đó.
5. Nếu ứng dụng bây giờ đã đáp ứng được các mục tiêu hiệu suất của bạn, thì hãy dừng lại.
6. Quay trở lại bước 1.

Luôn luôn thử giải quyết vấn đề về hiệu suất đầu tiên bằng cách cung cấp những phần cứng nhanh hơn vào nó. Đó sẽ thường là cách nhanh và rẻ hơn để giải quyết vấn đề hiệu suất ngay lập tức hơn là cố gắng để nhảy vào tối ưu code của bạn. Tất nhiên, về lâu dài thì bạn sẽ phải làm cả hai. Sau cùng, bạn sẽ buộc phải xem xét lại sâu hơn về thuật toán và các vấn đề thiết kế với code của mình để ứng dụng chạy nhanh hơn. Và lợi thế của làm việc trên phần cứng mới là bạn sẽ trông giống như một anh hùng thậm chí lớn hơn khi bạn đưa ra phần code tối ưu chạy trên phần cứng nhanh hơn đó.

Nhưng cho đến ngày Định luật Moore hoàn toàn rời bỏ chúng ta, có một điều chắc chắn là: phần cứng rất rẻ – và các lập trình viên rất đắt.

TechTalk via Vinacode.net