Tại sao động cơ cần phải được tối ưu hóa cho bộ xử lý mới có cùng kiến ​​trúc?


39

Khi một thế hệ bộ xử lý mới được phát hành, hầu hết các trang web báo cáo rằng các chương trình và công cụ trò chơi cần được tối ưu hóa cho phần cứng mới. Tôi không hiểu tại sao. Một bộ xử lý thường có kiến ​​trúc xác định loại tập lệnh mà nó sử dụng. Cái mà tất cả chúng ta sử dụng ngày nay là amd_x86_64. Tại sao bất kỳ chương trình hoặc trình biên dịch nào cũng cần được cập nhật nếu tất cả các bộ xử lý sử dụng cùng kiến ​​trúc này? Chắc chắn có những tính năng TRONG đường ống của bộ xử lý mới giúp tối ưu hóa việc thực thi mã máy, nhưng tại sao bản thân mã máy cần phải được thay đổi nếu kiến ​​trúc không?


Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
Josh

14
"Cần" là một từ ngữ sai và tiếp thị nhiều hơn sự thật, giống như cách Windows cần hỗ trợ một thế hệ CPU mới nhất định (hoặc không, như trong trường hợp của Windows 7, về nguyên tắc sẽ hoạt động hoàn hảo tốt với ví dụ Ryzen, ngoại trừ việc sử dụng năng lượng nhiều hơn 3-4% so với mức cần thiết). Điều chỉnh này chỉ là về việc cố gắng vắt kiệt thêm một chút ra khỏi CPU, tiến gần đến mức tối đa. Trên thực tế, bạn có thể đạt được 1-2% tổng thể trong các ví dụ không gây khó chịu do lập lịch khác nhau và sử dụng một vài hướng dẫn mới.
Damon

2
Chỉ vì hai bộ xử lý có thể thực hiện cùng một hoạt động, điều đó không có nghĩa là các hoạt động có cùng hiệu suất trên cả hai bộ xử lý ...
Mehrdad

Xem một câu hỏi liên quan của tôi về Stack Overflow: mtune thực sự hoạt động như thế nào?
Marc.2377

Câu trả lời:


54

Bởi vì các thế hệ khác nhau của cùng một kiến ​​trúc có thể có các bộ hướng dẫn khác nhau .

Ví dụ: Tiện ích mở rộng Truyền SIMD có lẽ là tập lệnh x86 nổi tiếng nhất, tuy nhiên, và mặc dù chỉ có một kiến ​​trúc x86, vẫn tồn tại SSE, SSE2, SSE3 và SSE4.

Mỗi thế hệ này có thể bao gồm các hướng dẫn mới cung cấp các cách nhanh hơn để thực hiện các hoạt động nhất định. Một ví dụ có liên quan đến các trò chơi có thể là hướng dẫn sản phẩm chấm.

Vì vậy, nếu một công cụ trò chơi được biên dịch cho thế hệ kiến ​​trúc trước đó, nó sẽ không hỗ trợ cho các hướng dẫn mới hơn này. Tương tự, có thể cần phải tối ưu hóa động cơ cho các hướng dẫn mới hơn; SSE4 , ví dụ, có hỗ trợ cho các hướng dẫn sản phẩm chấm hoạt động trên dữ liệu mảng. Một tối ưu hóa có thể tận dụng các hướng dẫn mới hơn này sẽ là thay đổi bố cục dữ liệu của bạn thành các mảng.


1
@Panzercrisis - cảm ơn bạn đã gợi ý chỉnh sửa. Để rõ ràng: câu hỏi ban đầu không phải là về mã của riêng bạn, mà là về mã công cụ, vì vậy "tối ưu hóa mã của riêng bạn" không phải là một gợi ý chỉnh sửa tốt. Tuy nhiên, nó đã làm nổi bật rằng tôi cần phải làm rõ rằng khi tôi nói "tối ưu hóa" tôi có nghĩa là "tối ưu hóa mã động cơ", vì vậy tôi đã chỉnh sửa để đưa lên.
Maximus Minimus

