Tại sao một chương trình sẽ yêu cầu số lượng lõi CPU tối thiểu cụ thể?

Có thể viết mã (hoặc phần mềm hoàn chỉnh, thay vì một đoạn mã) sẽ không hoạt động đúng khi chạy trên CPU có ít hơn N số lõi? Không kiểm tra nó một cách rõ ràng và thất bại về mục đích:

NẾU (noOfCores <4) THÌ không chạy đúng mục đích

Tôi đang xem xét các yêu cầu hệ thống tối thiểu của trò chơi ( Dragon Age: Inquisition ) và nó chỉ ra tối thiểu CPU bốn lõi. Nhiều người chơi nói rằng nó KHÔNG chạy trên CPU hai lõi và NGAY trên Intel Core i3 với hai lõi vật lý và hai lõi logic. Và đó KHÔNG phải là vấn đề về sức mạnh tính toán.

Theo hiểu biết của tôi, các luồng được cách ly hoàn toàn khỏi CPU bởi HĐH vì điều đó không thể thực hiện được.

Chỉ để xóa mọi thứ:

Tôi KHÔNG hỏi "Tôi có thể tìm ra số lượng lõi CPU từ mã không và có mục đích không?" ... Mã như vậy sẽ không có ý định (buộc bạn phải mua CPU đắt tiền hơn để chạy chương trình - mà không cần năng lượng tính toán). Tôi đang yêu cầu mã của bạn, có bốn luồng và không thành công khi hai luồng được chạy trên cùng một lõi vật lý (mà không kiểm tra rõ ràng thông tin hệ thống và cố tình không thành công) .

Nói tóm lại, có thể có phần mềm yêu cầu nhiều lõi, mà không cần sức mạnh tính toán bổ sung đến từ nhiều lõi không? Nó sẽ chỉ yêu cầu N lõi vật lý riêng biệt.

Có thể làm điều này "một cách tình cờ" với việc sử dụng mối quan hệ cốt lõi bất cẩn. Hãy xem xét các mã giả sau đây:

• bắt đầu một chủ đề
• trong luồng đó, tìm xem nó đang chạy trên lõi nào
• đặt ái lực CPU của nó vào lõi đó
• bắt đầu làm một cái gì đó tính toán chuyên sâu / vòng lặp mãi mãi

Nếu bạn khởi động bốn trong số đó trên CPU hai lõi, thì có điều gì đó không ổn với cài đặt mối quan hệ cốt lõi hoặc bạn kết thúc với hai luồng gây ra các lõi có sẵn và hai luồng không bao giờ được lên lịch. Không có gì rõ ràng nó đã hỏi tổng cộng có bao nhiêu lõi.

(Nếu bạn có các luồng chạy dài, việc đặt ái lực CPU thường cải thiện thông lượng)

Ý tưởng rằng các công ty game đang "buộc" mọi người mua phần cứng đắt tiền hơn mà không có lý do chính đáng nào là không hợp lý. Nó chỉ có thể mất khách hàng của họ.

Chỉnh sửa: bài đăng này hiện đã có 33 lượt upvote, khá nhiều cho rằng nó dựa trên phỏng đoán có giáo dục!

Dường như mọi người đã có DA: Tôi chạy, rất tệ, trên các hệ thống lõi kép: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ Phân tích đó đề cập rằng tình hình sẽ cải thiện đáng kể nếu siêu phân luồng được bật. Do HT không thêm bất kỳ đơn vị vấn đề hướng dẫn hoặc bộ đệm nào, nó chỉ cho phép một luồng chạy trong khi một luồng khác nằm trong gian hàng bộ đệm, điều đó cho thấy mạnh mẽ rằng nó được liên kết hoàn toàn với số lượng luồng.

