Tại sao quản lý bộ nhớ tùy chỉnh cần thiết cho tài sản?

Khá nhiều tài nguyên liên quan đến lập trình trò chơi, đặc biệt là các trò chơi thế giới mở 3D, nói về cách bạn phải liên tục dỡ và tải lại tài sản đến và từ đĩa, bộ nhớ hệ thống và bộ nhớ video. Tôi có thể hiểu điều này trên bảng điều khiển, vì chúng có các sơ đồ quản lý bộ nhớ rất đơn giản không thể đối phó với bất kỳ lỗi tràn tiềm năng nào.

Tuy nhiên, trên PC, tình hình rất khác. Có bộ nhớ ảo do HĐH cung cấp cho bộ nhớ hệ thống và trình điều khiển đồ họa xử lý hoán đổi qua lại từ CPU sang GPU. Vậy tại sao nó không đủ để tải mọi thứ cùng một lúc và chỉ phải xử lý việc tìm nạp trước và có thể đảm bảo rằng không có chặn trong khi một tài sản bắt buộc bị hoán đổi?

Điều này không có nghĩa là mọi thứ đang được phân bổ một cách ngây thơ bằng cách sử dụng một cái gì đó như malloc. Mọi thứ sẽ được giữ liên tục và kết hợp bộ nhớ cache. Có thể dễ dàng hơn để làm cho bộ nhớ của bạn truy cập hiệu quả nếu bạn không phải lo lắng về việc phân trang vào và ra bằng tay ...

CẬP NHẬT:

Sau khi đọc một chút về chuyển bộ đệm không đồng bộ , tôi có ý tưởng rằng cách trình điều khiển đồ họa có thể tự động trang bộ nhớ vào và ra là tối ưu. Điều này cũng đúng với tài nguyên CPU; tức là, tốt hơn là luôn luôn quản lý thủ công khi một tài nguyên nhất định được tải và không tải ngay cả khi có bộ nhớ ảo?

Các trò chơi thế giới mở hiện đại đơn giản là không phù hợp với bộ nhớ. Hãy nhớ rằng hầu hết các trò chơi vẫn là 32 bit do số lượng game thủ có HĐH 32 bit và quá trình 32 bit tốt nhất chỉ có thể có 4GB bộ nhớ địa chỉ tại một thời điểm (không phụ thuộc vào bộ nhớ ảo) nhưng thực tế là giới hạn ở 2-3 GB. Tách trong phân mảnh và số lượng thực tế của các đối tượng có thể sử dụng bạn có thể có trong bộ nhớ tại một thời điểm nhỏ hơn một chút so với tổng dữ liệu bạn cần cho một môi trường lớn. Ngay cả trên HĐH 64 bit, bạn thường cần nhắm mục tiêu các máy có thông số kỹ thuật thấp chỉ có 4GB bộ nhớ để đảm bảo khả năng tương thích tối đa của người dùng cuối. Chúng ta đừng quên các thiết bị di động, phần cứng "không được cung cấp năng lượng" như WiiU, v.v. Các nhà phát triển phải nhắm mục tiêu nhiều hơn các giàn máy tính chơi game ưa thích lớn.

Bộ nhớ ảo không phải là một giải pháp, trước tiên vì nó không phủ nhận giới hạn không gian địa chỉ và cũng vì nó không tối ưu. HĐH có thể loại bỏ mọi thứ vào thời điểm không thuận lợi hoặc theo cách không phù hợp. Đây là một vấn đề được xử lý bởi các hệ điều hành khi ngủ đông lần đầu tiên xuất hiện; Phân trang các tiến trình vào đĩa và sau đó phân trang chúng trở lại chậm hơn đáng kể trong một số trường hợp so với việc ứng dụng truyền tài nguyên trở lại một cách rõ ràng. Bạn vẫn có thể thấy các vấn đề ngày hôm nay khi một hệ thống hết bộ nhớ, các trang được xử lý đĩa và hệ thống trở nên không phản hồi trở thành những thứ quan trọng cần thiết để chạy WM / explorer.exe của bạn được phân trang. Bộ nhớ ảo là một giải pháp được đặt ra cho một vấn đề từ nhiều thập kỷ trước, nơi các hệ thống có rất ít RAM và khoảng cách giữa bộ nhớ và tốc độ ổ đĩa nhỏ hơn nhiều. Thậm chí ngày nay' SSD nhanh nhất là một phần rất nhỏ của tốc độ RAM rẻ / chậm và cố gắng giả vờ rằng bạn có thể sử dụng đĩa của mình làm RAM ảo không còn là ý tưởng tốt nhất nữa. Đây là thời đại mà một số người làm ngược lại và tải các hệ thống tệp vào đĩa RAM; các ràng buộc dẫn đến việc tạo ra bộ nhớ ảo không còn đúng nữa.

