Tại sao các quy trình không ưu tiên tạo ra sự cải thiện tốc độ?


18

Tôi đã có 2 ứng dụng sử dụng nhiều tài nguyên hệ thống. Khi tôi giảm mức độ ưu tiên của một trong Trình quản lý tác vụ, trong khi tăng mức độ khác, tôi không nhận thấy bất kỳ sự cải thiện đáng kể nào về tốc độ trong ứng dụng với mức độ ưu tiên cao hơn.

Tại sao lại thế này? Có nhiều việc đang diễn ra hay còn nhiều việc cần phải làm?


6
Nó giống như cuộc sống thực. Nếu bạn có mức độ ưu tiên cao hơn khi lên máy bay so với hành khách khác, điều đó không có nghĩa là chuyến bay sẽ mất ít thời gian hơn cho bạn!
Mehrdad

Câu trả lời:


28

Ưu tiên không giúp ích khi nút cổ chai là chính CPU. Ưu tiên thực sự là gì ảnh hưởng đến thuật toán lập lịch mà Hệ điều hành sử dụng để xác định quá trình nào chạy tiếp theo vì không có đủ bộ xử lý trong hầu hết các hệ thống để chạy mọi quy trình liên tục.

Một nhiệm vụ có mức độ ưu tiên cao hơn sẽ nhanh chóng đi đến đỉnh của hàng đợi, vì vậy điều này sẽ giúp cho độ trễ chung, nhưng nếu quá trình của bạn làm cạn kiệt toàn bộ thời gian thì nó được phân bổ trên tính toán thực tế, việc lập lịch trình sẽ không thay đổi bất cứ điều gì ở đó. Thay đổi mức ưu tiên sẽ hữu ích hơn khi bạn có một quy trình đang chờ trên I / O và bạn muốn nó được phản hồi nhanh hơn.


5
Ưu tiên giúp đỡ khi nút cổ chai có quá nhiều luồng có thể chạy được. Các luồng có mức độ ưu tiên cao hơn trên Windows vẫn có thể chạy được vào cuối thời gian của chúng sẽ có một cơ hội khác để chạy theo mức độ ưu tiên cho luồng có mức độ ưu tiên thấp hơn (Windows cố gắng không bỏ đói các luồng có mức độ ưu tiên thấp và đôi khi tăng cường chúng). Ưu tiên ít ảnh hưởng đến các luồng chờ I / O - Windows tạm thời tăng mức độ ưu tiên của luồng sau khi I / O hoàn thành, tùy thuộc vào loại I / O mà nó đang chờ.
Mike Dimmick

4

Ưu tiên là thời gian CPU. Có phải tất cả các lõi được sử dụng 100% mọi lúc? Nếu không, thì ưu tiên sẽ không có hiệu lực. Thông thường, CPU không phải là nút cổ chai và đó là tài nguyên bộ nhớ, đĩa hoặc GPU.


3

Ưu tiên chỉ quan trọng khi có nhiều luồng có thể chạy hơn các lõi CPU có sẵn. Khi điều đó xảy ra, ưu tiên kiểm soát các chủ đề được chạy. Trong hầu hết các hệ thống, không có đủ tính toán xảy ra cho bất kỳ sự tranh chấp nào trên CPU: các luồng đều bị chặn , chờ đợi điều gì đó xảy ra. Điều đó có thể đang chờ bạn nhập nội dung nào đó, di chuyển chuột, chạm vào màn hình hoặc để dữ liệu đến từ đĩa, mạng, một số thiết bị khác mà bạn đã cắm hoặc để một luồng khác hoàn thành công việc trên dữ liệu quan trọng kết cấu. Nó có thể đang chờ một phần của chương trình được đọc từ đĩa hoặc một số bộ nhớ được hoán đổi để đọc lại, thay vì đọc một tệp rõ ràng.

Trong Windows, bộ lập lịch giữ một hàng các chuỗi có thể chạy ở mỗi mức ưu tiên. Khi nó đưa ra quyết định lập lịch - hoặc là một luồng đã cạn kiệt lượng tử của nó (thời gian cho phép trước khi có thứ gì khác cần chạy), nghĩa là một luồng khác sẽ quay đầu, hoặc luồng bị chặn và không còn chạy được nữa, hoặc mức độ ưu tiên cao hơn luồng đã được bỏ chặn - luồng tiếp theo trong hàng đợi ở mức ưu tiên cao nhất với bất kỳ luồng nào có thể chạy được sẽ được lên lịch. Nếu luồng đang chạy đã sử dụng hết lượng tử của nó, thì nó sẽ được đặt ở cuối hàng đợi. Nếu đó là luồng duy nhất ở mức ưu tiên có thể chạy được và không có luồng nào có mức ưu tiên cao hơn, nhưng không chạy, thì các luồng sẽ chuyển sang một lượt khác.

