Làm thế nào để tạo hồ sơ và tổng hợp bộ nhớ cho mỗi hệ thống?


8

Tôi đã rất thú vị trong việc định hình và giữ một nhóm bộ nhớ được quản lý cho mỗi hệ thống con, vì vậy tôi có thể thống kê được bao nhiêu bộ nhớ đã được sử dụng trong một cái gì đó như âm thanh hoặc đồ họa. Tuy nhiên, điều gì sẽ là một thiết kế hoạt động để làm điều này? Tôi đã nghĩ đến việc sử dụng nhiều bộ cấp phát và chỉ sử dụng một bộ cho mỗi hệ thống con, tuy nhiên, điều đó sẽ dẫn đến các biến toàn cục cho bộ cấp phát của tôi (hoặc do đó nó có vẻ như đối với tôi). Một cách tiếp cận khác mà tôi đã thấy / được đề xuất là chỉ quá tải mới và chuyển vào một bộ cấp phát cho một tham số.

Tôi đã có một câu hỏi tương tự về stackoverflow ở đây với tiền thưởng, tuy nhiên, dường như có lẽ tôi quá mơ hồ hoặc chỉ là không có đủ người có kiến ​​thức về chủ đề này.


Xóa câu trả lời của tôi. Tôi đã quay lại và đọc các bài báo và các nhóm được sử dụng để theo dõi phân bổ trên mỗi hệ thống không phải là một phần của các bài viết đó (mặc dù chúng dựa trên nó) Nếu tôi có thể tìm lại những bài cụ thể đó một lần nữa, tôi sẽ liên kết chúng với nhau! Lấy làm tiếc!
James

1
Hãy xem bài viết trên blog này của Jesus de Santos Garcia. Trong đó, ông thảo luận về việc theo dõi bộ nhớ theo hệ thống con và sử dụng nhiều cấp phát cho các yêu cầu bộ nhớ khác nhau.

7
Đừng bị ám ảnh bởi các mô hình lý thuyết. Nếu bạn cần chức năng và dữ liệu trên toàn cầu, thì không có gì sai với toàn cầu. Hiện đã có một loạt các chức năng toàn cầu như mới / xóa / malloc / miễn phí. Chỉ cần thêm những gì bạn phải làm, để hoàn thành công việc.
Maik

Câu trả lời:


1

Đây chắc chắn là một câu hỏi nghe có vẻ mơ hồ với một số người;)

Nhưng tôi nghĩ tôi biết bạn đến từ đâu.

Bạn có một triệu lựa chọn cho cách bạn có thể chọn để thực hiện điều này. Một số trong những lựa chọn đó nên xoay quanh cả nền tảng mục tiêu và mục tiêu thiết kế tổng thể. Những cân nhắc đó sẽ phá vỡ mọi mối quan hệ, cho đến khi bạn cảm thấy đủ thoải mái với các chi phí thực hiện khác nhau đủ để phát triển thiết kế từ nền tảng và mối quan tâm thiết kế chung trước tiên. Vì vậy, cho đến lúc đó, đây là một số cách mà bạn không phải trả giá về sự phức tạp (gánh nặng quản lý) hoặc trong việc xử lý loại bỏ hoặc thay đổi nếu bạn thay đổi quyết định ...

Nếu mục tiêu là đo lường và phân bổ, với khả năng sử dụng các nhóm, thì trước tiên bạn cần nghĩ đến bộ mã có thể sống tối thiểu để bắt đầu. Để giải thích, nếu bạn là một phần của các lớp, bạn có thể tạo một lớp, để cho một đống, hoặc thay vào đó sử dụng một tập hợp các hàm có một hàm xử lý hoặc tên heap. Nó thực sự là một vấn đề ngữ nghĩa phải trung thực. Quyết định tiếp theo là mới hoặc malloc; Tôi là một phần của malloc bởi vì nhiều lần tôi đang xử lý các công trình cấp thấp và tôi biết trong hầu hết các triển khai mà gọi là malloc, và tôi không phải lo lắng về sự phức tạp của việc quá tải mới và lo lắng về điều đó trên tất cả các nền tảng . Tuy nhiên, tôi đã nhiều lần xây dựng các hệ thống hoặc các thành phần xung quanh quá tải hoặc móc mới. Và tất nhiên, vấn đề cốt lõi hoặc khác biệt, đó là 'mới' phải biết loại trước khi phân bổ, trong đó 'malloc' không quan tâm và với malloc, bạn quyết định loại sau khi phân bổ. Tất cả chi tiết đó là để cung cấp cho bạn một ý tưởng và một số bối cảnh để đưa ra quyết định thiết kế trong các loại vấn đề này :)

Vì vậy, tôi sẽ chọn lớp học và malloc, bởi vì ở đây dễ giải thích hơn, nhưng cuối cùng nó thực sự không quan trọng. Các bộ phận bên trong cuối cùng sẽ mang ít sự khác biệt về vật liệu so với phần còn lại của thiết kế tổng thể.

Vì vậy, trong giả thuyết này, tôi biết rằng (hoặc sẽ giả định rằng) tôi có thể kết thúc với 7-8 lần khởi động lớp hệ thống thực sự và dự đoán hàng trăm ngàn cuộc gọi để phân bổ và miễn phí. Vì phần lớn sự tò mò và lực đẩy thực sự của tôi trong tất cả những điều này, thực sự là về kích thước và khía cạnh hồ sơ, tôi không muốn tạo gánh nặng cho hiệu suất ứng dụng một cách khôn ngoan. Đối với người mới bắt đầu, tôi có thể quyết định để toàn bộ công khai và công khai cho đến khi tôi đóng nó xuống, khi tôi thực hiện nó trong suốt phần còn lại của ứng dụng; một cấu trúc sẽ làm điều này độc đáo. 'S_' là để hiển thị các vars nào được dự định rõ ràng để thống kê.