Một poster khác tuyên bố rằng việc thay đổi trình điều khiển đồ họa hoạt động: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; cho rằng trình điều khiển đồ họa có xu hướng là một tổ ong tồi tệ của cặn bã và dân làng, điều này không đáng ngạc nhiên. Một bộ trình điều khiển khét tiếng có chế độ "chính xác & chậm" so với "nhanh & không chính xác" đã được chọn nếu được gọi từ QUAKE.EXE. Các trình điều khiển hoạt động khác nhau đối với số lượng CPU rõ ràng khác nhau. Có lẽ (quay lại đầu cơ) một cơ chế đồng bộ hóa khác được sử dụng. Lạm dụng spinlocks ?

"Sử dụng sai các nguyên tắc khóa và đồng bộ hóa" là một nguồn rất phổ biến của các lỗi. (Lỗi tôi phải xem xét tại nơi làm việc trong khi viết đây là "sự cố nếu thay đổi cài đặt máy in cùng lúc khi công việc in kết thúc").

Chỉnh sửa 2: bình luận đề cập đến hệ điều hành cố gắng tránh chết đói luồng. Lưu ý rằng trò chơi có thể có bộ lập lịch nội bộ riêng để phân công công việc cho các luồng và sẽ có một cơ chế tương tự trong chính card đồ họa (đây thực sự là một hệ thống đa nhiệm). Cơ hội của một lỗi trong một trong số đó hoặc sự tương tác giữa chúng là khá cao.

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) là một luận án tốt nghiệp về lập lịch tốt hơn cho các card đồ họa trong đó đề cập rõ ràng rằng họ thường sử dụng lập lịch trước được phục vụ trước, dễ thực hiện trong hệ thống không phòng ngừa. Tình hình đã được cải thiện? Chắc là không.

Có thể cần phải có 4 lõi vì ứng dụng chạy bốn tác vụ theo các luồng song song và hy vọng chúng sẽ hoàn thành gần như đồng thời.

Khi mỗi luồng được thực thi bởi một lõi riêng biệt và tất cả các luồng có cùng khối lượng công việc tính toán chính xác, chúng hoàn toàn có khả năng (nhưng không được đảm bảo) để hoàn thành gần như cùng một lúc. Nhưng khi hai luồng chạy trên một lõi, thời gian sẽ ít dự đoán hơn vì lõi sẽ chuyển ngữ cảnh giữa hai luồng mọi lúc.

Lỗi xảy ra do thời gian xử lý luồng không mong muốn được gọi là " điều kiện cuộc đua ".

Trong bối cảnh phát triển trò chơi, một kiến ​​trúc hợp lý với loại vấn đề này có thể là một trong đó các tính năng khác nhau của trò chơi được mô phỏng theo thời gian thực bởi các luồng CPU khác nhau. Khi mỗi tính năng chạy trên một lõi riêng, tất cả chúng đều được mô phỏng với tốc độ gần như nhau. Nhưng khi hai tính năng chạy trên một lõi, cả hai sẽ chỉ được mô phỏng nhanh bằng một nửa so với phần còn lại của thế giới trò chơi, có thể gây ra tất cả các loại hành vi kỳ lạ.

Lưu ý rằng một kiến ​​trúc phần mềm phụ thuộc vào các luồng độc lập chạy với thời gian cụ thể là cực kỳ mong manh và là dấu hiệu của sự hiểu biết rất xấu về lập trình đồng thời. Trên thực tế, có tất cả các tính năng có sẵn trong tất cả các API đa luồng để đồng bộ hóa các luồng một cách rõ ràng để ngăn chặn các loại vấn đề này.

Không chắc là những "yêu cầu tối thiểu" này đại diện cho thứ gì đó bên dưới mà trò chơi sẽ không chạy. Nhiều khả năng là chúng đại diện cho thứ gì đó bên dưới mà trò chơi sẽ không chạy với hiệu suất chấp nhận được. Không có công ty trò chơi nào muốn đối phó với nhiều khách hàng phàn nàn về hiệu suất khủng khiếp khi họ đang chạy nó trên hộp 1 Ghz lõi đơn, ngay cả khi phần mềm có thể chạy kỹ thuật. Vì vậy, họ có thể cố tình thiết kế để thất bại cứng trên các hộp có ít lõi hơn sẽ mang lại cho họ hiệu suất chấp nhận được.