Ngay cả ngoài vấn đề về đĩa, quản lý tài nguyên tùy chỉnh vẫn là một phần lớn trong phát triển trò chơi. Từ các móc gỡ lỗi cho đến các mối quan tâm phân mảnh cho đến các luồng tài nguyên phức tạp, chỉ cần giả vờ toàn bộ thế giới là một hộp bit vô cùng lớn là không thực tế.

Đối với trò chơi 32 bit, vì hầu hết các trò chơi là vì nhiều lý do, ngay cả một trò chơi đi kèm với một đĩa DVD một mặt (4.3GB) đã có nhiều nội dung hơn có thể được gắn vào không gian địa chỉ 32 bit. Và đó là giả sử nội dung không được nén trên đĩa và hoàn toàn tối ưu, tải mọi thứ cùng một lúc vào phương pháp tiếp cận không gian địa chỉ liền kề. Nhiều trò chơi hiện có nhiều đĩa DVD, dễ dàng vượt qua 10GB nội dung. Theo kinh nghiệm của tôi trên PC, một khi không gian địa chỉ của bạn đạt tới mức phân bổ 2GB sẽ bắt đầu thất bại và điều đó trở thành giới hạn cứng, bất kể người dùng có bao nhiêu bộ nhớ vật lý.

Nếu bạn thực hiện bước nhảy lên 64 bit, giả sử động cơ của bạn hỗ trợ nó, giới hạn cứng đó sẽ biến mất, chỉ được thay thế bằng giới hạn mềm hiệu quả - ngay khi hoán đổi bộ nhớ ảo bắt đầu xảy ra, hiệu suất của trò chơi sẽ giảm không thể chấp nhận được Nếu quá trình chính phải đợi bộ nhớ được phân trang lại, tốc độ khung hình sẽ bị chậm và trục trặc. Bộ nhớ ảo có thể làm cho nó trong suốt, nhưng nó không làm cho nó hoạt động. Về mặt vật lý, cần có thời gian để lấy lại bộ nhớ đó từ đĩa và trong khi bạn chờ đợi, trò chơi của bạn đã bị đình trệ. Mặc dù có thể xử lý xung quanh (với việc tìm nạp trước các trang bộ nhớ mà bạn biết rằng bạn sẽ cần sớm), đó là một quá trình khó khăn và không đáng tin cậy, và vẫn sẽ có ý nghĩa về hiệu suất.

Các thuật toán của HĐH để quyết định những trang nào được trao đổi ra đĩa không có kiến ​​thức về trò chơi của bạn và những gì nó có thể cần tiếp theo. Hơn nữa, HĐH vẫn phải hỗ trợ các ứng dụng khác chạy đồng thời với trò chơi của bạn, cũng như chính HĐH. Phải ngừng hoạt động trong khi các trang được trả về từ đĩa là một thành tích lớn, và không quan trọng là trò chơi của bạn, ứng dụng khác hay HĐH phát sinh nó, hiệu suất của trò chơi sẽ bị ảnh hưởng lớn.

Vì vậy, bất kể giới hạn bộ nhớ là mềm hay cứng, bộ nhớ vẫn bị giới hạn. Nhưng ngay cả khi bạn chỉ có thể tải mọi thứ cùng một lúc mà không đạt giới hạn hiệu suất, vẫn có những lý do khiến bạn không muốn:

1. Trò chơi của bạn mất nhiều thời gian hơn để tải và đến trạng thái tương tác hơn mức cần thiết, bởi vì nó chỉ đơn giản là tải mọi thứ khi bắt đầu và giữ cho nó tồn tại. Bạn có thể tải khoảng 150MB / giây từ đĩa cứng và thậm chí ổ đĩa DVD nhanh nhất (24x) tải với tốc độ 33MB / giây. Điều đó có nghĩa là ví dụ nội dung có giá trị DVD 4,3 GB sẽ mất ít nhất 30 giây để tải từ ổ cứng và hơn 133 giây để tải từ DVD. Đó là thời gian tải dài không thể chấp nhận.

2. Trò chơi của bạn chiếm nhiều bộ nhớ hơn là hợp lý. Nếu chỉ có 10% nội dung hiển thị tại bất kỳ thời điểm nào, việc giữ cư dân còn lại chỉ đơn giản là lãng phí và ngăn người dùng sử dụng bộ nhớ đó cho mục đích khác. Người dùng thường không tha thứ cho các trò chơi đòi hỏi một lượng bộ nhớ lớn không tương xứng để chạy đúng.

Truyền tài sản từ đĩa một cách linh hoạt, cho dù ở chế độ nền hoặc đồng bộ trong khi tải màn hình, cho phép bạn sử dụng bộ nhớ hiệu quả hơn rất nhiều, với nỗ lực không đáng kể và chỉ là nhược điểm nhỏ cho người dùng. Nhưng đó là một tối ưu hóa, và giống như bất kỳ tối ưu hóa nào khác, nó sẽ giảm lợi nhuận khi bạn cố gắng áp dụng nó. Tại một số điểm, sự gia tăng dấu chân bộ nhớ để giữ một cái gì đó cư trú là lớn hơn những lợi thế có được từ việc có nó ở đó mà không cần phải tải. Nhưng cho đến khi đạt được điểm đó, tốt hơn là chỉ tải những gì bạn cần, khi bạn cần.