struct Mem
{
  int s_allocs;
  int s_frees;
  int s_peak;
  int s_current;
  void* heap; // if you wanted to go into having real actual separate heaps, else ignore
  void* alloc(int size);
  void free(void* p);

  Mem() {memset(this,0,szieof(Mem));}  // want this to be inlined with the call site constructor (a design decision example)
}

class MySubSystem
{
   Mem mem;
   ....  you get the idea
}

Điều này là vô cùngnhẹ trên nhiều mặt trận, và có thể là một nơi tốt để bắt đầu xác định bất cứ nơi nào bạn thực sự muốn đi với điều này. Và bạn ngay lập tức có một vấn đề, làm thế nào để bạn biết kích thước của mặt hàng được giải phóng. (Đây sẽ là một vấn đề cần giải quyết cho gần như mọi cách tiếp cận.) Vì đây là một diễn đàn trò chơi, bạn có thể xem xét pha tạp một vài byte đầu tiên với kích thước, hoặc nếu không bạn phải bọc hoặc ghi nhớ theo một cách khác. Hầu hết sự nhạy cảm của nhà phát triển trò chơi không nên quá nhiều so với doping, và đây là ví dụ đơn giản nhất, vì tôi đã tạo ra một bức tường văn bản. Về cơ bản là như thế này: bạn không muốn nếu có thể được giúp phá hủy sự liên kết vốn có, bạn muốn biết, vì gần như miễn phí, nếu kích thước được kết hợp. Vì vậy, một cái gì đó đơn giản như "s_allocs ++; s_total + = size; uint64 * p = (uint64 *) malloc / calloc (size + = 8); * p = 0xDEADDAED00000000 | kích thước; return p + 1; "trong đó phân bổ sẽ nhỏ hơn 4GB và uint64 là bất cứ điều gì trình biên dịch nghĩ rằng int 64 bit không dấu và là nơi bạn có thể kiểm tra giá trị độ sạch miễn phí.

Đây là tất cả một cách để giúp bạn có mức tối thiểu trần với chi phí tối thiểu trần thỏa mãn các yêu cầu. Nó khôngphân bổ địa chỉ các lớp có chức năng ảo nếu chúng nằm trong phạm vi để lược tả hoặc quản lý, vì bạn không thể lường trước kích thước của môi trường c ++ mà bạn đang sử dụng cho những thứ đó mà không bị quá tải hoặc móc nối mới, hoặc nếu bạn đang dựa vào hàm tạo trong một trong các những cách kỳ lạ không thể được xử lý bởi một số chức năng 'init' khác. Mặt khác, một lớp là một lớp phân bổ tùy ý và tất cả đều giống nhau, khi bạn bỏ. Nếu bạn là một phần của mới và cần ngữ nghĩa của bảng ảo hoặc hàm tạo, thì bạn phải nối mới, nhưng đó là một động vật hoàn toàn mới, mà bạn cần thực sự nghiên cứu để đảm bảo rằng bạn đang làm những gì cần mới và sẽ phải báo hiệu mã của bạn đang xử lý mới, cái xô này được áp dụng cho. Nhưng nếu không thì khái niệm trên là như nhau.

Quan trọng hơn, điều này sẽ khiến bộ não của bạn hoạt động, và hy vọng dọc theo dòng của những gì bạn cần và khả năng chịu đựng của bạn là gì, bây giờ bạn đã nhìn thấy đằng sau bức màn một chút nữa. Không có thuật sĩ :)


Nếu bạn đang sử dụng các hàm mẫu để phân bổ và giải phóng thì đó không phải là vấn đề để xác định kích thước cần được giải phóng (và được phân bổ).
API-Beast

1
Vấn đề là chỉ ra vấn đề tiềm ẩn để giúp cung cấp một cơ sở để chọn bất kỳ sự trừu tượng hóa nào, không đưa ra một sự trừu tượng cụ thể. Mọi thứ đều có sự đánh đổi của nó. Kiến thức về kích thước là không cần thiết để thực hiện việc giải phóng, nhưng để thống kê.
Không giới hạn

1

Bạn không cần phải thực hiện bất cứ điều gì trong trò chơi của mình cho dữ liệu này. Các công cụ như Massif Valgrind có thể trích xuất tất cả dữ liệu cần thiết từ Biểu tượng gỡ lỗi. Bạn có thể xem các bãi chứa Massif trong Massif Visualizer .


4
Tôi đoán rằng hầu hết các trò chơi đồ họa sẽ không được phát triển trên một hệ thống chạy Valgrind.
Kylotan

1

Tôi khuyên bạn không nên viết cấp phát bộ nhớ của riêng bạn. Bạn cần một bản ổn định, đáng tin cậy và đã được thử nghiệm, với chức năng sửa lỗi tốt như phát hiện tham nhũng và quan trọng nhất là: với số liệu thống kê đáng tin cậy. Đây không phải là một nhiệm vụ dễ dàng và có nhiều cạm bẫy. Có những thứ tuyệt vời và dễ sử dụng ngoài kia, ví dụ:

Phân bổ Doug Lea

Nó đi kèm với khái niệm về không gian bộ nhớ, bạn có thể sử dụng một cho mỗi hệ thống con. Nó được tối ưu hóa cao và cung cấp cho bạn số liệu thống kê tuyệt vời và thông tin thời gian chạy.

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.