Helpex - Trao đổi & giúp đỡ Đăng nhập

Mô hình CPU mới sẽ dựa trên bầy đàn?

Cách đây rất lâu (ở một thiên hà xa xôi?) Chúng ta đã tạo ra đa luồng và gặt hái được những lợi ích của phép song song lôgic. Sau đó, với nhiều lõi, chúng tôi đã thêm các lợi ích từ tính song song vật lý. Tuy nhiên, đối với bất kỳ ai được viết các chương trình đa luồng và đa lõi, những lợi ích mong đợi thường lớn hơn nhiều so với thực tế. Nó chỉ ra rằng ở mặt trước có một chi phí để chia nhỏ một chương trình thành các phần có thể chạy độc lập (trên các luồng hoặc lõi) và ở mặt sau, có một chi phí để tập hợp lại và đồng bộ hóa lại các giải pháp từng phần thành một tổng thể tập hợp. Nếu việc phân vùng cần thiết và được phối hợp lại là một đoạn mã thủ tục đơn lẻ thì quá trình đó sẽ là yếu tố giới hạn xác định tốc độ tối đa có thể. Nếu việc quản lý quản trị dữ liệu đầu vào và đầu ra là 20% chu kỳ được sử dụng thì bất kể bạn thực hiện các thao tác trên dữ liệu được phân vùng nhanh đến mức nào, quá trình hoàn chỉnh không bao giờ có thể nhanh hơn năm lần so với phiên bản một luồng. Mã quản trị chi phối độ trễ của chương trình tổng thể.

Tất nhiên, bất cứ khi nào chúng ta bắt đầu song song một chương trình, điều đầu tiên chúng ta xem xét là chi phí quản trị này. Hiệu quả của thành phần quản trị này quan trọng hơn nhiều so với hiệu quả của các thành phần song song bởi vì nếu bạn chỉ bổ sung thêm một vài lõi thì chương trình tổng thể sẽ có độ trễ ít hơn. Không phải là giải pháp thanh lịch nhất, nhưng nó là một cách tiếp cận kỹ thuật ban đầu thực tế.

Một điều thú vị về không gian bài toán mà chúng tôi cố gắng tấn công bằng lập trình song song là nó thường có dạng đồ thị giống như trong cấu trúc của nó. Hãy tưởng tượng một cái gì đó giống như một mô phỏng thời tiết trong đó khu vực được chia nhỏ thành các ô được chia nhỏ một cách đệ quy thành các ô nhỏ hơn bao giờ hết. Bầu khí quyển là một thể tích và cách tự nhiên để phân chia và chinh phục là sử dụng đồ thị một phần  tám : mỗi hàng đợi của thể tích được chia thành tám khối nhỏ hơn. Cấu trúc cây xác định cách khối lượng được tháo rời và tập hợp lại và độ sâu của mỗi nút trong cây xác định thứ tự "trong thời gian" phải được tuân thủ để tính toán và lắp ráp lại. Về cơ bản, việc đóng khung vấn đề trong một biểu đồ như ngữ cảnh sẽ cho phép chia vấn đề thành nhiều phần nhỏ liên kết một thứ tự ưu tiên dựa trên thời điểm các phần đó có thể được xử lý. Cho đến nay, không có gì kỳ diệu trong kiểu tiếp cận này, nó vẫn là một sự phân rã theo thứ bậc tiêu chuẩn với các nút thắt cổ chai ở tất cả các cách.