Một số liệu quan trọng trong hiệu suất trò chơi là tốc độ khung hình. Thông thường họ chạy ở tốc độ 30 hoặc 60 khung hình mỗi giây. Điều này có nghĩa là công cụ trò chơi phải hiển thị chế độ xem hiện tại từ trạng thái trò chơi trong một khoảng thời gian cố định. Để đạt được 60 khung hình / giây, chỉ cần hơn 16 ms để thực hiện điều này. Các trò chơi có đồ họa cao cấp bị ràng buộc rất nhiều về CPU và do đó, có một sự cho và nhận lớn giữa việc cố gắng đẩy chất lượng cao hơn (cần nhiều thời gian hơn) và cần phải duy trì ngân sách thời gian này. Vì vậy, ngân sách thời gian cho mỗi khung hình là vô cùng chặt chẽ.

Vì ngân sách thời gian eo hẹp, nhà phát triển lý tưởng muốn truy cập độc quyền vào một hoặc nhiều lõi. Họ cũng có khả năng muốn có thể thực hiện công cụ kết xuất của mình trong lõi, vì đó là những gì phải hoàn thành trong ngân sách thời gian đó, trong khi những thứ khác, như tính toán trạng thái thế giới, xảy ra trên một quy trình riêng biệt, nơi nó sẽ không xâm nhập.

Về lý thuyết, bạn có thể nhồi nhét tất cả những thứ này vào một lõi, nhưng sau đó mọi thứ trở nên khó khăn hơn nhiều. Đột nhiên bạn phải đảm bảo tất cả những thứ trạng thái trò chơi đó xảy ra đủ nhanh và cho phép kết xuất của bạn xảy ra. Bạn không thể biến chúng thành hai luồng phần mềm vì không có cách nào để HĐH hiểu "luồng A phải hoàn thành khối lượng công việc X trong 16 ms bất kể luồng B làm gì".

Các nhà phát triển trò chơi không quan tâm đến việc khiến bạn mua phần cứng mới. Lý do họ có yêu cầu hệ thống là chi phí hỗ trợ các máy cấp thấp hơn không đáng.

Ba chủ đề thời gian thực không bao giờ ngủ và một chủ đề khác. Nếu có ít hơn bốn lõi, luồng thứ tư không bao giờ chạy. Nếu luồng thứ tư cần giao tiếp với một trong các luồng thời gian thực để luồng thời gian thực kết thúc, mã sẽ không kết thúc với ít hơn bốn lõi.

Rõ ràng nếu các chủ đề thời gian thực đang chờ đợi một cái gì đó không cho phép chúng ngủ (chẳng hạn như một spinlock), nhà thiết kế chương trình đã làm hỏng.

Trước hết, các luồng phần mềm không liên quan gì đến các luồng phần cứng và thường bị lẫn lộn. Các luồng phần mềm là các đoạn mã hơn có thể được gửi và tự chạy trong bối cảnh quy trình. Các luồng phần cứng hầu hết được quản lý bởi HĐH và được gửi đến lõi của bộ xử lý khi nói về các chương trình thông thường. Các luồng phần cứng này được gửi dựa trên tải; bộ điều phối luồng phần cứng hoạt động ít nhiều giống như một bộ cân bằng tải.

Tuy nhiên, khi nói đến chơi game, đặc biệt là chơi game cao cấp, đôi khi các luồng phần cứng được quản lý bởi chính trò chơi hoặc trò chơi hướng dẫn người điều phối luồng phần cứng phải làm gì. Đó là bởi vì mọi nhiệm vụ hoặc nhóm nhiệm vụ không có cùng mức độ ưu tiên như trong một chương trình bình thường. Bởi vì tuổi rồng đến từ một studio trò chơi cao cấp sử dụng các công cụ trò chơi cao cấp, tôi có thể tưởng tượng rằng nó sử dụng công văn "thủ công" và sau đó số lượng lõi trở thành một yêu cầu hệ thống tối thiểu. Bất kỳ chương trình nào cũng gặp sự cố khi tôi gửi một đoạn mã đến lõi vật lý thứ 3 chạy trên máy chỉ có 1 hoặc 2 lõi.

