R: wyjaśnienie dotyczące zarządzania pamięcią

Question

Załóżmy, że mam macierz bigm. Muszę użyć losowego podzbioru tej macierzy i przekazać go algorytmowi uczenia maszynowego, na przykład svm. Losowy podzbiór macierzy będzie znany tylko w czasie wykonywania. Dodatkowo istnieją inne parametry, które są również wybrane z siatki.

Tak, mam kod, który wygląda mniej więcej tak:

foo = function (bigm, inTrain, moreParamsList) { 
    parsList = c(list(data=bigm[inTrain, ]), moreParamsList) 
    do.call(svm, parsList) 
} 

Co szukam wiedzieć, czy R wykorzystuje nową pamięć do zapisywania tych bigm[inTrain, ] obiekt w parsList. (Domyślam się, że tak.) Jakie polecenia mogę użyć do testowania takich hipotez? Dodatkowo, czy istnieje sposób użycia pod-macierzy w R bez użycia nowej pamięci?

Edit:

Ponadto zakładamy Wołam foo użyciu mclapply (w systemie Linux) gdzie bigm rezyduje w procesie macierzystym. Czy to oznacza, że ​​robię mc.cores liczbę kopii bigm lub czy wszystkie rdzenie używają obiektu od rodzica?

Jakieś funkcje i heurystyki lokalizacji pamięci i zużycia obiektów wykonanych w różnych rdzeniach?

Dzięki.

Answer 1

jestem po prostu zamiar umieścić tu co znajdę z moich badań na ten temat:

Nie sądzę, używając mclapply sprawia mc.cores kopie bigm oparciu o tę z podręcznika dla multicore:

In a nutshell fork spawns a copy (child) of the current process, that can work in parallel 
to the master (parent) process. At the point of forking both processes share exactly the 
same state including the workspace, global options, loaded packages etc. Forking is 
relatively cheap in modern operating systems and no real copy of the used memory is 
created, instead both processes share the same memory and only modified parts are copied. 
This makes fork an ideal tool for parallel processing since there is no need to setup the 
parallel working environment, data and code is shared automatically from the start. 

Answer 2

Podczas pierwszej części pytania, można użyć tracemem:

funkcja ta wyznacza OB Ject tak, że wiadomość jest drukowana, gdy wewnętrzne kopie Kodeksu obiektów

Oto przykład:

a <- 1:10 
tracemem(a) 
## [1] "<0x000000001669cf00" 
b <- a  ## b and a share memory (no message) 
d <- stats::rnorm(10) 
invisible(lm(d ~ a+log(b))) 
## tracemem[0x000000001669cf00 -> 0x000000001669e298] ## object a is copied twice 
## tracemem[0x000000001669cf00 -> 0x0000000016698a38] 
untracemem(a) 

Answer 3

można już znaleźć w przewodniku, że mclapply nie powinien wykonywać kopie bigm. Jednak każda nić musi utworzyć własną kopię mniejszej matrycy treningowej, ponieważ różni się ona między wątkami.

Jeśli zsynchronizowałeś się z np. snow, musisz mieć kopię danych w każdym z węzłów klastra. Jednak w takim przypadku możesz przepisać swój problem w taki sposób, że przekazane zostaną tylko mniejsze matryce treningowe.

Wyszukiwane hasło do ogólnego badania zachowania się w pamięci to profilowanie pamięci. Niestety, AFAIK dostępne narzędzia nie są (jeszcze) bardzo wygodne, patrz np.

• Monitor memory usage in R
• Memory profiling in R - tools for summarizing