下面通過實驗來探索pytorch分配視訊記憶體的方式。
我使用vscode的jupyter來進行實驗，首先只匯入pytorch，**如下：
import torch在視訊記憶體中建立1gb的張量，賦值給a，**如下：
a = torch.zeros([256,1024,1024],device= 'cpu')可以看到主存與視訊記憶體都變大了，而且視訊記憶體不止變大了1g，多出來的記憶體是pytorch執行所需的一些配置變數，我們這裡忽略。
再次在視訊記憶體中建立乙個1gb的張量，賦值給b，**如下：
b = torch.zeros([256,1024,1024],device= 'cpu')這次主存大小沒變，視訊記憶體變高了1gb，這是合情合理的。然後我們將b移動到主存中，**如下：
b = b.to('cpu')發現主存是變高了1gb，視訊記憶體卻只變小了0.1gb，好像只是將視訊記憶體張量複製到主存一樣。實際上，pytorch的確是複製了乙份張量到主存中，但它也對視訊記憶體中這個張量的移動進行了記錄。我們接著執行以下**，再建立1gb的張量賦值給c：
c = torch.zeros([256,1024,1024],device= 'cuda')c = torch.zeros([256,1024,1024],device= 'cuda')明明我們把張量c給覆蓋了，視訊記憶體內容卻變大了，這是為什麼呢？實際上，pytorch在執行這句**時，是首先找到可使用的視訊記憶體位置，建立這1gb的張量，然後再賦值給c。但因為在新建立這個張量時，原本的c依然占有1gb的視訊記憶體，pytorch只能先調取另外1gb視訊記憶體來建立這個張量，再將這個張量賦值給c。這樣一來，原本的那個c所在的視訊記憶體內容就空出來了，但和前面說的一樣，pytorch並不會立即釋放這裡的視訊記憶體，而等待下一次的覆蓋，所以視訊記憶體大小並沒有減小。
我們再建立1gb的d張量，就可以驗證上面的猜想，**如下：
d = torch.zeros([256,1024,1024],device= 'cuda')del d視訊記憶體沒有變化，同樣是等待下一次的覆蓋。
接著上面的實驗，我們建立直接在主存建立1gb的張量並賦值給e，**如下：
e = torch.zeros([256,1024,1024],device= 'cpu')主存變大1gb，合情合理。然後將e移動到視訊記憶體，**如下：
e = e.to('cuda')主存變小1gb，視訊記憶體沒變是因為上面張量d被刪除沒有被覆蓋，合情合理。說明主存的釋放是立即執行的。
實驗**彙總如下：
#%%
import torch
#%%a = torch.zeros([256,1024,1024],device= 'cuda')
#%%b = torch.zeros([256,1024,1024],device= 'cuda')
#%%b = b.to('cpu')
#%%c = torch.zeros([256,1024,1024],device= 'cuda')
#%%c = torch.zeros([256,1024,1024],device= 'cuda')
#%%
d = torch.zeros([256,1024,1024],device= 'cuda')
#%%del d
#%%
e = torch.zeros([256,1024,1024],device= 'cpu')
#%%e = e.to('cuda')
mallco動態分配 malloc動態分配多維陣列
下面試自己寫的三個測試程式，如果看懂了基本上動態分配多維陣列就沒什麼問題啦 重點 1 深刻理解多維陣列的概念，多維陣列在記憶體中的分配情況，基本上動態分配也沒什麼問題的。然後還要注意一點的就是，釋放是分配的逆過程！include include include void main void int ...
記憶體動態分配
陣列的元素儲存於記憶體中連續的位置上。當乙個陣列被宣告時，它所需要的內存在編譯時就被分配。但是，你也可以使用動態記憶體分配在執行時為它分配記憶體。malloc所分配的是一塊連續的記憶體。例如，如果請求它分配100個位元組的記憶體，那麼它實際分配的記憶體就是100個連續的位元組，並不會分開位於兩塊或多...
動態分配malloc realloc free
1 malloc unsigned int num bytes 分配長度為num bytes的記憶體塊，注意 malloc 只管分配不進行初始化和越界判斷，即剛獲得的記憶體中的資料是隨機的 不進行越界判斷 例如 char k malloc 10 for i 0 i 20 i for i 0 i 20...