Có bao nhiêu luồng đồng thời trong một ứng dụng?

Question

5, 100, 1000?

Tôi đoán, "nó phụ thuộc", nhưng về cái gì?

Điều gì phổ biến trong các ứng dụng chạy dưới dạng trình nền/dịch vụ máy chủ?

Giới hạn cứng là gì?

Cho rằng máy có thể xử lý khối lượng công việc tổng thể, làm thế nào để tôi xác định xem có bao nhiêu luồng trên không bắt đầu có tác động đến hiệu suất?

Điểm khác biệt quan trọng giữa hệ điều hành là gì?

Điều gì khác cần được xem xét?

Tôi hỏi vì tôi muốn sử dụng các luồng trong ứng dụng để sắp xếp các thành phần phụ của ứng dụng không chia sẻ dữ liệu và được thiết kế để thực hiện công việc của chúng song song. Vì ứng dụng cũng sẽ sử dụng các nhóm luồng để song song một số nhiệm vụ, tôi đã tự hỏi tại thời điểm nào tôi nên bắt đầu nghĩ về số lượng các luồng sẽ chạy tổng cộng.

Tôi biết quy tắc n + 1 là hướng dẫn để xác định số lượng chuỗi đồng thời hoạt động trên cùng một tác vụ để đạt được hiệu suất. Tuy nhiên, tôi muốn sử dụng các chủ đề giống như một quy trình có thể sử dụng các quy trình trong phạm vi rộng hơn, i. e. để tổ chức các nhiệm vụ độc lập không nên can thiệp lẫn nhau.

Trong this related question, một số người khuyên bạn nên giảm thiểu số lượng chủ đề vì độ phức tạp được thêm vào. Với tôi, dường như các chủ đề cũng có thể giúp giữ cho mọi thứ được sắp xếp trật tự hơn và thực sự giảm nhiễu. Đúng không?

Answer 1

Tôi không thể trả lời câu hỏi của bạn về "số tiền là bao nhiêu" nhưng tôi đồng ý rằng bạn không nên sử dụng đề tài cho mọi tác vụ có thể.

Số tối ưu số lượng chủ đề cho hiệu suất của ứng dụng là (n + 1), trong đó n là số lượng bộ xử lý/lõi máy tính/máy quét của bạn.

Số tiền chủ đề thực tế của bạn khác với n + 1, số tiền tối ưu ít hơn và nhận được tài nguyên hệ thống của bạn bị lãng phí khi tính toán chuỗi.

Vì vậy, thông thường bạn sử dụng 1 luồng cho giao diện người dùng, 1 chuỗi cho một số tác vụ chung và (n + 1) chủ đề cho một số tác vụ tính toán lớn.

Answer 2

Lớp học ThreadPool của Microsoft giới hạn 25 chủ đề cho mỗi bộ xử lý. Giới hạn được dựa trên context switching giữa các chủ đề và memory consumed theo từng chuỗi. Vì vậy, đó là một hướng dẫn tốt nếu bạn đang ở trên nền tảng Windows.

Answer 3

Thực ra Ajmastrean hơi lạc hậu. Trích dẫn từ riêng hồ bơi link

Các chủ đề của mình có kích thước mặc định của 250 đề người lao động mỗi sẵn bộ xử lý , và 1000 I/O hoàn đề. Số lượng các chủ đề trong hồ sơ chủ đề có thể được thay đổi bằng cách sử dụng phương pháp Set2axSetMaxThreads.

Nhưng nói chung, tôi nghĩ 25 thực sự là nơi mà luật giảm dần (và khả năng lập trình để theo dõi những gì đang diễn ra) bắt đầu có hiệu lực. Mặc dù Max là đúng, miễn là tất cả các chủ đề đang thực hiện tính toán không chặn n + 1 là số tối ưu, trong thế giới thực, hầu hết các nhiệm vụ luồng tôi thực hiện có xu hướng được thực hiện trên các công cụ với một số loại IO.

Answer 4

Cũng phụ thuộc vào kiến ​​trúc của bạn. Ví dụ. trong NVIDIA GPGPU lib CUDA bạn có thể đặt trên một chủ đề đa xử lý 8 chủ đề 512 mô phỏng. Bạn có thể hỏi tại sao chỉ định mỗi bộ xử lý vô hướng 64 luồng? Câu trả lời là dễ dàng: Nếu tính toán không phải là tính toán bị ràng buộc nhưng bộ nhớ IO bị ràng buộc, bạn có thể ẩn các độ trễ mem bằng cách thực hiện các chủ đề khác. Tương tự áp dụng cho các CPU bình thường. Tôi có thể nhớ rằng đề xuất cho tùy chọn song song để tạo "-j" là sử dụng khoảng 1,5 lần số lõi bạn có. Nhiều nhiệm vụ biên dịch là gánh nặng IO nặng nề và nếu một tác vụ phải chờ đĩa cứng, mem ... bất cứ điều gì, CPU có thể hoạt động trên một luồng khác.

Tiếp theo bạn phải xem xét việc chuyển đổi nhiệm vụ/luồng tốn kém đến mức nào. Ví dụ. nó được cung cấp miễn phí, trong khi CPU phải thực hiện một số công việc cho một chuyển đổi ngữ cảnh. Vì vậy, nói chung bạn phải ước tính nếu hình phạt cho hai công tắc chuyển mạch dài hơn thời gian mà luồng sẽ chặn (phụ thuộc nhiều vào các ứng dụng của bạn).