Có bao nhiêu CPU nên được sử dụng với Hyperthreading?

Giả sử tôi có một cpu máy chủ với 18 lõi, với khả năng siêu phân luồng, điều đó có nghĩa là tôi có thể thấy 36 cpus trong htop.

Để sử dụng đầy đủ CPU và không ảnh hưởng đến hiệu suất của một luồng, tôi nên nhắm tới tất cả 36 "lõi" để chạy ở mức 100% và các lõi HT sẽ chỉ hoạt động ít hơn và vẫn báo cáo 100%, hoặc có nghĩa là Các lõi "đầy đủ" đã bị gián đoạn bởi tác vụ trên "lõi HT" của nó và do đó thực hiện công việc đơn luồng ít hơn?

Tôi biết rằng có rất nhiều biến số ảnh hưởng đến hiệu suất HT, tôi chỉ muốn biết máy đo cpu có ý nghĩa gì khi giao dịch với HT.

Nếu lõi ảo thứ hai được phép đóng góp khi lõi thứ nhất bị kẹt, thì tốt hơn là không , vì vậy bạn sẽ nhận được (ít nhất) một chút công việc phụ được thực hiện.

Câu hỏi trở thành: khi nào có hai luồng khác nhau khiến một luồng chạy tệ hơn? Dự đoán chi nhánh và sự phụ thuộc giữa các hướng dẫn sẽ không thay đổi. Đang chờ truy cập bộ nhớ ngay bây giờ ... hai luồng cạnh tranh về quyền truy cập bộ nhớ, cả về sử dụng bộ nhớ cache và băng thông.

Nếu bạn có một số CPU chạy với HT và các CPU khác thì không, điều đó cũng có nghĩa là bạn sẽ gán các luồng cụ thể cho loại này hay loại khác? Tôi nghĩ là không: các chương trình của bạn sẽ chạy các luồng của chúng trên các lõi ảo ngẫu nhiên. Vậy làm thế nào để chia cấu hình giúp? Vì mỗi CPU có bộ đệm riêng, ảnh hưởng duy nhất là do băng thông bộ nhớ và gánh nặng của sự kết hợp bộ đệm.

Nói chung, bạn đạt đến một điểm mà việc có nhiều thứ bạn có thể làm sẽ tốn kém hơn là để một số đơn vị thực thi CPU không hoạt động. Điều này không phụ thuộc vào số lượng luồng trực tiếp, mà phụ thuộc vào những gì luồng đang làm , và kiến ​​trúc bộ nhớ chi tiết và sắc thái hiệu suất của các thành phần khác nhau.

Không có câu trả lời đơn giản. Ngay cả với một chương trình cụ thể trong tâm trí, máy có thể khác với những người liên quan đến trải nghiệm của chính họ.

Bạn phải tự mình thử và đo những gì nhanh nhất, với công việc cụ thể đó trên máy chính xác đó. Và thậm chí sau đó, nó có thể thay đổi với các bản cập nhật phần mềm và thay đổi sử dụng theo thời gian.

Hãy xem tập 3 của kiệt tác của Anger . Nếu bạn xem xét kỹ một số bộ xử lý cụ thể, bạn có thể tìm thấy các tài nguyên giới hạn trong số các bước sâu của nhiều bước cần thiết để thực thi mã. Bạn cần tìm một trường hợp trong đó tình trạng quá tải khiến nó hoạt động chậm hơn, trái ngược với việc không đảm nhận nhiều công việc hơn. Nói chung điều đó có nghĩa là một số loại bộ nhớ đệm; và nơi tài nguyên được chia sẻ giữa các chủ đề.

Máy đo CPU có nghĩa là gì: nó báo cáo tất cả thời gian không dành cho việc chạy luồng nhàn rỗi. Cả hai luồng logic được gán cho lõi sẽ không ở chế độ chờ mặc dù công việc thực tế được thực hiện trên một trong số chúng có thể nhỏ. Thời gian dành cho đường ống bị kẹt trong một vài chu kỳ cho đến khi kết quả sẵn sàng, bộ nhớ được tải xuống, các hoạt động nguyên tử được rào lại, v.v., do đó, không làm cho luồng bị tạm dừng là "không sẵn sàng" vì vậy nó sẽ không hoạt động, và thời gian vẫn hiển thị như đang sử dụng. Chờ đợi trên RAM sẽ không hiển thị dưới dạng nhàn rỗi. Chỉ một cái gì đó như I / O sẽ làm cho khối luồng và ngừng sạc thời gian đối với nó. Một mutex hệ điều hành nói chung sẽ làm như vậy, nhưng với sự gia tăng của các hệ thống đa lõi không còn là điều chắc chắn nữa, vì một "spinlock" sẽ không làm cho luồng trở lại trên kệ.

Vì vậy, đồng hồ CPU 100% không có nghĩa là tất cả đều hoạt động trơn tru, nếu CPU thường bị kẹt chờ bộ nhớ. Một số lượng ít hơn các lõi logic cho thấy 90% rất có thể sẽ hoàn thành được nhiều công việc hơn, vì nó hoàn thành số lượng khủng hoảng và hiện đang chờ trên đĩa.

Vì vậy, đừng lo lắng về đồng hồ CPU. Nhìn vào tiến độ thực tế, chỉ .