Trước khi tôi bắt đầu với mô hình mới, chúng ta nên xem lại CPU ngày nay đã trở thành như thế nào. Trong những ngày đầu của máy tính đa năng, CPU hầu như chỉ lấy dữ liệu từ bộ nhớ và thực hiện một số thao tác đơn giản và ghi kết quả vào bộ nhớ. Ngày nay chip CPU có nhiều quy trình phụ trợ mà chúng ta có xu hướng quên đi. Ví dụ: bộ nhớ được quản lý tích cực khi nó được di chuyển vào bộ nhớ đệm L1 và L2, CPU của chính nótìm ra cách giữ dữ liệu mà nó sử dụng ở những vị trí có tốc độ hiệu quả nhất. Một ví dụ khác là nếu CPU có một số chu kỳ dự phòng thì nhiều nhánh logic trong mã được xử lý cho đến khi rõ ràng nhánh nào sẽ được sử dụng, sau đó các nhánh không cần thiết chỉ bị loại bỏ: thời gian được sử dụng trên nhánh không được sử dụng không xuất hiện trong tổng thể độ trễ mã. Các phần cứng chuyên biệt này của CPU hiện đại về cơ bản là các sự kiện song song nhỏ giúp giảm độ trễ của quy trình và điều mà hầu hết chúng ta thậm chí không bao giờ nghĩ đến (và nhiều người thậm chí còn không biết đến).

Nhưng trở lại đồ thị của chúng tôi giống như sự phân hủy của vấn đề. Điều gì sẽ xảy ra nếu một tính năng tăng tốc phần cứng khác được thêm vào CPU của chúng tôi? Điều gì sẽ xảy ra nếu mỗi nút của sự phân rã đồ họa của chúng ta không chỉ chứa dữ liệu cục bộ có liên quan mà còn cả "mức độ ưu tiên" của nó trong sơ đồ sự vật. Sau đó, sâu bên trong CPU một số mạch tự trị có thể quyết định hoàn toàn ngày của riêng mìnhkhi nào hoạt động trên dữ liệu và khi nào và làm thế nào để liên kết lại dữ liệu đó với nguồn gốc của nó? Trong trường hợp đó, có thể phát hành một "bầy" các quy trình nhẹ rất nhỏ mà mỗi quy trình hoạt động trong miền nhiệm vụ phụ nhỏ, riêng lẻ của chúng. Mỗi thành viên nhóm có thể tìm ra cái gì, ở đâu và khi nào cho những đóng góp cụ thể của mình đối với giải pháp. Cách tiếp cận vấn đề này sẽ dẫn đến xử lý tổng thể nhanh hơn và song song hiệu quả hơn. Tuy nhiên, lợi ích lớn nhất của cách tiếp cận này là nó sẽ giảm đáng kể thời gian và dòng mã cần thiết để viết các chương trình song song hiệu quả. Cũng giống như bạn sẽ không bao giờ mơ đến việc viết phần mềm quản lý tiền mặt L1-L2 của riêng mình, chúng tôi có thể hy vọng rằng một ngày nào đó bạn sẽ không phải bận tâm về việc phân hủy và tập hợp lại dữ liệu của mình để bạn có thể song song hóa nó.

Kỹ thuật này cũng có thể được áp dụng cho các vấn đề nhạy cảm với cấu trúc của đồ thị nhưng lại nhạy cảm với các trọng số liên quan đến các nút (ví dụ như lưới thần kinh). Điều này sẽ cho phép các CPU để quyết định ngày của riêng mình để làm việc trên một phần quan trọng nhất của vấn đề (trọng lượng nặng nhất) đầu tiên. Giống như việc tải liên tục hình ảnh trên một trang web, bạn có thể tưởng tượng một hệ thống như thế này cung cấp cho bạn một giải pháp nhanh chóng "khá tốt" và nếu bạn cho thêm một chút thời gian thì giải pháp sẽ tốt hơn.

Đây không phải là suy nghĩ viễn vông hay khoa học viễn tưởng. Bạn nên theo liên kết này đến một dự án thực tế đang được tiến hành tại MIT . Bài báo của MIT có rất nhiều chi tiết thú vị và tương đối dễ đọc. Trong số những điều bạn sẽ học được là các thí nghiệm cho thấy tốc độ từ 3X đến 18X (trong một trường hợp là 75X!) So với các chương trình được lập trình khoa học có kinh nghiệm song song hóa bằng tay. Và bởi vì kiến ​​trúc CPU mới này quản lý rất nhiều việc tháo gỡ, lắp ráp lại, đồng bộ hóa phức tạp nên các chương trình bầy đàn mới này yêu cầu khoảng 1/10 mã .

13 hữu ích 0 bình luận 3.6k xem chia sẻ

Có thể bạn quan tâm

loading