Vì có thể sử dụng ảo hóa để có nhiều lõi ảo hơn vật lý và phần mềm sẽ không biết nó đang chạy trên ảo hóa và thay vào đó nghĩ rằng nó có nhiều lõi vật lý, tôi sẽ nói rằng phần mềm như vậy là không thể.

Điều đó có nghĩa là, không thể viết phần mềm sẽ luôn dừng trên ít hơn N lõi.

Như những người khác đã chỉ ra, có những giải pháp phần mềm có khả năng kiểm tra, đặc biệt là nếu hệ điều hành và mã được sử dụng có ít sự bảo vệ chống lại các điều kiện chủng tộc khi các quá trình N chạy trên bộ xử lý <N. Thủ thuật thực sự là mã sẽ thất bại khi bạn có ít hơn bộ xử lý N nhưng sẽ không thất bại khi bạn có bộ xử lý N nhưng có một hệ điều hành có thể gán công việc cho ít hơn bộ xử lý N.

Có thể có ba luồng làm một cái gì đó (tạo nền hoặc tạo chuyển động NPC) và chuyển các sự kiện sang một thứ tư, được cho là tổng hợp / lọc các sự kiện và cập nhật mô hình xem. Nếu luồng thứ tư không nhận được tất cả các sự kiện (vì nó không được lên lịch trên lõi) thì mô hình khung nhìn sẽ không được cập nhật chính xác. Điều này chỉ có thể xảy ra lẻ tẻ, nhưng những lõi đó cần phải có sẵn tại bất kỳ thời điểm nào. Điều này có thể giải thích tại sao bạn không thấy sử dụng CPU cao mọi lúc, nhưng dù sao thì trò chơi vẫn không hoạt động bình thường.

Tôi nghĩ Joshua đang đi đúng hướng, chỉ là chưa đi đến kết luận.

Giả sử bạn có một kiến ​​trúc trong đó có ba luồng được viết để làm nhiều nhất có thể - khi họ hoàn thành những gì họ đang làm, họ sẽ làm lại. Để duy trì hiệu suất, các luồng này không giải phóng quyền kiểm soát cho bất cứ điều gì - chúng không muốn mạo hiểm độ trễ từ bộ lập lịch tác vụ Windows. Chừng nào có 4 lõi trở lên thì nó hoạt động tốt, nó sẽ thất bại nặng nề nếu không có.

Nói chung đây sẽ là lập trình tồi nhưng game lại là vấn đề khác - khi bạn phải đối mặt với sự lựa chọn giữa một thiết kế kém hơn tất cả phần cứng hoặc thiết kế vượt trội về phần cứng đủ tốt hoặc thất bại đối với các nhà phát triển trò chơi phần cứng kém hơn thường chọn để yêu cầu phần cứng.

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

Chắc chắn rồi. Việc sử dụng các luồng thời gian thực sẽ là một ví dụ điển hình cho tình huống này, không chỉ có thể, mà là cách mong muốn (và thường là cách duy nhất đúng) để hoàn thành công việc. Tuy nhiên, các luồng thời gian thực thường được giới hạn trong nhân hệ điều hành, thường là cho các trình điều khiển cần có khả năng đảm bảo rằng một sự kiện phần cứng nào đó được xử lý trong một khoảng thời gian xác định. Bạn không nên có các luồng thời gian thực trong các ứng dụng người dùng thông thường và tôi không chắc chắn rằng thậm chí có thể có một luồng trong ứng dụng chế độ người dùng Windows. Nói chung, các hệ điều hành làm cho nó không thể thực hiện điều này một cách chính xác từ đất của người dùng vì nó cho phép một ứng dụng nhất định chiếm quyền kiểm soát hệ thống.