Đồng hồ đo CPU rất tệ khi cho bạn biết hiệu năng bạn có thể vắt kiệt hơn bao nhiêu so với CPU siêu phân luồng của bạn. Vì thế, bạn nên chạy điểm chuẩn của riêng mình với các mức giá đăng ký vượt mức cốt lõi khác nhau. Có một số khối lượng công việc hoạt động tốt nhất với HT hoàn toàn bị tắt, vì vậy hãy đưa trường hợp đó vào thử nghiệm của bạn. Đó có thể là tỷ lệ 1: 2 (36 công nhân song song) hoặc 1: 1.5 hoặc thậm chí 1: 2.5! Nó phụ thuộc vào khối lượng công việc của bạn.

Chi tiết hơn, HT được triển khai trên silicon theo cách giảm thời gian bộ xử lý nhàn rỗi khi bối cảnh cần chuyển đổi hoặc dự đoán nhánh không thành công. Điều này giúp dễ dàng đạt được mức sử dụng đơn vị thực thi 100% hơn so với các thủ thuật hệ điều hành thuần túy. HT đã phát triển kể từ khi được giới thiệu, và có nhiều sự song song trên các chip hiện đại hơn so với những gì chúng ta đã sử dụng 10 năm trước.

Có hai hồ sơ thực hiện sẽ ảnh hưởng đến điểm đăng ký vượt mức tối ưu của bạn là:

• Thời gian thực hiện dài . Nếu công nhân của bạn chạy trong vài phút hoặc vài giờ trước khi tái chế, chẳng hạn như công việc kết xuất lớn hoặc mô hình hóa môi trường, bạn sẽ có hiệu suất lõi đơn hiệu quả hơn cho mỗi công nhân. Điều này sẽ làm giảm tỷ lệ của bạn.
• Thời gian thực hiện ngắn . Nếu nhân viên của bạn quay vòng trong vài giây hoặc vài phút, chẳng hạn như các luồng ứng dụng web, thì chi phí liên quan đến việc bật quy trình mới có nghĩa là tỷ lệ của bạn sẽ cao hơn.

Bạn sẽ thấy tất cả 36 lõi hoạt động ở mức 100% - giả sử phần mềm có thể làm điều đó (điều này không tầm thường - việc lập lịch trình có thể khó khăn với nhiều lõi đó, vì vậy việc giảm xuống dưới 100% là chấp nhận được).

Rõ ràng khi bạn "tách" quặng với siêu phân luồng, ý nghĩa của 200% đó không phải là "2x100% - trong công việc được thực hiện. Nhưng điều này là vô hình đối với bất kỳ phép đo nào được thực hiện (xuất phát từ việc sử dụng CPU và không có khái niệm về công việc được thực hiện). Bao nhiêu công việc này được thực hiện tùy thuộc vào công việc là gì - ở đâu đó trên 1,5 x công việc mà không siêu phân luồng sẽ được mong đợi hầu hết thời gian.

Cách thức siêu phân luồng được thực hiện thay đổi theo uarch CPU cụ thể. Từ Nehalem đến Skylake, Intel đã giảm đáng kể tỷ lệ cố định (nghĩa là: 50/50) các phần được chia sẻ của đường ống, hướng đến các cấu trúc chia sẻ thực tế.

Dù sao, nói chung, việc cho phép HT dẫn đến việc thực thi một luồng chậm hơn một cách chậm chạp, nhưng do cách lập lịch của Linux hoạt động, điều này chỉ xảy ra khi số lượng hoặc luồng chạy cao hơn số lõi vật lý. Như trong các tình huống như vậy (khi các luồng> lõi), bạn thường đánh giá tổng thông lượng có tầm quan trọng tối đa, siêu phân luồng vẫn là một chiến thắng ròng.

Làm thế nào điều này là có thể? Điểm mấu chốt cần hiểu là CPU không trình bày các lõi vật lý và các lõi ảo là các lõi bằng nhau, thay vào đó, nó phơi bày cái sau theo cách mà bộ lập lịch Linux có thể tránh lập lịch cho chúng nếu có bất kỳ lõi vật lý nào khác. Nói cách khác, đầu tiên nó sử dụng tất cả các lõi vật lý, sau đó nó bắt đầu sử dụng lõi ảo.

Điều này có nghĩa là, nói chung, HyperThreading là một tính năng rất có giá trị (các bộ xử lý khác, như Power8, sử dụng các kỹ thuật SMT sâu hơn) và để tối đa hóa thông lượng, bạn nên kích hoạt nó, tải CPU với ít nhất một luồng trên mỗi lõi ảo hoặc vật lý. Để có một ví dụ thực tế, để trích xuất hiệu suất đầy đủ từ CPU 18 lõi, bạn nên sử dụng ít nhất 36 luồng.

Hai trường hợp ngoại lệ tồn tại:

1. nếu tất cả những gì bạn muốn là giảm thiểu độ trễ từ một nhóm các luồng bị giới hạn (trong đó các luồng <lõi vật lý), bạn có thể tắt HT
2. CPU rất cũ (Pentium4 và, theo cách nhỏ hơn nhiều, Nehalem) có các quy tắc phân vùng không linh hoạt, buộc CPU phải phân chia nhiều tài nguyên chính ở tỷ lệ 50/50, độc lập với trạng thái / tải của luồng thứ hai. Trong trường hợp này, bạn phải định chuẩn trường hợp sử dụng của mình để chắc chắn rằng thông lượng được thêm vào có giá trị hiệu suất luồng đơn thấp hơn đáng kể.