37

Câu trả lời của Maximus là chính xác, tôi chỉ muốn đưa ra một phần khác của câu chuyện:

Phần cứng tự thay đổi theo cách bạn cần thay đổi cách mã hóa, bất kể hướng dẫn mới được giới thiệu.

  • Số lượng bộ đệm tăng hoặc giảm có nghĩa là bạn cần lo lắng ít nhiều về việc tối ưu hóa bộ đệm / mất hiệu lực bộ đệm là vấn đề. Nhiều bộ nhớ cache hơn có nghĩa là với dữ liệu nhỏ, bạn có thể tập trung ít hơn vào việc đảm bảo dữ liệu liền kề với việc chạy vào các mối quan tâm về hiệu suất. Ít bộ đệm hơn có nghĩa đây có thể là một vấn đề và rất ít bộ đệm có nghĩa là với một số cấu trúc dữ liệu lớn, nó sẽ không thành vấn đề.

  • Các cấp độ bộ đệm mới có nghĩa là bạn cần suy nghĩ nhiều hơn về cách bạn sắp xếp các bộ dữ liệu lớn hơn (L1, so với L2, so với L3 so với L4).

  • Nhiều lõi hơn có nghĩa là bạn cần suy nghĩ về cách bạn sẽ sử dụng các ứng dụng đa luồng tốt hơn và cách ứng dụng của bạn mở rộng trong môi trường đa quy trình.

  • Đồng hồ nhanh hơn có nghĩa là bạn cần bắt đầu suy nghĩ về độ trễ bộ nhớ nhiều hơn bạn cần nghĩ về tốc độ tính toán của CPU như một nút cổ chai trong hệ thống của bạn.

  • Số lượng FPU trên một hệ thống có thể không còn phù hợp với số lượng ALU số nguyên trên mỗi lõi nữa (AMD đã có / có các kiến ​​trúc như thế này).

  • Số chu kỳ đồng hồ cần để tính toán một thao tác tôi đã giảm hoặc tăng.

  • Số lượng đăng ký có sẵn thay đổi.

Tất cả những thứ này có tác động hiệu năng rất thực đến các chương trình đưa ra các giả định về kiến ​​trúc cơ bản trong phần cứng trước đó với cùng một ISA, dù là tích cực hay tiêu cực.


"Mức độ tăng hoặc giảm của bộ đệm có nghĩa là bạn cần bớt lo lắng về sự kết hợp bộ đệm." - hầu như bất kỳ CPU nào đều được kết hợp bộ đệm. Bạn có nghĩa là chia sẻ sai? Thậm chí hơn hầu như bất kỳ dòng CPU $ nào hầu như luôn luôn là 64 B ...
Maciej Piechotka

1
Maciej chỉ lấy tuyên bố của bạn về sự kết hợp bộ đệm :) Bạn có thể có nghĩa là "tối ưu hóa bộ đệm" hoặc một cái gì đó. Sự kết hợp bộ nhớ cache là khả năng của một hệ thống để giữ một cái nhìn nhất quán về bộ nhớ trong suốt cho phần mềm ngay cả khi có sự hiện diện của bộ đệm độc lập N. Điều này là hoàn toàn trực giao với kích thước. TBH tuyên bố không thực sự phù hợp nhưng câu trả lời của bạn (đặc biệt là điểm 5 & 6) giải quyết câu hỏi tốt hơn so với IMO được chấp nhận :) Có thể nhấn mạnh sự khác biệt giữa kiến ​​trúc và kiến ​​trúc u sẽ khiến nó nổi bật hơn.
Margaret Bloom