Trong các hệ thống đa lõi / đa bộ xử lý, có thể có các hạn chế về lõi mà một luồng có thể chạy trên đó. Ngoài ra, hệ thống cố gắng giữ các luồng trên lõi lý tưởng của chúng và trong nút NUMA của chúng để dữ liệu của luồng có thể vẫn nằm trong bộ đệm của lõi đó và nó có quyền truy cập nhanh vào dữ liệu mà nó tạo ra. Chủ đề vẫn sẽ được chạy trên các lõi không lý tưởng nếu không có lựa chọn nào để chạy tiếp theo.

Hệ thống sử dụng các mức tăng ưu tiên động khác nhau và kích thước lượng tử động để ứng dụng nền trước có nhiều thời gian hơn (nếu cần) so với các quy trình nền và để các quy trình có thể phản ứng nhanh khi các hoạt động I / O hoàn thành (bao gồm chuột, bàn phím và màn hình cảm ứng đầu vào). Ngoài ra, việc tăng mức độ ưu tiên được sử dụng để khắc phục các nghịch đảo ưu tiên, trong đó một luồng có mức độ ưu tiên cao đang chờ một tài nguyên mà luồng có mức độ ưu tiên thấp hiện đang nắm giữ. Nếu có một luồng ưu tiên trung bình cũng đang chạy, nó sẽ bỏ đói luồng ưu tiên thấp của thời gian xử lý, giữ luồng ưu tiên cao. Vì vậy, luồng ưu tiên thấp tạm thời được tăng lên mức ưu tiên cao hơn để có thời gian và hy vọng giải phóng tài nguyên mà luồng ưu tiên cao cần.

Trước Windows Vista, mức độ ưu tiên của luồng không ảnh hưởng đến tốc độ hoàn thành các thao tác I / O. Kể từ Windows Vista, I / O cũng có thể có mức độ ưu tiên, theo mặc định xuất phát từ mức độ ưu tiên của luồng.

Tóm tắt: bạn hầu như sẽ không thấy bất kỳ ảnh hưởng nào của việc thay đổi mức độ ưu tiên của luồng trừ khi CPU của bạn được tải rất nhiều và thậm chí sau đó hiệu ứng sẽ thường là tối thiểu. Nếu quá trình phải chờ I / O hoặc nó không tranh chấp với các tiến trình khác trong thời gian CPU, thì nó đã chạy nhanh nhất có thể và việc thay đổi mức độ ưu tiên sẽ không làm cho nó nhanh hơn.


0

Nói chung, phải mất thêm nỗ lực để làm cho một chương trình sử dụng nhiều CPU (bằng cách thêm đa luồng). Vì vậy, ngay cả khi chương trình có mức ưu tiên khả dụng cao nhất, nó chỉ có thể được sử dụng một lõi.

Các vấn đề khác có thể xảy ra:

  • Chương trình có thể không hiệu quả / viết kém
  • Nó có thể bị chậm do truy cập đĩa "chậm" hoặc mạng chậm

0

Ngay cả việc tăng mức độ ưu tiên I / O của quy trình ràng buộc I / O sẽ không nhất thiết khiến nó chạy nhanh hơn. Ví dụ: nếu đó là người tiêu dùng dữ liệu được tạo bởi một quy trình riêng biệt, có thể là từ xa và theo kịp tốc độ mà nguồn đó tạo ra dữ liệu, thì nó không thể đi nhanh hơn hoặc có thông lượng cao hơn.

