Codice si blocca a 1.000.000 di iterazioni

[TommyB1992]

Ho sviluppato un codice che in base a come lo configuro mangia tutto: ram, cpu, gpu.
Se lo configuro con parametri "meno esosi" a livello di memoria, il codice sembra funzionare e proseguire, altrimenti si ferma esattamente a 1.000.000 di iterazioni (non da errori ne nulla).
E' possibile che sia un problema di memoria?

[korda]

Se spiegassi che cosa faccia questo codice e in che linguaggio sia stato scritto sarebbe più facile aiutarti nei tuoi problemi di overflow

[TommyB1992]

C++, cicla, fa calcoli e inserisce in un unorderd_map degli oggetti con i risulti (che poi rituilizza per fare i calcoli dei successivi oggetti).

[DoctorStrange]

Non mi è chiaro se il fatto che saturi tutte le risorse sia intenzionale, come ad esempio una fork bomb, oppure un effetto indesiderato. In questo secondo caso, visto che sviluppi in C++, ti sei assicurato di chiudere tutti gli handle rimasti aperti ed allocati, usando le varie chiamate "close" a tutti i metodi che usi?

[TommyB1992]

Non mi è chiaro se il fatto che saturi tutte le risorse sia intenzionale, come ad esempio una fork bomb, oppure un effetto indesiderato. In questo secondo caso, visto che sviluppi in C++

Non è intenzionale, semplicemente deve esplorare dei nodi, se gli dico di esplorarne solo una piccola percentuale, fa male i calcoli perchè non riesce a essere preciso, se gli dico di esplorarne troppi, diventa troppo lento (o in questo caso si blocca), perciò vado a tentativi cercando una via di mezzo e guardando i risultati che mi fornisce.

ti sei assicurato di chiudere tutti gli handle rimasti aperti ed allocati, usando le varie chiamate "close" a tutti i metodi che usi?

Presumo di si, altrimenti non funzionerebbe anche quando dico di "esplorare meno nodi" (che comunque rimangono tanti computazionalmente parlando).

[Rafbor]

Ciao, prova a eseguire il comando

Codice: Seleziona tutto

free -m

ogni 100.000 iterazioni, per esempio, per vedere se la memoria si riempie.

Forse devi liberare memoria distruggendo gli oggetti non più necessari con il comando delete.

[TommyB1992]

Ciao, prova a eseguire il comando

Codice: Seleziona tutto

free -m

ogni 100.000 iterazioni, per esempio, per vedere se la memoria si riempie.

Forse devi liberare memoria distruggendo gli oggetti non più necessari con il comando delete.

Codice: Seleziona tutto

tomas@tomas-tobefilledbyoem:~/Desktop/Projects/thirdparty/Scraper/myversion$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15899       15574         146           6         177          69
Swap:          16280        4430       11850

[Actarus5]

Hai provato ad usare valgrind? È un tool molto utile per tracciare eventuali memory leak, anche se non è detto che la causa sia questa vale la pena provarci

[Rafbor]

@TommyB1992 la memoria è piena. Puoi descrivere l'algoritmo che stai usando (se possibile in linguaggio algoritmico, per evitare di fornire codice troppo complesso da leggere e capire) e forse qualcuno vedrà come può essere ottimizzato.

[TommyB1992]

@TommyB1992 la memoria è piena. Puoi descrivere l'algoritmo che stai usando (se possibile in linguaggio algoritmico, per evitare di fornire codice troppo complesso da leggere e capire) e forse qualcuno vedrà come può essere ottimizzato.

Ma non credo dipenda questo... ho fatto ripartire l'algoritmo con meno "risorse" e sta andando da 10h.

Codice: Seleziona tutto

tomas@tomas-tobefilledbyoem:~/Desktop/Projects/thirdparty/Scraper/myversion$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15899       15372         150           4         375         209
Swap:          16280        8125        8155

Eppure anche ora è "quasi piena".

[TommyB1992]

Hai provato ad usare valgrind? È un tool molto utile per tracciare eventuali memory leak, anche se non è detto che la causa sia questa vale la pena provarci

Se non va nessun'altra alternativa do uno sguardo su come si usa

[UgoBollito]

Va bene tracciare i memory leak,ma bisognerebbe evitarli. Dato per scontato che usi puntatori e non variabili automatiche, da profano, forse passare i dati fra thread separati potrebbe essere una soluzione?

[TommyB1992]

Va bene tracciare i memory leak,ma bisognerebbe evitarli. Dato per scontato che usi puntatori e non variabili automatiche, da profano, forse passare i dati fra thread separati potrebbe essere una soluzione?

Utilizzo già OpenMP con threading x4. Paradossalmente usando un single-thread non si ferma a 4M (1M * 4 thread), ma continua.
Ciò che per me non trova senso, è: perchè proprio 1M preciso di iterazioni (che in questo caso sarebbero 4M)? E anche se tecnicamente l'esplorazione dei nodi è casuale, perciò facendo due esecuzioni del programma i dati salvati siano differenti (ho anche controllato), si blocca sempre, esattamente a 1M.
E la storia della memoria non regge molto visto il secondo tentativo fatto con free -m e che a tutti gli effetti, occupa la stessa memoria, non si blocca (e se lo fa, non lo fa a 1M di iterazioni).

[Actarus5]

Va bene tracciare i memory leak,ma bisognerebbe evitarli.

Beh sì, sarebbe auspicabile, l'idea è scoprire se ci sono eventualmente e risolvere il problema, lo davo per scontato ecco