Các chương trình tuyên bố rằng chúng không thân thiện với nhiều người khác

Thỉnh thoảng bạn thấy cụm từ này hoặc tương tự bị đá, nói chung đề cập đến một chương trình tuyên bố rằng chúng không được thiết kế để tận dụng tối đa lợi thế của bộ xử lý đa lõi. Điều này là phổ biến đặc biệt với lập trình trò chơi video. (tất nhiên rất nhiều chương trình không có sự tương tranh và không cần nó, chẳng hạn như các tập lệnh cơ bản, v.v.).

Làm sao có thể? Rất nhiều chương trình (đặc biệt là các trò chơi) vốn đã sử dụng đồng thời và do HĐH chịu trách nhiệm lập lịch tác vụ trên CPU, vậy các chương trình này vốn không tận dụng được nhiều lõi có sẵn? Điều này có nghĩa là gì trong "bối cảnh" tận dụng nhiều lõi "? Có phải các nhà phát triển này thực sự cấm lập kế hoạch nhiệm vụ hệ điều hành và buộc mối quan hệ hoặc lập kế hoạch riêng của họ? (Âm thanh như một vấn đề ổn định lớn).

Tôi là một lập trình viên Java, vì vậy có lẽ tôi đã không phải đối phó với điều này do sự trừu tượng hoặc không có gì.

Đồng thời tốt đòi hỏi nhiều hơn là ném một vài luồng trong một ứng dụng và hy vọng điều tốt nhất. Có một phạm vi trong cách đồng thời một chương trình có thể đi từ song song lúng túng sang tuần tự thuần túy. Bất kỳ chương trình cụ thể nào cũng có thể sử dụng luật của Amdahl để diễn tả mức độ có thể mở rộng của một vấn đề hoặc thuật toán. Một vài bằng cấp cho một ứng dụng song song đáng xấu hổ sẽ là:

• Không có trạng thái chia sẻ, mọi chức năng chỉ phụ thuộc vào các tham số được truyền vào
• Không có quyền truy cập vào các thiết bị vật lý (card đồ họa, ổ cứng, v.v.)

Có những bằng cấp khác, nhưng chỉ với hai điều này, chúng ta có thể hiểu tại sao các trò chơi nói riêng không dễ như bạn nghĩ để tận dụng nhiều lõi. Đối với một, mô hình của thế giới sẽ được kết xuất phải được chia sẻ dưới dạng các chức năng khác nhau tính toán vật lý, chuyển động, áp dụng trí tuệ nhân tạo, vv Thứ hai, mỗi khung hình của mô hình trò chơi này phải được hiển thị trên màn hình bằng thẻ đồ họa.

Công bằng mà nói, nhiều nhà sản xuất trò chơi sử dụng các công cụ trò chơi được sản xuất bởi các bên thứ ba. Phải mất một thời gian, nhưng các công cụ trò chơi của bên thứ ba này hiện đang song song hơn nhiều so với trước đây.

Có những thách thức kiến ​​trúc lớn hơn trong việc xử lý đồng thời hiệu quả

Đồng thời có thể có nhiều hình thức, từ chạy các tác vụ trong nền đến hỗ trợ kiến ​​trúc đầy đủ cho đồng thời. Một số ngôn ngữ cung cấp cho bạn các tính năng tương tranh rất mạnh như ERLANG , nhưng nó đòi hỏi bạn phải suy nghĩ rất khác về cách bạn xây dựng ứng dụng của mình.

Không phải mọi chương trình thực sự cần sự phức tạp của hỗ trợ đa lõi đầy đủ. Một ví dụ như vậy là phần mềm thuế, hoặc bất kỳ ứng dụng định hướng nào. Khi hầu hết thời gian của bạn dành cho việc chờ đợi người dùng làm việc gì đó, sự phức tạp của các ứng dụng đa luồng chỉ là không hữu ích.

Một số ứng dụng cho vay một giải pháp song song đáng xấu hổ hơn, chẳng hạn như các ứng dụng web. Trong trường hợp này, nền tảng bắt đầu song song lúng túng và tùy thuộc vào bạn không phải áp đặt tranh chấp luồng.

Điểm mấu chốt:

Không phải tất cả các ứng dụng đều thực sự bị tổn thương do không tận dụng được nhiều luồng (và do đó, lõi). Đối với những người bị tổn thương bởi điều đó, đôi khi các tính toán không thân thiện với xử lý song song hoặc chi phí để phối hợp nó sẽ làm cho ứng dụng trở nên dễ vỡ hơn. Thật không may, xử lý song song vẫn không dễ dàng như nó phải làm tốt.

Rất nhiều chương trình (đặc biệt là game) vốn đã sử dụng đồng thời,

Không, thực sự đó là điều ngược lại. Hầu hết các ứng dụng được viết theo một tư duy luồng đơn và nhà phát triển không bao giờ thực hiện các thay đổi cần thiết để hỗ trợ đồng thời.

Trong C, C ++ và C #, bạn cần thông báo rõ ràng cho ứng dụng để bắt đầu các luồng và / hoặc tiến trình mới.

Tôi nghĩ rằng bạn đang tập trung quá nhiều vào việc lên lịch cho các luồng và không đủ để xử lý dữ liệu trong các luồng tiềm năng. Chia sẻ dữ liệu qua các luồng và / hoặc quy trình yêu cầu một số hình thức đồng bộ hóa. Nếu bạn thay đổi một ứng dụng để sử dụng nhiều luồng nhưng không có sự đồng bộ hóa đó thì có khả năng bạn sẽ gặp rất nhiều khó khăn để theo dõi các lỗi trong mã.

Đối với các ứng dụng đa luồng mà tôi đã làm việc, tôi thường không bao giờ lo lắng về việc gửi và chỉ về đồng bộ hóa dữ liệu. Lần duy nhất tôi phải lo lắng về công văn là khi tôi đang theo đuổi các điều kiện cuộc đua do đồng bộ hóa dữ liệu không chính xác.

Nói chung, khi một ứng dụng nói rằng nó không thể sử dụng nhiều lõi thì điều đó có nghĩa là chúng không có đồng bộ hóa để bảo vệ thao tác dữ liệu.

Đây không phải là quá nhiều về nhiều lõi vì nó là về nhiều luồng. HĐH có thể lên lịch cho một luồng để chạy trên bất kỳ lõi nào mà nó thích và việc lập lịch trình này là minh bạch cho chương trình đang được lên lịch. Tuy nhiên, nhiều chương trình không được viết bằng nhiều luồng, vì vậy chúng chỉ có thể chạy trên một lõi cùng một lúc.

Tại sao tôi lại viết một chương trình đơn luồng? Chúng dễ viết hơn và dễ gỡ lỗi hơn: một điều xảy ra sau một điều khác (thay vì nhiều điều xảy ra cùng một lúc và có thể xảy ra theo cách khác). Hoặc chương trình của bạn có thể không nhắm mục tiêu các máy đa lõi (như trường hợp của các trò chơi cũ). Trong một số trường hợp, một chương trình đa luồng thậm chí có thể chạy chậm hơn phiên bản một luồng nếu chi phí từ chuyển mạch ngữ cảnh và giao tiếp giữa các luồng vượt xa tốc độ đạt được khi thực hiện song song (một số phần của chương trình có thể không song song).

Đây không phải là một câu trả lời đầy đủ. Đó là một câu chuyện cảnh báo.

Một ngày nọ, tôi nghĩ rằng tôi sẽ cho các sinh viên trong khóa học lập trình đồng thời của mình một bản tóm tắt song song. Quicksort nên song song tốt, tôi nghĩ. Tôi đã sử dụng hai chủ đề. Chạy nó trên máy tính lõi đơn của tôi. Kết quả là:

• 14 giây cho một phiên bản đơn luồng.
• 15 giây cho phiên bản 2 luồng.

Đây là về những gì tôi mong đợi.

Sau đó, tôi đã thử nó trên một máy lõi kép mới hơn.

• 11 giây cho phiên bản đơn luồng.
• 20 giây cho phiên bản 2 luồng.

Hai chủ đề chia sẻ một hàng các nhiệm vụ còn lại. Có vẻ như các trường của đối tượng hàng đợi được xáo trộn qua lại giữa bộ đệm của lõi này và bộ đệm khác.