Về các ứng dụng đất người dùng: Giả định của bạn rằng việc kiểm tra một số luồng nhất định để chạy là nhất thiết có hại trong ý định là không chính xác. Chẳng hạn, bạn có thể có 2 nhiệm vụ chuyên sâu, hiệu năng dài cần có cốt lõi cho chính mình. Bất kể tốc độ lõi CPU, chia sẻ lõi với các luồng khác có thể là sự suy giảm hiệu năng nghiêm trọng và không thể chấp nhận được do lỗi bộ nhớ cache cùng với các hình phạt thông thường phát sinh khi chuyển đổi luồng (khá đáng kể.) Trong trường hợp này, nó sẽ hoàn toàn hợp lý, đặc biệt đối với một trò chơi, để đặt mỗi luồng này chỉ có ái lực trên một lõi cụ thể cho từng luồng và sau đó đặt tất cả các luồng khác của bạn không có ái lực trên 2 lõi đó. Tuy nhiên, để làm điều này, bạn '

Bất kỳ mã nào sử dụng spinlocks với bất kỳ sự tranh chấp khóa đáng chú ý nào cũng sẽ hoạt động khủng khiếp (đến một mức độ - đối với một ứng dụng như trò chơi - bạn có thể nói "không hoạt động" ) nếu số lượng luồng vượt quá số lượng lõi.

Ví dụ, hãy tưởng tượng một luồng sản xuất gửi các tác vụ đến một hàng đợi phục vụ 4 luồng tiêu dùng. Chỉ có hai lõi:

Nhà sản xuất cố gắng để có được spinlock, nhưng nó được giữ bởi một người tiêu dùng chạy trên lõi khác. Hai lõi đang chạy khóa trong khi nhà sản xuất đang quay, chờ khóa được phát hành. Điều này đã là xấu, nhưng không tệ như nó sẽ nhận được.
Thật không may, luồng tiêu dùng ở cuối lượng tử thời gian của nó, vì vậy nó bị cấm và một luồng tiêu dùng khác được lên lịch. Nó cố gắng giữ khóa, nhưng dĩ nhiên là khóa được lấy, vì vậy bây giờ hai lõi đang quay và chờ đợi điều gì đó không thể xảy ra.
Chuỗi sản xuất đến hết lát cắt thời gian của nó và được ưu tiên, một người tiêu dùng khác thức dậy. Một lần nữa, hai người tiêu dùng đang chờ khóa được phát hành và điều đó sẽ không xảy ra trước khi hai lượng tử thời gian nữa trôi qua.
[...] Cuối cùng, người tiêu dùng đang giữ spinlock đã phát hành khóa. Nó ngay lập tức được thực hiện bởi bất cứ ai đang quay trên lõi khác. Có 75% cơ hội (3 đến 1) rằng đó là một chủ đề tiêu dùng khác. Nói cách khác, 75% khả năng nhà sản xuất vẫn đang bị đình trệ. Tất nhiên điều này có nghĩa là người tiêu dùng cũng bị đình trệ. Không có nhà sản xuất làm nhiệm vụ, họ không có gì để làm.

Lưu ý rằng điều này hoạt động trên nguyên tắc với bất kỳ loại khóa nào, không chỉ là spinlocks - mà hiệu ứng tàn phá nổi bật hơn nhiều với spinlocks vì CPU tiếp tục ghi chu kỳ trong khi nó không đạt được gì.

Bây giờ hãy tưởng tượng rằng ngoài các lập trình viên ở trên, một số lập trình viên đã có ý tưởng tuyệt vời để sử dụng một luồng chuyên dụng với mối quan hệ được đặt thành lõi đầu tiên, vì vậy RDTSC sẽ cho kết quả đáng tin cậy trên tất cả các bộ xử lý (dù sao thì cũng không, nhưng một số người nghĩ vậy).

Nếu tôi hiểu những gì bạn đang hỏi, điều đó là có thể, nhưng đó là một điều rất, rất tồi tệ.