Trái với những gì được nêu một cách cụ thể trong câu đầu tiên của câu trả lời hiện được chấp nhận ( /superuser//a/752587/322588 ), các thay đổi ưu tiên có hiệu quả nhất khi CPU là nút cổ chai, như được giải thích trong câu trả lời của Mike Dimmick ( /superuser//a/752864 / 322588 ). Hơn nữa, tuyên bố trong đoạn thứ hai của câu trả lời được chấp nhận, "nếu quy trình của bạn cạn kiệt toàn bộ thời gian thì nó được phân bổ trên tính toán thực tế thì việc lập lịch sẽ không thay đổi bất cứ điều gì" trừ khi quy trình nói chung có mức độ ưu tiên cao nhất chủ đề runnable bất cứ khi nào nó đang chờ để chạy. Điều này là do trong tất cả các trường hợp khác, việc tăng mức độ ưu tiên có thể sẽ nhận được nhiều thời gian hơn trên mỗi khoảng thời gian trên đồng hồ treo tường.

Mike Dimmick đã chỉ ra những vấn đề với câu trả lời này vài ngày trước, và đưa ra một câu trả lời tốt hơn nhiều, nhưng lần đầu tiên không thể giải thích được vẫn tiếp tục giành được phiếu bầu. Tác giả của nó tuyên bố rằng anh ta chỉ đơn thuần làm giảm bớt câu trả lời của mình cho người giả là không hợp lý, bởi vì nó không chỉ đơn giản, hoặc thậm chí đơn giản, nó hoàn toàn sai, ít nhất là liên quan đến các quy trình liên quan đến CPU.

Tuyên bố miễn trừ trách nhiệm: Tôi không biết ông Dimmick, mặc dù tôi có thể nói ông ta biết ông ta đang viết về cái gì.


Có lẽ bạn đã hiểu lầm; câu hỏi là về các quy trình chạy nhanh hơn. Các quy trình liên kết với CPU sẽ làm cạn kiệt toàn bộ đơn vị lập lịch (lượng tử) của chúng và sau đó đi vào hàng đợi các quy trình sẵn sàng ở cuối. Trong một hệ điều hành máy tính để bàn như Windows, điều đó có nghĩa là quá trình này có cơ hội 1 / lượng tử-Hz để chạy mỗi giây. Thay đổi mức độ ưu tiên (nói chung) không thay đổi độ dài thời gian của nó. Nó sẽ luôn luôn lấy cùng một số lượng tử lập lịch để hoàn thành. Điều quan trọng , đây là cách Windows thực sự đo thời gian chạy: số lượng tử được lên lịch.
Andon M. Coleman

Quá trình có thể kết thúc sớm hơn, nhưng nó vẫn chạy cho cùng một số đơn vị lập lịch. Khi một quy trình ràng buộc I / O tự đặt nó vào danh sách chờ, nó có thể có cơ hội thứ hai để chạy và ưu tiên một quy trình đang chạy với mức độ ưu tiên thấp hơn trước khi lượng tử của nó hết hạn nếu hoạt động I / O của nó hoàn thành. Các quy trình liên kết với CPU không có quyền tự do này, chúng làm cạn kiệt toàn bộ thời gian của chúng và sau đó đi vào hàng đợi sẵn sàng. Nó có thể cho chúng chạy ngay lập tức sau đó nếu họ có một ưu tiên đủ cao, nhưng điều đó không có gì để làm với cách Windows đo thời gian thực hiện.
Andon M. Coleman

Ưu tiên cho quá trình ràng buộc I / O chờ đợi về cơ bản là khác nhau và nó có thể có tác động có thể đo lường được đối với thời gian chạy được báo cáo trong Windows. Một lần nữa, Windows đo thời gian chạy là số lượng tử đã hết hạn (ngay cả khi một quá trình dành 1 ms trong số lượng tử 10 ms thực sự đang chạy và sau đó tự nguyện đợi 9 ms còn lại cho I / O, hạt nhân Windows tính là 10 ms của thời gian chạy chế độ người dùng). Ưu tiên có thể giúp các ứng dụng ràng buộc I / O mất ít lượng tử hơn để hoàn thành. Các hạt nhân khác (ví dụ Linux) có thể đo chính xác lượng tử một phần trong thời gian chạy của quy trình, nhưng Windows thì không thể.
Andon M. Coleman

@ AndonM.Coleman Kể từ Vista và sau này, vâng, nó có thể và làm được.
Jamie Hanrahan

@JamieHanrahan: Chà, bạn luôn có thể gọi timeBeginPeriod (...), điều mà bất cứ điều gì tương tác đã làm. Một trò chơi thường sẽ đặt thành 1 khi trò chơi bắt đầu và áp dụng khoảng thời gian lập lịch 1 ms trên bảng cho mọi thứ chạy trên hệ thống. Nó không bị cô lập với quá trình đã làm nó. Đó là một phần lý do khiến Windows khó có thể thực hiện nghiêm túc việc đa tác vụ.
Andon M. Coleman
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.