2013-10-17 13 views
5

Supponiamo di avere una matrice bigm. Ho bisogno di usare un sottoinsieme casuale di questa matrice e darlo ad un algoritmo di apprendimento automatico come ad esempio svm. Il sottoinsieme casuale della matrice sarà noto solo in fase di esecuzione. Inoltre ci sono altri parametri che vengono scelti anche da una griglia.R: chiarimenti sulla gestione della memoria

Così, ho il codice che assomigli a questo:

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

Quello che sto cercando di sapere è se R utilizza la nuova memoria per salvare quella bigm[inTrain, ] oggetto in parsList. (La mia ipotesi è che lo faccia.) Quali comandi posso usare per testare queste ipotesi da solo? Inoltre, c'è un modo di usare una sottomatrice in R senza usare nuova memoria?

Edit:

Inoltre, assumere sto chiamando foo utilizzando mclapply (su Linux) dove bigm risiede nel processo padre. Significa che sto facendo il numero mc.cores di copie di bigm o che tutti i core usano solo l'oggetto dal genitore?

Qualsiasi funzione ed euristica di localizzazione della memoria di tracciamento e consumo di oggetti realizzati in core diversi?

Grazie.

risposta

1

Sto solo andando a mettere in qui che cosa trovo dalla mia ricerca su questo argomento:

Non credo usando mclapply rende mc.cores copie di bigm basate su questo dal manuale per 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. 
1

Per la vostra prima parte della domanda, è possibile utilizzare tracemem:

Questa funzione segna un OB Ject in modo che un messaggio viene stampato ogni volta che le copie del codice interno l'oggetto

Ecco un esempio:

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) 
+0

Grazie per questa risposta. Ho pensato che sarebbe meglio menzionare che questo è disponibile solo se R è stato compilato 'con --enable-memory-profiling'. – asb

1

hai già trovato dal manuale che mclapply non dovrebbe fare copie di bigm. Ma ogni thread deve creare la propria copia della matrice di allenamento più piccola in quanto varia attraverso i thread.

Se si dovesse parallelizzare ad es. snow, avresti bisogno di avere una copia dei dati in ciascuno dei nodi del cluster. Tuttavia, in questo caso potresti riscrivere il tuo problema in modo che vengano consegnate solo le matrici di allenamento più piccole.

Il termine di ricerca per l'analisi generale del comportamento di consumo della memoria è profilo di memoria. Sfortunatamente, AFAIK gli strumenti disponibili non sono (ancora) molto confortevoli, vedi per es.