Ví dụ kinh điển về những gì bạn mô tả sẽ duy trì một bộ đếm được tăng lên bởi nhiều luồng. Điều này đòi hỏi hầu như không có gì trong sức mạnh tính toán nhưng đòi hỏi sự phối hợp cẩn thận giữa các luồng. Miễn là chỉ có một luồng tại một thời điểm tăng (mà thực sự là một lần đọc tiếp theo là một bổ sung theo sau là ghi), giá trị của nó sẽ luôn luôn chính xác. Điều này là do một luồng sẽ luôn đọc giá trị "trước" chính xác, thêm một luồng và viết giá trị "tiếp theo" chính xác. Nhận hai luồng vào hành động cùng một lúc và cả hai sẽ đọc cùng một giá trị "trước đó", nhận cùng một kết quả từ mức tăng và viết cùng một giá trị "tiếp theo". Bộ đếm thực sự sẽ được tăng lên chỉ một lần mặc dù hai luồng nghĩ rằng mỗi luồng đã làm điều đó.

Sự phụ thuộc giữa thời gian và tính chính xác là điều mà khoa học máy tính gọi là điều kiện chủng tộc .

Điều kiện cuộc đua thường được tránh bằng cách sử dụng các cơ chế đồng bộ hóa để đảm bảo các luồng muốn hoạt động trên một phần dữ liệu được chia sẻ phải được xếp hàng để truy cập. Bộ đếm được mô tả ở trên có thể sử dụng khóa đọc ghi cho việc này.

Không có quyền truy cập vào thiết kế nội bộ của Dragon Age: Inquisition , tất cả mọi người có thể làm là suy đoán về lý do tại sao nó hành xử theo cách của nó. Nhưng tôi sẽ đi dựa trên một số điều tôi đã thấy được thực hiện theo kinh nghiệm của riêng mình:

Có thể là chương trình dựa trên bốn luồng đã được điều chỉnh để mọi thứ hoạt động khi các luồng chạy hầu như không bị gián đoạn trên các lõi vật lý của chính chúng. Việc "điều chỉnh" có thể đến dưới dạng sắp xếp lại mã hoặc chèn giấc ngủ vào các vị trí chiến lược để giảm thiểu các lỗi do tình trạng chủng tộc gây ra trong quá trình phát triển. Một lần nữa, đây chỉ là phỏng đoán, nhưng tôi đã thấy các điều kiện cuộc đua "được giải quyết" theo cách đó nhiều lần hơn tôi quan tâm.

Chạy một chương trình như vậy trên bất kỳ thứ gì có khả năng thấp hơn môi trường mà nó được điều chỉnh sẽ đưa ra các thay đổi về thời gian là kết quả của mã không chạy nhanh hoặc nhiều khả năng là chuyển đổi ngữ cảnh. Các chuyển đổi bối cảnh xảy ra trong vật lý (nghĩa là các lõi vật lý của CPU đang chuyển đổi giữa công việc mà các lõi logic của nó đang giữ) và logic (nghĩa là HĐH trên CPU đang phân công công việc cho các lõi), nhưng hoặc là một sự khác biệt đáng kể so với những gì sẽ là thời gian thực hiện "dự kiến". Điều đó có thể mang lại hành vi xấu.

Nếu Dragon Age: Inquisition không thực hiện bước đơn giản để đảm bảo có đủ lõi vật lý có sẵn trước khi tiếp tục, đó là lỗi của EA. Có lẽ họ dành một số tiền nhỏ để bảo vệ các cuộc gọi hỗ trợ và email từ những người đã cố gắng chạy trò chơi trên quá ít phần cứng.

Windows có chức năng tích hợp sẵn cho việc này: chức năng GetLogicalProcessorIn information nằm trong API Windows . Bạn có thể gọi nó từ chương trình của bạn để lấy thông tin về lõi, lõi ảo và siêu phân luồng.

Vì vậy, câu trả lời cho câu hỏi của bạn sẽ là: Có.