Chỉ cần nói rất chung chung và đơn giản, và không xem xét các chi tiết về việc triển khai bộ nhớ ảo, nhà phát triển luôn có kiến ​​thức về tầm nhìn xa mà việc triển khai VM thiếu.

Nhà phát triển luôn có thể nói: "Tôi không cần tải tệp âm thanh này ngay bây giờ. Âm nhạc bên trong chỉ được sử dụng cho trò chơi trên màn hình." Và ngay sau khi trò chơi qua màn hình, nhà phát triển có thể nói: "Tôi không cần clip âm thanh này nữa trong bộ nhớ vật lý. Nó chỉ được sử dụng cho trò chơi này trên màn hình."

HĐH không có tầm nhìn xa như vậy. Có thể có thể nhận ra, nhiều lỗi trang sau đó, rằng một số clip âm thanh không còn cần thiết trong bộ nhớ vật lý vì nó không được truy cập trong một thời gian tốt. Nhưng biến tầm nhìn xa thành nhận thức muộn sẽ chuyển thành rất nhiều lỗi trang và rất nhiều lỗi trang chuyển thành trục trặc về tốc độ khung hình trong một phần mềm quan trọng như thời gian như một trò chơi video. Có tầm nhìn xa của nhà phát triển thực sự có ích nếu bạn muốn tránh những trục trặc như vậy.

Và điều đó áp dụng về mặt khái niệm bất kể phần cứng và phần mềm. Giả sử phân trang trong bộ nhớ là tốn kém, thì tầm nhìn xa của nhà phát triển sẽ luôn giúp giảm chi phí đó.

Nói rộng hơn nữa, có một chu kỳ không bao giờ kết thúc giữa nhà thiết kế phần cứng, nhà thiết kế trình biên dịch, nhà thiết kế hệ điều hành / trình điều khiển và nhà phát triển ứng dụng. Các nhà phát triển phần cứng / trình biên dịch / HĐH / trình điều khiển thường cố gắng thực hiện tối ưu hóa để tăng tốc ứng dụng trung bình của bạn dựa trên các mẫu truy cập bộ nhớ thông thường của nó và đôi khi với hy vọng như "Mọi người chỉ có thể viết mã theo cách họ muốn và nó nên nhanh lên. "Nhưng nếu có bất kỳ suy nghĩ nào về kiểu đó xảy ra, nó thường thất bại đối với các trường quan trọng về hiệu năng, bởi vì sau đó các nhà phát triển quan trọng về hiệu năng bắt đầu tìm hiểu các chi tiết phức tạp của trình biên dịch, phần cứng, HĐH, trình điều khiển, v.v. và bắt đầu viết mã cụ thể được thiết kế để khai thác càng nhiều càng tốt để viết mã nhanh nhất có thể (như tìm nạp trước, tách trường nóng / lạnh, SoAs, v.v. để mã thân thiện với bộ đệm). Và đó giống như một trò chơi không bao giờ kết thúc. Những thứ này không bao giờ được coi là hộp đen trong các lĩnh vực quan trọng về hiệu suất, vì các nhà phát triển đang cạnh tranh về hiệu suất.

Cá nhân tôi ước rằng bộ nhớ ảo không tồn tại vì nó bổ sung thêm một lớp hiệu suất không thể đoán trước theo những cách có xu hướng quá cực đoan và phát sinh, quá nhiều hình phạt hiệu năng khi mọi thứ thực sự đi về phía nam đến mức không thể tin được. Thỉnh thoảng tôi gặp phải trường hợp tôi sử dụng một số ứng dụng mà tôi đã vô tình gõ thêm một hoặc hai chữ số khi say vào một số trường đầu vào, sau đó khiến nó cạn kiệt bộ nhớ vật lý nhanh chóng theo cách mà đưa HĐH đến một nơi mà tôi không thể ' Thậm chí nhấp vào nút hủy trên thanh tiến trình nữa và phải đợi 10 phút trong khi gây nhiễu Ctrl + Alt + Del để giết một quá trình và tự nguyền rủa bản thân trong khi làm đổ đồ uống của tôi để quay lại điểm mà mọi thứ có thể sử dụng được một lần nữa, và điều đó mặc dù tập tin trang được lưu trữ trên ổ SSD. Trong những trường hợp đó, tôi thích sử dụng một lỗi "hết bộ nhớ" hoặc một cái gì đó, tại thời điểm đó tôi có thể đóng một số 17 tab khiêu dâm của mình (không sao, tôi vẫn đánh dấu mục yêu thích của mình) để giải phóng bộ nhớ và sau đó ngay lập tức nối lại công việc kinh doanh của tôi