Những con số thiết yếu mà mọi lập trình viên nên biết

Minh họa trực quan các con số độ trễ mà lập trình viên nên biết

• Tham chiếu bộ nhớ đệm L1: 1 nano giây
• Dự đoán nhánh thất bại: 3 nano giây
• Tham chiếu bộ nhớ đệm L2: 4 nano giây
• Khóa/mở khóa mutex: 17 nano giây
• Truyền 1KB dữ liệu qua mạng 1 Gbps: 44 nano giây
• Tham chiếu bộ nhớ chính: 100 nano giây
• Nén 1KB dữ liệu bằng Zippy: 2 micro giây
• Đọc tuần tự 1MB từ bộ nhớ: 3 micro giây
• Đọc ngẫu nhiên 4K từ SSD: 16 micro giây
• Đọc tuần tự 1MB từ SSD: 49 micro giây
• Thời gian khứ hồi trong cùng một trung tâm dữ liệu: 500 micro giây
• Đọc tuần tự 1MB từ đĩa: 825 micro giây
• Tìm kiếm trên đĩa: 2 mili giây
• Gửi một gói tin từ California đến Hà Lan rồi quay lại: 150 mili giây

Ý kiến của GN⁺

• Dữ liệu này có thể là tài liệu tham khảo quan trọng khi lập trình viên thiết kế hệ thống hoặc tối ưu hiệu năng. Nếu biết mỗi phép toán hay tác vụ mất bao lâu, có thể xác định phần nào gây ra nút thắt cổ chai và cải thiện nó.
• Ví dụ, khi so sánh thời gian truy cập bộ nhớ và độ trễ mạng, có thể thấy việc giảm thiểu các lời gọi qua mạng và xử lý dữ liệu trong bộ nhớ sẽ nhanh hơn nhiều. Đây có thể là một yếu tố quan trọng khi thiết kế hệ thống phân tán.
• Những độ trễ này có thể thay đổi theo sự phát triển của phần cứng và công nghệ, vì vậy việc cập nhật thông tin mới nhất là rất quan trọng. Ví dụ, nhờ sự phát triển của SSD mà thời gian đọc đĩa đã được rút ngắn đáng kể.
• Khi đưa vào một công nghệ mới hoặc mã nguồn mở, cần cân nhắc các độ trễ này để dự đoán hiệu năng của hệ thống và quyết định công nghệ nào sẽ hiệu quả nhất trong môi trường thực tế. Ví dụ, dùng giải pháp caching trong bộ nhớ có thể giảm độ trễ mạng, nhưng sẽ cần cân nhắc thêm về tính nhất quán của cache và đồng bộ dữ liệu.

[kleinstein]

https://colin-scott.github.io/personal_website/research/…
Chỗ này nhìn dễ hơn nhiều.

[cosine20]

UI/UX thật sự không hợp gu của tôi chút nào...

[yangeok]

Đúng là vậy thật ghê,,

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  • Người dùng chia sẻ mã JavaScript; đoạn mã này duyệt qua các phần tử con của phần tử HTML có class latency-container và in ra độ trễ của từng phần tử.
  • Các độ trễ được in ra bao gồm nhiều tác vụ tính toán khác nhau, từ truy cập bộ nhớ đệm L1 đến thời gian khứ hồi trong cùng trung tâm dữ liệu.

• Tóm tắt bình luận thứ hai:

  • Đánh giá khả năng sử dụng của giao diện người dùng (UI) là kém, và coi đây là một ví dụ thú vị về trải nghiệm người dùng (UX).
  • Chỉ trích rằng UI không đáp ứng kỳ vọng của người dùng trong việc thực hiện các chức năng chính và khó hiểu.
  • Người dùng cho rằng cần phải đọc phần trợ giúp, nhưng đa số người dùng không thích điều đó.
  • Nhấn mạnh rằng có thể rút ra bài học về UX thông qua việc thảo luận những vấn đề này.

• Tóm tắt bình luận thứ ba:

  • Chỉ ra rằng tiêu đề thiếu từ "Latency", khiến việc tìm các kết quả khác khi tìm kiếm trở nên khó khăn.
  • Tham chiếu các nguồn khác và cho biết họ thích tài liệu dạng văn bản cung cấp nhiều thông tin về độ trễ hơn.

• Tóm tắt bình luận thứ tư:

  • Chỉ trích rằng một phần của UI hiển thị trên màn hình khó đọc.
  • Cho rằng văn bản bị xoay 90 độ gây bất tiện, và đánh giá UI tuy thú vị nhưng có vẻ chú trọng hình thức hơn chức năng khi cần lấy thông tin thực tế.

• Tóm tắt bình luận thứ năm:

  • Liệt kê các tài liệu liên quan đến nguồn gốc của thông tin độ trễ, cung cấp bối cảnh lịch sử cho thông tin này.

• Tóm tắt bình luận thứ sáu:

  • Đề cập rằng độ trễ liên quan đến mạng không mang tính trực quan.
  • Chia sẻ trải nghiệm cá nhân về việc các dịch vụ như Google Stadia có thể nhanh hơn kỳ vọng như thế nào.

• Tóm tắt bình luận thứ bảy:

  • Với tư cách là người dùng Firefox Mobile, bày tỏ rằng họ không hiểu UI đang cố hiển thị điều gì.

• Tóm tắt bình luận thứ tám:

  • Bày tỏ sự bối rối vì không hiểu ý nghĩa của các con số hiển thị trong UI, và thấy chúng giống như đang biểu thị các năm trong tương lai.

• Tóm tắt bình luận thứ chín:

  • Nói rằng tiêu đề hơi bí hiểm và họ đã mong đợi nội dung về các con số như 16, 256, 65536.
  • Bày tỏ sự hoài nghi trước nhận định rằng vào năm 2030, việc gửi 1K byte qua mạng gigabit sẽ nhanh hơn một lần dự đoán nhánh sai bên trong CPU.