4
"Giống như phép nhân mất nhiều thời gian hơn so với phép cộng, trong khi ngày nay trên CPUS intel và amd hiện đại, nó mất cùng một lượng thời gian" Điều đó không hoàn toàn đúng. Trong các kiến ​​trúc đường ống, bạn phải phân biệt giữa độ trễ (khi kết quả đã sẵn sàng) và thông lượng (số lượng bạn có thể làm trong mỗi chu kỳ). Bổ sung Int trên bộ xử lý Intel hiện đại có thông lượng là 4 và độ trễ là 1. Nhân có thông lượng 1 và độ trễ 3 (hoặc 4). Đây là những điều thay đổi theo từng kiến ​​trúc và cần tối ưu hóa. Ví dụ: pdepmất 1 chu kỳ trên intel nhưng 6 trên Ryzen nên có thể không muốn sử dụng nó trên Ryzen.
Christoph

2
@Clearer Tôi biết chúng ta đang nói về CPU ở đây, nhưng bạn chưa bao giờ lập trình cho GPU phải không? Cùng một mã tạo ra các kết quả rất khác nhau về hiệu suất mà thường bạn thực sự buộc phải xem xét các khả năng phần cứng trong CUDA. Đó là nơi tôi đến từ đây, kích thước bộ đệm (bộ nhớ dùng chung, bộ đệm L1 được quản lý) thực sự cần được xem xét trong cách bạn mã hóa một cái gì đó trong CUDA.
opa

2
@Christoph đúng. Điểm chuẩn bạn liên kết là cho một vòng lặp trên một mảng c[i] = a[i] OP b[i](tức là 2 lần tải và 1 lần lưu trữ cho mỗi thao tác) vì vậy thời gian bị chi phối bởi băng thông bộ nhớ do cường độ tính toán rất thấp. Kích thước mảng không được hiển thị vì vậy IDK nếu nó phù hợp với L1D. ( gcc4.9 -Ofastrất có khả năng tự động véc tơ các vòng lặp đó, vì vậy bạn thậm chí không đo chi phí cho các hoạt động vô hướng thông thường như là một phần của mã số phức). Dòng đầu tiên của trang đó là QUAN TRỌNG: Phản hồi hữu ích tiết lộ rằng một số biện pháp này là thiếu sót nghiêm trọng. Một bản cập nhật lớn đang trên đường .
Peter Cordes

2

Ngay cả ngoài những thay đổi lớn như hỗ trợ cho các hướng dẫn mới, các nhà sản xuất bộ vi xử lý vẫn liên tục sửa đổi thiết kế của họ để cải thiện hiệu suất và mỗi thiết kế mới có thể có hiệu suất tương đối khác nhau cho mỗi hướng dẫn hoặc kỹ thuật. Có thể bạn đã viết một số mã không phân nhánh được tối ưu hóa cẩn thận cho Model X, nhưng Model Y có bộ dự báo nhánh được cải thiện giúp giảm hình phạt sai cho phiên bản mã không phân nhánh (cũng giải phóng đăng ký được sử dụng ở nơi khác) . Có thể Model Y hỗ trợ tính song song lớn hơn của một lệnh có độ trễ cao nhất định, do đó giờ đây một vòng lặp không được kiểm soát của lệnh đó sẽ giúp bạn có thông lượng tốt hơn, trong khi trên Model X, một chuỗi ngắn hơn là tốt hơn.

Bất kỳ vấn đề nào cũng có thể được giải quyết theo nhiều cách, và mọi chương trình là một tập hợp đan xen của sự đánh đổi và phân bổ tài nguyên, từ điểm tối ưu hóa. Ngay cả những thay đổi nhỏ về tính khả dụng của các tài nguyên đó hoặc chi phí của một đoạn mã nhất định về các tài nguyên đó, cũng có thể có hiệu ứng xếp tầng mang lại lợi thế đáng kể về hiệu suất cho mã này hoặc mã khác. Ngay cả khi một con chip được nâng cấp có "nhiều thứ hơn", thì mỗi thứ có thể xoay được bao nhiêu cân bằng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.