2010-04-08 18 views
7

Đây có lẽ là một câu hỏi thảo luận, nhưng tôi nghĩ rằng stackoverflow có thể là nơi thích hợp để hỏi nó. Tôi đang nghiên cứu khái niệm về hướng dẫn pipelining. Tôi đã được dạy rằng thông lượng hướng dẫn của một đường ống được tăng lên một khi số lượng các giai đoạn đường ống được tăng lên, nhưng trong một số trường hợp, thông lượng có thể không thay đổi. Dưới những điều kiện nào, điều này có xảy ra không? Tôi nghĩ suy nghĩ và phân nhánh có thể là câu trả lời cho câu hỏi, nhưng tôi tự hỏi liệu tôi có thiếu cái gì đó quan trọng không.Tại sao độ sâu đường ống tăng không phải lúc nào cũng có nghĩa là tăng lưu lượng?

+0

Cảm ơn câu trả lời. Chỉ cần thông tin của bạn, một thứ khác xuất hiện trong tâm trí của tôi là ngay cả khi chúng tôi tăng giai đoạn đường ống, hy vọng phá vỡ logic giai đoạn ban đầu thành các mạng con nhỏ hơn, một hướng dẫn có thể không lan truyền qua các mạng nhỏ hơn này bởi vì hệ thống phân cấp đường ống đơn giản nhất có thể giải thích về logic giai đoạn ban đầu, vì vậy điều này sẽ không ảnh hưởng đến thông lượng. – user246392

Trả lời

4

Toàn bộ có thể bị tạm dừng bởi các hướng dẫn khác khi chờ kết quả hoặc bị mất bộ nhớ cache. Pipelining không tự bảo đảm rằng các hoạt động hoàn toàn độc lập. Đây là bản trình bày tuyệt vời về sự phức tạp của kiến ​​trúc Intel/AMD x86: http://www.infoq.com/presentations/click-crash-course-modern-hardware

Nó giải thích chi tiết về cách cải thiện thông lượng và ẩn độ trễ. JustJeff đã đề cập đến việc thực hiện out-of-order cho một, và bạn có các thanh ghi bóng không được mô hình lập trình tiếp xúc (hơn 8 thanh ghi trên x86), và bạn cũng có dự đoán nhánh.

0

Tôi cũng nghĩ rằng việc tăng đường ống vượt quá số lượng thời gian mà lệnh dài nhất trong một chuỗi sẽ thực hiện sẽ không làm tăng hiệu suất. Tôi nghĩ rằng việc trì hoãn và phân nhánh là những vấn đề cơ bản.

0

Chắc chắn các gian hàng/bong bóng trong đường ống dài gây ra tổn thất rất lớn về thông lượng. Và tất nhiên, đường ống càng dài thì chu kỳ đồng hồ càng bị lãng phí.

Tôi đã thử một thời gian dài để nghĩ về các tình huống khác, nơi đường ống dài hơn có thể gây ra sự mất hiệu suất, nhưng tất cả trở lại quầy hàng. (Và số lượng các đơn vị thực hiện và đề án phát hành, nhưng những người không có nhiều để làm với chiều dài đường ống.)

2

Đồng ý. Các vấn đề lớn nhất là các quầy hàng (chờ kết quả từ các hướng dẫn trước) và dự đoán nhánh không chính xác. Nếu đường ống của bạn có 20 tầng sâu và bạn sẽ đợi kết quả của điều kiện hoặc hoạt động, bạn sẽ đợi lâu hơn nếu kênh của bạn chỉ có 5 giai đoạn. Nếu bạn dự đoán nhánh sai, bạn phải xóa 20 lệnh ra khỏi đường ống, trái ngược với 5.

Tôi đoán bạn có thể có một đường ống sâu nơi nhiều giai đoạn đang cố truy cập cùng phần cứng (ALU, v.v.), mà sẽ gây ra một hit hiệu suất, mặc dù hy vọng bạn ném đủ đơn vị bổ sung để hỗ trợ từng giai đoạn.

+1

Đó không phải là 20 hướng dẫn, nhưng giá trị chỉ dẫn của 20 chu kỳ. Trên một CPU siêu cứng, có thể là MUCH nhiều hơn. – slacker

1

Độ song song về mức lệnh có thu nhập giảm dần. Đặc biệt, phụ thuộc dữ liệu giữa các lệnh xác định song song có thể.

Xem xét trường hợp Đọc sau khi viết (được gọi là RAW trong sách giáo khoa).

Trong cú pháp mà toán hạng đầu tiên nhận được kết quả, hãy xem xét ví dụ này.

10: add r1, r2, r3 
20: add r1, r1, r1 

Kết quả của dòng 10 phải được biết đến khi tính toán dòng 10 bắt đầu. Chuyển tiếp dữ liệu giảm nhẹ vấn đề này, nhưng ... chỉ đến điểm dữ liệu được biết.

Các vấn đề liên quan